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 .
Response to Amendment
Claims 1, 3, 5-10, 12 and 14-20 are currently pending. Claims 1, 3, 10, 12 and 19-20 have been amended and claims 2, 4, 11 and 13 have been canceled.
Response to Arguments
Applicant’s amendment and arguments (see pg. 6-7) filed on 02/10/2026 with respect to the amended limitation “by obtaining an access control policy, managed by a Root of Trust of the computing device, that references modifications to the one or more permissions based on the state of the computing device and modifying the one or more permissions based on the access control policy” in claim 1 and “for management by a hardware Root of Trust” in claim 19 have been considered and are persuasive. However, in view of the amendment and the resulting change in claim scope, the prior rejection is withdrawn and the claims are newly rejected on the grounds set forth below.
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, 3, 5-7, 10, 12 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEE et al., US-20190138741-A1 (hereinafter “LEE ‘741”) in view of Brickell et al., US-20050081065-A1 (hereinafter “Brickell ‘065”).
Per claim 1 (independent):
LEE ‘741 discloses: A method, comprising:
receiving, by a computing device, a request to run an application, wherein the application is associated with a security context;
obtaining one or more permissions associated with the security context
(FIG. 1, [0053], when a user uses a specific application and an application attempts (receiving a request to run an application) to use a specific function of the electronic device (by a computing device) in a state in which access to a specific function (of the application) of the electronic device is blocked (by obtaining one or more permissions associated with the security context), the electronic device 100 may display a UI asking about setting an access right (the security context); FIG. 4A and 4B, [0118], FIGS. 4A and 4B are views to describe an access right management table – associated with the security context; [0119], In the past, access right which matches the types of an application and functions of the electronic device 100 executed by an application is stored as a table, and the electronic device 100 determines whether to execute a specific function according to a stored table (by obtaining one or more permissions); [0122], Referring to FIG. 4B, when the status ID is 1, the application A sets the camera function access right to "allow" (one or more permissions) and when the status ID is 2 for the camera function, the camera function access right can be set to "deny" (one or more permissions));
modifying the one or more permissions based on a state of the computing device; and
running the application based on the modified one or more permissions
(FIG. 3B, [0102], The access right management module 113-1 may store access right information according to the execution state of the electronic device 100 (based on a state of the computing device) ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right (modifying the one or more permissions based on a state of the computing device), the access right management module 113-1 matches the state of the application (the state of the computing device; Various examples of “the state of the computing device” are provided in paragraphs [0103] to [0112]. For instance, [0108] discloses “a state condition depending on whether or not the security application is being executed,” and [0110] describes “a state condition for the execution time of the application”) and the permission of the access right according to the user command and store the same; FIG. 4A and 4B, [0119], In the past, access right (the modified one or more permissions) which matches the types of an application and functions of the electronic device 100 executed by an application is stored as a table, and the electronic device 100 determines whether to execute a specific function (running the application based on the modified one or more permissions) according to a stored table).
LEE ‘741 does not disclose but Brickell ‘065 discloses: modifying the one or more permissions based on a state of the computing device by obtaining an access control policy, managed by a Root of Trust of the computing device, that references modifications to the one or more permissions based on the state of the computing device and modifying the one or more permissions based on the access control policy ([0012], a method for permitting the owner/main user of a computer system (the computing device) to grant sets of permissions/delegations (modifying the one or more permissions) for control of a system resource (such as a TPM, for example) ... Embodiments of the present invention permit a user/ owner of a computer system to establish a list (obtaining an access control policy) of acceptable environments (as defined herein), that is, based on a state of the computing device, and then have those (and only those) environments (i.e., the state of the computing device; see [0016], “Environment: a given set of hardware, firmware, and software for a computer system”) automatically granted TPM ownership and management privileges (a Root of Trust of the computing device) on each subsequent boot of the system, without requiring further user interaction. The user/owner retains the ability to adjust the list, changing TPM privileges granted to an environment or revoking the privileges entirely – modifying the one or more permissions based on the access control policy; FIG. 2, [0029], The ME may communicate 126 a generated DOT-E to a particular delegated environment 108 (that is, a certain DOT-E represents a certain delegate environment, which is a state of the computing device). The ME also communicates 128 the generated DOT-R for the delegated environment to a resource 130 (e.g., a TPM corresponding to the Root of Trust of the computing device) on the computer system ... The resource may store the received DOT-R (for managing the access control policy, e.g., the ACL 132) in a list called an access control list (ACL) 132 (i.e., the access control policy that references modifications to the one or more permissions based on the state of the computing device). The ACL may comprise a list of DOT-Rs for delegated environments; [0021], The delegate owner token (DOT) may authorize some subset of the owner's capabilities on the computer system – modifications to the one or more permissions based on the state of the computing device).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 with the selective grant of delegated environments partial TPM ownership privileges by storing DOT-R entries in an ACL of the resource and permitting access when a valid DOT-E is presented as taught by Brickell ‘065 because it would enable fine-grained and centralized delegation of TPM owner functionality by selectively granting, modifying, or revoking partial ownership capabilities for different delegated environments [0012][0021]. Additionally, Brickell ‘065 is analogous to the claimed invention because it teaches permitting the owner/main user of a computer system to grant sets of permissions/delegations for control of a system resource (such as a TPM, for example) [0012].
Per claim 3 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 1, wherein the access control policy comprises a metadata data structure ([0122], Referring to FIG. 4B, when the status ID is 1, the application A sets the camera function access right to "allow" and when the status ID is 2 for the camera function, the camera function access right can be set to "deny"; Note that the table shown in FIG. 4B demonstrates that the same app A is associated with different ‘access rules’ depending on the ‘object’ and the ‘status ID’. In other words, this indicates that distinct access control policies are to be applied to the same app A based on contextual factors, and furthermore, the table includes, in addition to the access rule column, other columns such as ‘object and status ID’, i.e., metadata).
Per claim 5 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 1, wherein the state of the computing device references at least one of a life cycle state of the computing device, a temperature of the computing device, a time, a date, a measurable value or a discoverable value (FIG. 3B, [0102], The access right management module 113-1 may store access right information according to the execution state of the electronic device 100 (the state of the computing device) ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right, the access right management module 113-1 matches the state of the application and the permission of the access right according to the user command and store the same; [0107], the status condition of the application may be a condition for the location of the electronic device 100; [0110], the state condition of the application may be a state condition for the execution time of the application).
Per claim 6 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 1, wherein the state of the computing device references an identification of a host system requesting to run the application or an identification of a user requesting to run the application (FIG. 3B, [0102], The access right management module 113-1 may store access right information according to the execution state of the electronic device 100 (the state of the computing device) ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right, the access right management module 113-1 matches the state of the application and the permission of the access right according to the user command and store the same; [0103], the state condition of the application (the application) may be information on a network to which the electronic device 100 is connected (through an identification of a host system requesting to run the application), a connected device, or position of the electronic device 100).
Per claim 7 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 1, wherein modifying the one or more permissions comprises replacing a first set of permissions associated with the security context with a second set of permissions associated with the state of the computing device (FIG. 3B, [0102], The access right management module 113-1 may store access right information according to the execution state of the electronic device 100 (associated with the state of the computing device) ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right (modifying the one or more permissions), the access right management module 113-1 matches the state of the application and the permission of the access right according to the user command and store the same; FIG. 4A and 4B, [0118], FIGS. 4A and 4B are views to describe an access right management table – associated with the security context; [0122], Referring to FIG. 4B, when the status ID is 1, the application A sets the camera function access right to "allow" (one or more permissions) and when the status ID is 2 for the camera function, the camera function access right can be set to "deny" (one or more permissions); Note that the table shown in FIG. 4B demonstrates that the same app A is associated with different ‘access rules’ depending on the ‘object’ and the ‘status ID’. In other words, this indicates that distinct access control policies are to be applied to the same app A based on contextual factors. In this case, for example, when the app A transitions from using a camera object with status id 2 (a first set of permissions) to an internet object with status id 2 (a second set of permissions), the access rule changes from ‘deny’ to ‘allow.’ In other words, the set of permissions is replaced).
Per claim 10 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 12 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 3 and the claim(s) is/are rejected for the reasons detailed with respect to claim 3.
Per claim 14 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 5 and the claim(s) is/are rejected for the reasons detailed with respect to claim 5.
Per claim 15 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 6 and the claim(s) is/are rejected for the reasons detailed with respect to claim 6.
Per claim 16 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 7 and the claim(s) is/are rejected for the reasons detailed with respect to claim 7.
Claim(s) 8, 17 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEE ‘741 in view of Brickell ‘065 and Kumar et al., US-20170169254-A1 (hereinafter “Kumar ‘254”).
Per claim 8 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 in view of Brickell ‘065 does not disclose but Kumar ‘254 discloses: The method of claim 1, wherein a permission of the set of permission enables access to a secure data asset (FIG. 2, [0023], an example architecture 200 of a secure computation environment; [0025], The architecture 200 may include a resource enforcement core 260 that enforces control or access to the resources 232A-H of the architecture 200 (enables access to a secure data asset). Such resources may include, but are not limited to, one-time programmable (OTP) memory writes or burns, OTP reads, feature reads, feature writes, reading of cryptographic keys – the secure data asset ... For example, a container 240 may include an identification of permissions (a permission of the set of permission) to the features or resources 232A-H and the container manager 250 may program registers or memory of the resource enforcement core 260 based on the permissions of a container 240 that is to be executed).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 in view of Brickell ‘065 with the verification of the signature of the container with a public key, whereby the container includes an identification of permissions to the resources including feature reads or reading of cryptographic keys as taught by Kumar ‘254 because resource sharing among containers can be achieved more safely and without conflict [0026].
Per claim 17 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 8 and the claim(s) is/are rejected for the reasons detailed with respect to claim 8.
Per claim 19 (independent):
LEE ‘741 discloses: A method, comprising:
generating, by a processor, an access control policy associated with a state of a computing device and a security context, wherein the access control policy references a modification to be applied to a permission of the security context
(FIG. 4A and 4B, [0118], FIGS. 4A and 4B are views to describe an access right management table – an access control policy; [0119], In the past, access right (the access control policy) which matches the types of an application and functions of the electronic device 100 (associated with a state of a computing device; For an example of a state of a computing device, see FIG. 3B and [0102], which were cited in support of the rejection of claim 1) executed by an application is stored (generated) as a table (generating, by a processor, an access control policy associated with a state of a computing device), and the electronic device 100 determines whether to execute a specific function according to a stored table; [0122], Referring to FIG. 4B, when the status ID is 1, the application A sets the camera function access right to "allow" (a permission) and when the status ID is 2 for the camera function, the camera function access right can be set to "deny" (a permission) – means that the access right, i.e., an access control policy, is associated with a security context; FIG. 1, [0053], when a user uses a specific application and an application attempts to use a specific function of the electronic device in a state in which access to a specific function of the electronic device is blocked, the electronic device 100 may display a UI asking about setting an access right, that is, a modification to be applied to a permission of the security context; Note that modifications to access rights made through the UI are stored in the access right as shown in FIG. 4A and 4B for later references).
LEE ‘741 does not disclose but Kumar ‘254 discloses: signing the security policy using a cryptographic key; and sending the signed security policy to a computing device (FIG. 2, [0023], an example architecture 200 of a secure computation environment; [0025], For example, a container 240 may include an identification of permissions (the security policy) to the features or resources 232A-H and the container manager 250 may program registers or memory of the resource enforcement core 260 based on the permissions of a container 240 that is to be executed; FIG. 3, [0030], The processing logic may determine whether the container (received in the secure computation environment at block 310) is signed by a root entity that has assigned a preemption privilege to the container (block 340). In some embodiments, the container (the signed security policy) may be cryptographically signed by a root entity. For example, a root entity may sign the container with a private key (signing the security policy using a cryptographic key) and the secure computation environment may verify the signature of the container (which has been sent to the secure computation environment such as the 200 of FIG.2, i.e., a computing device) with a public key that corresponds to the private key).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 with the verification of the signature of the container with a public key, whereby the container includes an identification of permissions to the resources as taught by Kumar ‘254 because resource sharing among containers can be achieved more safely and without conflict [0026].
LEE ‘741 in view of Kumar ‘254 does not disclose but Brickell ‘065 discloses: storing the security policy to a computing device for management by a hardware Root of Trust. (FIG. 2, [0029], The ME may communicate 126 a generated DOT-E to a particular delegated environment 108. The ME also communicates 128 the generated DOT-R for the delegated environment to a resource 130 (e.g., a TPM corresponding to a hardware Root of Trust of a computing device) on the computer system ... The resource may store the received DOT-R (for managing the security policy, e.g., the ACL 132) in a list called an access control list (ACL) 132 (i.e., the security policy). The ACL may comprise a list of DOT-Rs for delegated environments; [0021], The delegate owner token (DOT) may authorize some subset of the owner's capabilities on the computer system).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 in view of Kumar ‘254 with the selective grant of delegated environments partial TPM ownership privileges by storing DOT-R entries in an ACL of the resource and permitting access when a valid DOT-E is presented as taught by Brickell ‘065 because it would enable fine-grained and centralized delegation of TPM owner functionality by selectively granting, modifying, or revoking partial ownership capabilities for different delegated environments [0012][0021].
Per claim 20 (dependent on claim 19):
LEE ‘741 in view of Brickell ‘065 and Kumar ‘254 discloses the elements detailed in the rejection of claim 19 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 19, wherein the state of the computing device references at least one of a life cycle state of the computing device or an identification a host system requesting to run an application (FIG. 3B, [0102], The access right management module 113-1 may store access right information according to the execution state of the electronic device 100 (the state of the computing device) ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right, the access right management module 113-1 matches the state of the application and the permission of the access right according to the user command and store the same; [0103], the state condition of the application (an application) may be information on a network to which the electronic device 100 is connected (through an identification a host system requesting to run an application), a connected device, or position of the electronic device 100).
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over LEE ‘741 in view of Brickell ‘065 and Kumar ‘254 and Kumar et al., US-20180357183-A1 (hereinafter “Kumar ‘183”).
Per claim 9 (dependent on claim 1):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
LEE ‘741 discloses: The method of claim 1, further comprising:
receiving an access control policy referencing one or more permission modifications;
storing the access control policy
(FIG. 3B, [0102], The access right management module 113-1 may store access right information (an access control policy) according to the execution state of the electronic device 100 ... That is, when a user command for granting or denying the access right is inputted through the UI inquiring about the permission or denial of the access right (one or more permission modifications), the access right management module 113-1 matches the state of the application and the permission of the access right according to the user command and store the same; FIG. 4A and 4B, [0118], FIGS. 4A and 4B are views to describe an access right management table; [0122], Referring to FIG. 4B, when the status ID is 1, the application A sets the camera function access right to "allow" and when the status ID is 2 for the camera function, the camera function access right can be set to "deny"; Note that the access right information – such as the table of FIG. 4B – that reflects one or more permission modifications configured via the UI is stored in the electronic device 100 via the access right management module 113-1).
LEE ‘741 in view of Brickell ‘065 does not disclose but Kumar ‘254 discloses: wherein the access control policy is signed with a cryptographic signature; verifying the cryptographic signature (FIG. 2, [0023], an example architecture 200 of a secure computation environment; [0025], For example, a container 240 may include an identification of permissions (the access control policy) to the features or resources 232A-H and the container manager 250 may program registers or memory of the resource enforcement core 260 based on the permissions of a container 240 that is to be executed; FIG. 3, [0030], The processing logic may determine whether the container is signed by a root entity that has assigned a preemption privilege to the container (block 340). In some embodiments, the container (the access control policy) may be cryptographically signed by a root entity (signed with a cryptographic signature). For example, a root entity may sign the container with a private key (signed with a cryptographic signature) and the secure computation environment may verify the signature of the container (verifying the cryptographic signature) with a public key that corresponds to the private key).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 in view of Brickell ‘065with the verification of the signature of the container with a public key, whereby the container includes an identification of permissions to the resources as taught by Kumar ‘254 because resource sharing among containers can be achieved more safely and without conflict [0026].
LEE ‘741 in view of Brickell ‘065 and Kumar ‘254 does not disclose but Kumar ‘183 discloses: receiving, from a provisioning device, an access control policy (FIG. 1, [0017], The device may include an integrated circuit with a multiple root of trust component that provides access to different resources, or features, of the integrated circuit based on different roots of trust. Each of the roots of trust may correspond to a single root entity that represents an entity that is assigned certain permissions or privileges (an access control policy to be received) to resources of the integrated circuit; [0023], the second entity 120 may be a semiconductor chip packaging provider that receives the integrated circuit from the first entity 110 and produces a semiconductor package for the integrated circuit that includes the multiple root of trust component 115 that provides privileges (receiving, from a provisioning device, an access control policy, whereby the provisioning device can be used by the manufacturer of the integrated circuit for including the multiple root of trust with cryptographic keys as described in [0023]) to one or more resources of the integrated circuit to the second entity 120 that is the first root entity).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified LEE ‘741 in view of Brickell ‘065 and Kumar ‘254 with the provision of permissions to resources of the integrated circuit via the multiple root of trust component at different times throughout the lifecycle of the integrated circuit as taught by Kumar ‘183 because access to the resources of the integrated circuit would be performed effectively and securely at each stage of the entire lifecycle. Additionally, Kumar ‘183 is analogous to the claimed invention because it teaches an example lifecycle 100 of an integrated circuit including a multiple root of trust component [0022].
Per claim 18 (dependent on claim 10):
LEE ‘741 in view of Brickell ‘065 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 9 and the claim(s) is/are rejected for the reasons detailed with respect to claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LANDERHOLM et al., US-20230131348-A1 – An access control list (ACL) associated with a migrated key may be redefined at an inheriting HSM. Accordingly although the key itself is transferred, the original ACL is not necessarily preserved, since a second ACL may be specified during the key sending operation to define a different access policy at the inheriting HSM.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights