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 .
Detailed action
Claims 1-20 are pending and being considered.
Claims 1, 2, 7, 8, 11, 12, 17 and 18 have been amended.
Response to 103
Applicant’s arguments filed on 05/12/2025 have been fully considered and are not persuasive.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Sakthikumar (i.e., primary reference) is directed towards multi-owner deployment of signed firmware images that comprises a first code module signed by a first code owner and a second code module signed by a second code owner and updating the signed firmware image with the updated first code module in response to verifying that the updated first code module is signed by the first code owner. Sakthikumar discloses validating, utilizing the platform ROTPK, a plurality of firmware owner ROTPKs across a respective plurality of signing domains in one or more operations to provision a plurality of firmware agents and delegating cryptographic control of firmware authorization management to plurality of delegates based on public-private key pair. Sakthikumar fails to explicitly teach transferring cryptograph control based on provisioning a subsequent system owner public key as a platform root of trust public key (ROTPK) for the at least one computing device. However, Phan from analogous art overcomes the above deficiency. One would be motivated to do so in order to ensure that the ownership of a device is legitimate and allowing to transfer this ownership securely and efficiently from a first owner to a second owner (Phan [0011]).
In response to applicant’s arguments on page 10 of remarks, the applicant argues that the cited prior art Sakthikumar fails to teach the amended limitation “subsequent to transferring cryptographic control to the subsequent system owner, validating, utilizing the platform ROTPK, a plurality of firmware owner ROTPKs across a respective plurality of signing domains in one or more operations to provision a plurality of firmware agents in a secure non-volatile storage of the at least one computing device” the examiner acknowledges applicants point of view but respectfully disagrees because Sakthikumar explicitly teaches on [0028] teaches an initial owner of the root firmware image, such as a system manufacturer (referred to herein as "Root"), has signed each of the firmware image code modules in five firmware volumes (FV1 211, FV2 213, FV3 215, FV4 217, and FV5 219) with root private key 220. Signing the code module may involve attaching the digital signature to the code module. In the examples shown herein, a signature for a code module is illustrated as a signature associated with a firmware volume containing the code module. Similarly, the authority to update a given code module is described as the authority to update a firmware volume containing the code module. See on [0034] teaches firmware image signed by a root firmware code owner "Root," an OEM firmware code owner "OEM," and a channel distributor firmware code owner "Chnl" in accordance with one embodiment of the invention. In this example, a third owner of code modules of the firmware image, such as a channel customer of the OEM holding private key 240 in FIG. 2B, has provided customized root firmware modules. The third owner "Chnl" has signed one firmware volume within the firmware image, now referred to as channel customer firmware image 210C, with the channel (Chnl) private key 250.
Claim Objections
Claims 1 and 11 objected to because of the following informalities:
Claim 1 and 11 recites “a plurality of firmware owner ROTPKs” and further recites “authorizing….one or more firmware owner ROTPK…..” the examiner inconsistencies in the claims and suggests to clarify whether “plurality of firmware owner ROTPKs” is same as “one or more firmware owner ROTPK”. Appropriate correction is required.
The above remarks also apply to claims 9 and 19.
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.
Claims 1-7, 9-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sakthikumar et al (hereinafter Sakthikumar) (US 20110307712 in view of Phan (US 20190149558)
Regarding claim 1 Sakthikumar teaches a method, comprising: (Sakthikumar on [0019] teaches method for obtaining a signed firmware image);
subsequent to transferring cryptographic control to the subsequent system owner, validating, utilizing the platform ROTPK, a plurality of firmware owner ROTPKs across a respective plurality of signing domains in one or more operations to provision a plurality of firmware agents in a secure non-volatile storage of the at least one computing device (Sakthikumar on [0028] teaches an initial owner of the root firmware image, such as a system manufacturer (referred to herein as "Root"), has signed each of the firmware image code modules in five firmware volumes (FV1 211, FV2 213, FV3 215, FV4 217, and FV5 219) (i.e., a respective plurality of signing domains) with root private key 220. Signing the code module may involve attaching the digital signature to the code module. In the examples shown herein, a signature for a code module is illustrated as a signature associated with a firmware volume containing the code module. Similarly, the authority to update a given code module is described as the authority to update a firmware volume containing the code module. See on [0037] teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated, such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. In this example, public key 362 for firmware code owner "OEM" has been included in token 360, with an access control list 364 allowing the owner of OEM public key 362 to update firmware volumes FV3 315 and FV5 319 i.e., Please note that the firmware image is updated after firmware control is delegated see [0033-0036] );
via at least one processor of the at least one computing device, delegating at least in part, cryptographical control of firmware authorization management for the at least one computing device by the subsequent system owner, having cryptographical control of the platform ROTPK, to a one or more delegates (Sakthikumar Fig 3 and text on [0036-0038 and 0055] teaches the process for signing and delegating authority for updating the signed firmware by host computer system comprising a processor. Initially, root firmware image 310A has been signed by root firmware code owner "Root" having control of public key 331 (i.e., equivalent to cryptographical control of platform ROTPK). Further teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated (i.e., delegating third party), such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. See on [0040] teaches OEM" firmware code owner (the owner of private key 340), creates a signed token 370 in order to authorize subsequent updates of OEM firmware image 310B. By signing token 370, the owner of private key 340, "OEM" firmware code owner, associates the "OEM" public key 341 with token 370. Token 370 is created to include information for which authority is being delegated, such as a public key 372 of an entity authorized to update OEM firmware image 310B and an access control list 374 indicating the firmware modules within OEM firmware image 310B that can be updated by the corresponding public key 372 (i.e., plurality of delegates). See also Fig 4 and text on [0043-0049] teaches the steps described in FIG. 4 are performed by an owner of an existing firmware image, such as signed root firmware image 310A of FIG. 3, to delegate authority to another entity to update the signed firmware image (i.e., delegating cryptographic control of firmware to another entity). The entity delegating authority to update the firmware image is referred to herein as the "delegating entity");
wherein the cryptographical control of firmware authorization management includes authorizing by the one or more delegates, one or more new firmware owner ROTPK, revoking one or more firmware owner ROTPK, or modifying one or more firmware owner ROTPK, or any combination thereof (Sakthikumar on [0036-0038] teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated (i.e., delegating third party), such as a public key 362 of an entity authorized (i.e., authorizing public key 362 equivalent to authorizing one or more firmware owner ROTPK) to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. See on [0040-0042 and claim 3] teaches "OEM" firmware code owner (the owner of private key 340), creates a signed token 370 in order to authorize subsequent updates of OEM firmware image 310B. By signing token 370, the owner of private key 340, "OEM" firmware code owner, associates the "OEM" public key 341 with token 370. Token 370 is created to include information for which authority is being delegated, such as a public key 372 of an entity authorized to update OEM firmware image 310B and an access control list 374 indicating the firmware modules within OEM firmware image 310B that can be updated by the corresponding public key 372 i.e., subsequent delegation process for authorizing another entities public key to update firmware image. Please note that the token 360 and 370 corresponds to delegate authority certificate and revoking and/or modifying firmware ROTPK specified in the token 360 and 370).
Although Sakthikumar describes system owner delegating cryptographic control of firmware authorization to another entity, but fails to explicitly teach transferring cryptograph control, including cryptographic control of firmware authorization management, of at least one computing device from a previous system owner to a subsequent system owner at least in part by provisioning a subsequent system owner public key as a platform root of trust public key (ROTPK) for the at least one computing device, wherein the subsequent system owner maintains cryptographical control of the at least one computing device at least in part via the platform ROTPK, however Phan from analogous art teaches
transferring cryptograph control, including cryptographic control of firmware authorization management, of at least one computing device from a previous system owner to a subsequent system owner at least in part by provisioning a subsequent system owner public key as a platform root of trust public key (ROTPK) for the at least one computing device ((Phan on [0152-0155 and 0162-0173]
teaches transferring ownership of lot device (i.e., equivalent to associating particular computing
device with new ownership) from user 1 (i.e., current system owner) to user 2 (i.e., new system owner) using private key of user 1 (i.e., current system owner private key) and public key of user 2 (i.e., subsequent system owner public key as ROTPK));
wherein the subsequent system owner maintains cryptographical control of the at least one computing device at least in part via the platform ROTPK ((Phan on [0152-0155 and 0162-0173]
teaches transferring ownership of lot device (i.e., equivalent to associating particular computing
device with new ownership) from user 1 (i.e., current system owner) to user 2 (i.e., new system owner) using private key of user 1 (i.e., current system owner private key) and public key of user 2 (i.e., subsequent system owner uses public key as ROTPK to maintain control of at least one computing device)).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Phan into the teaching of Sakthikumar by having the subsequent owner of the computing device maintaining overall control of the computing system using ROTPK. One would be motivated to do so in order to ensure that the ownership of a device is legitimate and allowing to transfer this ownership securely and efficiently from a first owner to a second owner (Phan [0011]).
Regarding claim 11 Sakthikumar teaches an apparatus, comprising: (Sakthikumar on [0036 and 0055] teaches host computer having processor);
at least one processor implemented in hardware to: (Sakthikumar on [0036 and 0055] teaches host computer having processor);
subsequent to transferring cryptographic control to the subsequent system owner, validating, utilizing the platform ROTPK, a plurality of firmware owner ROTPKs across a respective plurality of signing domains in one or more operations to provision a plurality of firmware agents in a secure non-volatile storage of the at least one computing device (Sakthikumar on [0028] teaches an initial owner of the root firmware image, such as a system manufacturer (referred to herein as "Root"), has signed each of the firmware image code modules in five firmware volumes (FV1 211, FV2 213, FV3 215, FV4 217, and FV5 219) (i.e., a respective plurality of signing domains) with root private key 220. Signing the code module may involve attaching the digital signature to the code module. In the examples shown herein, a signature for a code module is illustrated as a signature associated with a firmware volume containing the code module. Similarly, the authority to update a given code module is described as the authority to update a firmware volume containing the code module. See on [0037] teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated, such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. In this example, public key 362 for firmware code owner "OEM" has been included in token 360, with an access control list 364 allowing the owner of OEM public key 362 to update firmware volumes FV3 315 and FV5 319);
delegate cryptographical control of firmware authorization management for the at least one computing device by the subsequent system owner, having cryptographical control of the platform ROTPK to one or more delegates (Sakthikumar Fig 3 and text on [0036-0038 and 0055] teaches the process for signing and delegating authority for updating the signed firmware by host computer system comprising a processor. Initially, root firmware image 310A has been signed by root firmware code owner "Root" having control of public key 331 (i.e., equivalent to cryptographical control of platform ROTPK). Further teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated (i.e., delegating third party), such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. See on [0040] teaches OEM" firmware code owner (the owner of private key 340), creates a signed token 370 in order to authorize subsequent updates of OEM firmware image 310B. By signing token 370, the owner of private key 340, "OEM" firmware code owner, associates the "OEM" public key 341 with token 370. Token 370 is created to include information for which authority is being delegated, such as a public key 372 of an entity authorized to update OEM firmware image 310B and an access control list 374 indicating the firmware modules within OEM firmware image 310B that can be updated by the corresponding public key 372 (i.e., plurality of delegates). See also Fig 4 and text on [0043-0049] teaches the steps described in FIG. 4 are performed by an owner of an existing firmware image, such as signed root firmware image 310A of FIG. 3, to delegate authority to another entity to update the signed firmware image (i.e., delegating cryptographic control of firmware to another entity). The entity delegating authority to update the firmware image is referred to herein as the "delegating entity");
wherein the cryptographical control of firmware authorization management includes authorizing by the one or more delegates, one or more new firmware owner ROTPK, revoking one or more firmware owner ROTPK, or modifying one or more firmware owner ROTPK, or any combination thereof (Sakthikumar on [0036-0038] teaches the owner of private key 320, "Root," creates a signed token 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated (i.e., delegating third party), such as a public key 362 of an entity authorized (i.e., authorizing public key 362 equivalent to authorizing one or more firmware owner ROTPK) to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362. See on [0040-0042 and claim 3] teaches "OEM" firmware code owner (the owner of private key 340), creates a signed token 370 in order to authorize subsequent updates of OEM firmware image 310B. By signing token 370, the owner of private key 340, "OEM" firmware code owner, associates the "OEM" public key 341 with token 370. Token 370 is created to include information for which authority is being delegated, such as a public key 372 of an entity authorized to update OEM firmware image 310B and an access control list 374 indicating the firmware modules within OEM firmware image 310B that can be updated by the corresponding public key 372 i.e., subsequent delegation process for authorizing another entities public key to update firmware image. Please note that the token 360 and 370 corresponds to delegate authority certificate and revoking and/or modifying firmware ROTPK specified in the token 360 and 370).
Although Sakthikumar describes system owner delegating cryptographic control of firmware authorization to another entity, but fails to explicitly teach transferring cryptograph control, including cryptographic control of firmware authorization management, of at least one computing device from a previous system owner to a subsequent system owner at least in part by provisioning a subsequent system owner public key as a platform root of trust public key (ROTPK) for the at least one computing device, wherein the subsequent system owner maintains cryptographical control of the at least one computing device at least in part via the platform ROTPK, however Phan from analogous art teaches
transfer cryptograph control, including cryptographic control of firmware authorization management, of at least one computing device from a previous system owner to a subsequent system owner at least in part by provisioning a subsequent system owner public key as a platform root of trust public key (ROTPK) for the at least one computing device ((Phan on [0152-0155 and 0162-0173]
teaches transferring ownership of lot device (i.e., equivalent to associating particular computing
device with new ownership) from user 1 (i.e., current system owner) to user 2 (i.e., new system owner) using private key of user 1 (i.e., current system owner private key) and public key of user 2 (i.e., subsequent system owner public key as ROTPK));
wherein the subsequent system owner maintains cryptographical control of the at least one computing device at least in part via the platform ROTPK ((Phan on [0152-0155 and 0162-0173]
teaches transferring ownership of lot device (i.e., equivalent to associating particular computing
device with new ownership) from user 1 (i.e., current system owner) to user 2 (i.e., new system owner) using private key of user 1 (i.e., current system owner private key) and public key of user 2 (i.e., subsequent system owner uses public key as ROTPK to maintain control of at least one computing device)).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Phan into the teaching of Sakthikumar by having the subsequent owner of the computing device maintaining overall control of the computing system using ROTPK. One would be motivated to do so in order to ensure that the ownership of a device is legitimate and allowing to transfer this ownership securely and efficiently from a first owner to a second owner (Phan [0011]).
Regarding claim 2 and 12 the combination of Sakthikumar and Phan teaches all the limitations of claims 1 and 11 respectively Sakthikumar further teaches wherein the delegating the cryptographical control of firmware authorization management for the at least one computing device by the subsequent system owner to a first delegate of the one or more delegates comprises: the subsequent system owner cryptographically signing a first delegation authority certificate for the first delegate (Sakthikumar on [0037] teaches creates a signed token (i.e., signed delegation certificate) 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated, such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362).
Phan teaches provisioning the signed delegation authority certificate in a key database of the at least one computing device (Phan on [0046, 0054, 0067, 0099 and 0201] teaches storing the signed assertions in a database).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Phan into the teaching of Sakthikumar by storing the signed certificate in database. One would be motivated to do so in order to ensure that the ownership of a device is legitimate and allowing to transfer this ownership securely and efficiently from a first owner to a second owner (Phan [0011]).
Regarding claim 3 and 13 the combination of Sakthikumar and Phan teaches all the limitations of claims 2 and 12 respectively Sakthikumar further teaches wherein the first delegation authority certificate includes one or more parameters specifying one or more firmware types that the first delegate is permitted to authorize (Sakthikumar on [0036-0040] teaches creates a signed token (i.e., signed delegation certificate) 360 in order to authorize subsequent updates of root firmware image 310A. By signing token 360, the owner of private key 320, "Root" firmware code owner, associates the "Root" public key 321 with token 360. Token 360 is created to include information for which authority is being delegated, such as a public key 362 of an entity authorized to update root firmware image 310A and an access control list 364 indicating the firmware modules within root firmware image 310A that can be updated by the corresponding public key 362).
Regarding claim 4 and 14 the combination of Sakthikumar and Phan teaches all the limitations of claims 2 and 12 respectively Sakthikumar further teaches wherein the first delegation authority certificate to include one or more parameters specifying one or more permissions delegated to the first delegate (Sakthikumar on [0037-0038 and 0044-0046] teaches token includes access control list and public key authorizing the delegated entity to update or modify the firmware).
Regarding claim 5 and 15 the combination of Sakthikumar and Phan teaches all the limitations of claims 4 and 14 respectively Sakthikumar further teaches wherein the one or more permissions delegated to the first delegate include authorization of firmware ROTPK or revocation of firmware ROTPK for one or more specified firmware types (Sakthikumar on [0037-0038 and 0044-0046] teaches token includes access control list and root public key authorizing the delegated entity to update or modify the firmware).
Regarding claim 6 and 16 the combination of Sakthikumar and Phan teaches all the limitations of claims 4 and 14 respectively Sakthikumar further teaches wherein the one or more permissions delegated to the first delegate include modification of firmware owner authorization properties (Sakthikumar on [0047-0049] teaches In "Verify Delegating Entity is Authorized Change AC" step 450, a determination is made whether the delegating entity is authorized to change the access control list of the existing firmware image. As described above, the delegating entity, "Root" firmware code owner, has been designated as the owner of the access control list for firmware volumes FV1 311 through FV5 319. Consequently, the delegating entity is authorized to change the access control list for these firmware volumes).
Regarding claim 7 and 17 the combination of Sakthikumar and Phan teaches all the limitations of claims 1 and 11 respectively Sakthikumar further teaches wherein the plurality of delegates respectively comprise one or more individuals or one or more organizations, or a combination thereof (Sakthikumar Fig 4 and text on [0043] teaches the steps described in FIG. 4 are performed by an owner of an existing firmware image, such as signed root firmware image 310A of FIG. 3, to delegate authority to another entity to update the signed firmware image (i.e., delegating cryptographic control of firmware to another entity). The entity delegating authority to update the firmware image is referred to herein as the "delegating entity.").
Regarding claim 9 and 19 the combination of Sakthikumar and Phan teaches all the limitations of claims 1 and 11 respectively Sakthikumar further teaches further comprising the subsequent system owner authorizing one or more firmware owner ROTPK or the subsequent system owner revoking authorization to the one or more firmware owner ROTPK (Sakthikumar on [0036-0040] teaches an entity with public key 331 (which corresponds to the "Root" owner with private key 320) has an access control list 332 containing pointers 332A through 332E allowing the owner of public key 331 to update code modules contained in each of firmware volumes FV1 311, FV2 313, FV3 315, FV4 317, and FV5 319. Further teaches a public key 362 of an entity authorized to update root firmware image 310A).
Regarding claim 10 and 20 the combination of Sakthikumar and Phan teaches all the limitations of claims 9 and 19 respectively Sakthikumar further teaches further comprising the subsequent system owner modifying firmware owner authorization properties (Sakthikumar on [0047-0049] teaches In "Verify Delegating Entity is Authorized Change AC" step 450, a determination is made whether the delegating entity is authorized to change the access control list of the existing firmware image. As described above, the delegating entity, "Root" firmware code owner, has been designated as the owner of the access control list for firmware volumes FV1 311 through FV5 319. Consequently, the delegating entity is authorized to change the access control list for these firmware volumes).
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sakthikumar et al (hereinafter Sakthikumar) (US 20110307712) in view of Phan (US 20190149558) and further in view of Birgisson et al (hereinafter Birgisson) (US 10146932).
Regarding claim 8 and 18 the combination of Sakthikumar and Phan teaches all the limitations of claims 1 and 11 respectively, although Sakthikumar teaches verifying delegated entity is authorized to make changes in the firmware (i.e., implied that delegated entity also not have permission to make the change i.e., permission revoked [0042-0048 and 0052]), the combination fails to explicitly teach the subsequent system owner revoking, via the at least one processor of the at least one computing device, cryptographical control of the firmware authorization management for the at least one computing device from the delegate, however Birgisson from analogous art teaches the system owner revoking, via the at least one processor of the at least one computing device, cryptographical control of the firmware authorization management for the at least one computing device from at least one of the one or more delegates (Birgisson on [col 4 line 60-65] teaches resource device 140 is owned by an owner, who uses the system 100 to authorize another user, a “sharee” to access the resource device 140. After granting access to the sharee, the owner uses the system 100 to revoke the access of the sharee using an access control blacklist 142. See on [col 5 line 10-20] teaches the owner device 110 can be a mobile device that an owner uses to grant and revoke authorization to access the resource device 140. For example, the owner device 110 can transmit access control data that specifies users that can access the resource device 140 and one or more conditions associated with the access (e.g., time period of access, permission levels for access, etc.) to the access granting authority 120. The access control data can then be used by the access granting authority 120 to generate and maintain the user access control list 122. See on [col 6 line 53-60] teaches each blacklist entry within the access control blacklist 132 can specify token information for the sharee device 130. The resource device 140 then uses the token information included within the access control blacklist 132 to block access by the sharee device 130 based on comparing token information included within the access control blacklist 132 and the information included within the limited token 126a i.e., owner of the resource device maintains overall control of the resource device while authorizing another user to have access to the resource device).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Birgisson into the combined teaching of Sakthikumar and Phan by having the owner of the computing device maintaining overall control of the computing system and revoking by the subsequent system owener cryptographic control. One would be motivated to do so in order to regulate the user accessing the resource device by providing limited access, thereby protecting user against potential security breaches (Birgisson [col 1 line 25-35]).
Conclusion
THIS ACTION IS MADE FINAL. 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 MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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 on (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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436