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 .
The amendment filed on 02/10/2026 has been entered. Applicant amended claims 1-2, 5, 9, 10, 15, and 18-20 in the amendment.
Claims 1-20 remain pending.
Response to Arguments
Applicant's arguments filed 02/10/2026 have been fully considered but they are not persuasive.
Applicant argued Adams is not concerned with devices and methods for “traceably planning, designing, developing, deploying, and operating secure software” in “a software supply chain having a plurality of stages of a software life cycle.”
Applicant’s arguments rely on language solely recited in preamble recitations in claim(s) “traceably planning, designing, developing, deploying, and operating secure software” in “a software supply chain having a plurality of stages of a software life cycle”. When reading the preamble in the context of the entire claim, the recitation “traceably planning, designing, developing, deploying, and operating secure software” in “a software supply chain having a plurality of stages of a software life cycle” is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02.
Applicant argued Adams disclose APIs of software fully developed and Landman discloses a method applicable to software still in development, and therefore one ordinary skill would not combine the two references.
In response to applicant’s argument, the claim recites “at least one of the plurality of stage” and deployment of a software is a very important stage in the life cycle of a software, just because the software is “developed” doesn’t mean the stages of the software is complete. Therefore, any additional security measure and/or further development can occur during the development stage, even if the software is “completed” as argued by the applicant. For the at least foregoing reason, the rejection is maintained.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. The structure to perform the claimed function can be found in [0004] of the specification.
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 2-13 and 16-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the public key" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 16 recites the limitation "the public key" in line 4. There is insufficient antecedent basis for this limitation in the claim.
All dependent claims are rejected as having the same deficiencies as the claims they depend from.
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.
Claim(s) 1, 2, 9, 13, 16, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams (US 2007/0074031 A1), hereinafter Adams, in view of Landman (US 2022/0164452 A1) .
Regarding claim 1, Adams discloses
In a software supply chain having a plurality of stages of a software life cycle, a method of traceably planning, designing, developing, deploying, and operating secure software, comprising:
accepting, in secure management service via a first client interface module of a set of client interface modules, a request from a member, among a plurality of members, of the software supply chain to sign designated information, the designated information associated with the secure software in at least one of the plurality of stages ([0021]: receiving a code signing request from a requester, the requestor being an entity registered at the registering step, wherein the code signing request comprises an object that the requestor is requesting to have signed with a select private key of the at least one private key created);
signing the designated information in response to the request according to a private key of a public/private key pair uniquely associated with the member ([0021]: digitally signing the object, wherein a digital signature is generated using the selected private key); and
providing the signed designated information to the member of the software supply chain ([0021]: transmitting the digital signature to the requestor).
Adams does not explicitly disclose
software in at least one of the plurality of stages.
However, Landman discloses
software in at least one of the plurality of stages ([0005]: verifying completion of one or more stages of a multi-stage development process, such as a CI/CD pipeline process, for a software release and for validating information generated by the one or more stages using validation information provided with the software release).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Landman in Adams because Adams discloses providing code signing services to software application developers (abstract) and Landman further suggests verifying completion of one or more stages of a multi-stage software development process ([0005]).
One of ordinary skill in the art would be motivated to utilize the teachings of Landman in the Adams system in order to ensure completion of multi-stage development process.
Regarding claim 2, Adams and Landman disclose the method as described in claim 1. Adams further discloses
providing the designated information, the signed designated information, and the public key to another member of the software supply chain ([0064]: public signature key may instead be obtained from a public key repository (not shown), using mobile device or possibly a personal computer system, and installed on mobile device as needed; mobile device computes a hash of software application in the signed software application, using the same hashing algorithm as code signing authority, and uses the digital signature and public signature key to recover the hash originally encoded by code signing authority); and
wherein the signed designated information is validated according to the public key of the public/private key pair ([0059]: once signed software application is loaded on mobile device, at least one digital signature of signed software application will then typically be verified with a public signature key before software application is granted access to a sensitive API).
Regarding claim 9, Adams and Landman disclose the method as described in claim 2. Adams further discloses
the designated information and the signed designated information is provided to the another member of the software supply chain via a software repository server ([0059]: signed software application may then be sent to mobile device over a wireless network for example, or otherwise loaded onto mobile device; once signed software application is loaded on mobile device, at least one digital signature of signed software application will then typically be verified with a public signature key before software application is granted access to a sensitive API; & [0064]: mobile device computes a hash of software application in the signed software application, using the same hashing algorithm as code signing authority, and uses the digital signature and public signature key to recover the hash originally encoded by code signing authority).
Regarding claim 13, Adams and Landman disclose the method as described in claim 2. Adams further discloses
accepting the public key from the member of the software supply chain or the secure management service ([0109]: a private key and a corresponding public key are created in known manner; the private key is stored for future use by the code signing authority, and the public key is deployed; the public key can be attached to sensitive API(s) that the code signing authority wishes to protect, or it may store the public key in a repository, which is made available to code signing system components executing on computing devices when signature verification is required); and
validating the signed designated information using the public key ([0059]: once signed software application is loaded on mobile device, at least one digital signature of signed software application will then typically be verified with a public signature key before software application is granted access to a sensitive API).
Regarding claim 16, Adams and Landman disclose the method as described in claim 1. Adams further discloses
generating the key pair uniquely associated with the member ([0021]: creating at least one public key and at least one corresponding private key; & [0095]: a private key/public key pair needs to first be generated, so that the public key can be attached to the APIs (e.g. classes) that are to be protected by classifying them as sensitive);
storing the private key in secure storage ([0021]: deploying each public key to protect at least one sensitive API and storing each corresponding private key; & [0095]: the private key can be stored locally (e.g., in private key store) by the code signing authority for later use); and
storing the public key ([0064]: public signature key may instead be obtained from a public key repository, using mobile device or possibly a personal computer system, and installed on mobile device as needed; & [0109]: he public key can be attached to sensitive API(s) that the code signing authority wishes to protect, or it may store the public key in a repository, which is made available to code signing system components executing on computing devices when signature verification is required).
Regarding claims 19 and 20, the limitations of claims 19 and 20 are rejected in the analysis of claim 1 above and these claims are rejected on that basis.
Claim(s) 3-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Bhandari et al. (US 2020/0322176 A1), hereinafter Bhandari.
Regarding claim 3, Adams and Landman disclose the method as described in claim 2. Adams and Landman do not explicitly disclose
generating a signing artifact, the signing artifact having information describing the signing of the designated information; and
storing the signing artifact in the secure management service.
However, Bhandari discloses
generating a signing artifact, the signing artifact having information describing the signing of the designated information ([0017]: generating a signed dossier including all validated signed security measurements in a secure enclave, the signed dossier being used by an external network device for remote attestation of the device); and
storing the signing artifact in the secure management service ([0090]: the modules can be verified by the network device, which in turn saves a dossier of validation information in a secure enclave; & [0098]: secure enclave can securely store and replicate the signed dossier received from trusted processor module).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Bhandari in Adams and Landman because Adams and Landman disclose providing code signing services to software application developers (Adams: abstract) and Bhandari further suggests generating a signed dossier (abstract).
One of ordinary skill in the art would be motivated to utilize the teachings of Bhandari in the Adams and Landman system in order to provide a secure system.
Regarding claim 4, Adams, Landman, and Bhandari disclose the method as described in claim 3. Adams, Landman, and Bhandari further disclose
providing the signing artifact to the member of the software supply chain (Bhandari: [0101]: sends the signed security measurement to trusted processor module and trusted processor module receives the signed security measurement);
receiving an attestation request from the another member of the software supply chain, the attestation request comprising the signing artifact (Bhandari: [0018]: the signed dossier being used by an external network device for remote attestation of the device; & [0101]: receives the request for the signed security measurement; & [0102]: supervisor trusted processor module validates the signed security measurement received from module);
comparing the received signing artifact with the stored signing artifact (Bhandari: [0102]: validate the signed security measurement by comparing the signature keys of module with public keys for this purpose in trusted processor module);
generating an attestation response according to the comparison between the received signing artifact and the stored signing artifact (Bhandari: [0104]: signs all received and verified signed security measurements compiled in a dossier). Therefore, the limitations of claim 4 are rejected in the analysis of claim 3 above, and the claim is rejected on that basis.
Regarding claim 5, Adams, Landman, and Bhandari disclose the method as described in claim 3. Adams, Landman, and Bhandari further disclose
receiving an attestation request from the another member of the software supply chain (Bhandari: [0018]: the signed dossier being used by an external network device for remote attestation of the device; & [0101]: receives the request for the signed security measurement; & [0102]: supervisor trusted processor module validates the signed security measurement received from module); and
providing the stored signing artifact to the another member of the software supply chain for comparison with another signing artifact (Bhandari: [0101]: sends the signed security measurement to trusted processor module and trusted processor module receives the signed security measurement). Therefore, the limitations of claim 5 are rejected in the analysis of claim 3 above, and the claim is rejected on that basis.
Claim(s) 6-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, in view of Bhandari, and further in view of Deacon (US 8,572,368 B1).
Regarding claim 6, Adams, Landman, and Bhandari disclose the method as described in claim 3. Adams, Landman, and Bhandari do not explicitly disclose
augmenting a dossier to include the signed designated information and the stored signing artifact, the dossier provided, upon request, to any of the plurality of members of the software supply chain.
However, Deacon discloses
augmenting a dossier to include the signed designated information and the stored signing artifact, the dossier provided, upon request, to any of the plurality of members of the software supply chain (Col. 1, lines 50-62: (1) receiving a code-signing request from a software publisher to sign code, the code-signing request including both information that uniquely identifies the code and metadata that identifies at least one characteristic of the code, (2) signing the code by generating a unique, code-specific digital certificate for the code that is valid only for the code in question and includes at least a portion of the metadata contained within the code-signing request).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Deacon in Adams, Landman, and Bhandari because Adams, Landman, and Bhandari disclose providing code signing services to software application developers (Adams: abstract) and Deacon further suggests signing the code by generating a certificate for the code includes at least a portion of the metadata (Col. 1, lines 50-62).
One of ordinary skill in the art would be motivated to utilize the teachings of Deacon in the Adams, Landman, and Bhandari system in order to improve systems for generating and providing digital certificates to convey useful information as suggested by Deacon (Col. 1, lines 37-39).
Regarding claim 7, Adams, Landman, Bhandari, and Deacon disclose the method as described in claim 6. Adams, Landman, Bhandari, and Deacon further disclose
accepting, in a secure management service, a request for the dossier from any of the plurality of members of the software supply chain (Deacon: Col. 1, lines 50-62: receiving a code-signing request from a software publisher to sign code); and
providing the dossier in response to the request (Deacon: Col. 1, lines 50-62: providing the code-specific digital certificate to the software publisher to enable the software publisher to attest that the code originated from the software publisher and has not been altered since leaving the software publisher’s possession). Therefore, the limitations of claim 7 are rejected in the analysis of claim 6 above, and the claim is rejected on that basis.
Regarding claim 8, Adams, Landman, Bhandari, and Deacon disclose the method as described in claim 7. Adams, Landman, Bhandari, and Deacon further disclose
the secure management service comprises a second key pair, the second key pair comprising a second private key and a second public key (Bhandari: [0095]: a code signing authority application creates a private key/public key pair for the APIs that the code signing authority wishes to control access to);
the dossier is signed by the secure management service according to the second private key (Bhandari: [0096]: the dossier can be signed by an enrollment key stored in trusted processor module; & [0097]: the key enrollment comprises an asymmetric cipher with a private key component stored in secure enclave used to sign a certificate chain issued by a certificate authority and a corresponding certificate which is either a self-signed certificate authority or root certificate signed by a customer’s root certificate authority). Therefore, the limitations of claim 8 are rejected in the analysis of claim 7 above, and the claim is rejected on that basis.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Wheeler et al. (US 8,620,814 B2), hereinafter Wheeler.
Regarding claim 10, Adams and Landman disclose the method as described in claim 2. Adams and Landman do not explicitly disclose
the public key is provided by the member of the software supply chain to the another member of the software supply chain.
However, Wheeler discloses
the public key is provided by the member of the software supply chain to the another member of the software supply chain (Col. 10, lines 38-39: prior to sending a message to the receiver, the sender provides the sender’s public key to the receiver).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Wheeler in Adams and Landman because Adams and Landman disclose obtaining public key from a public key repository (Adams: [0064]) and Wheeler further suggests sending public key to receiver (Col. 10, lines 38-39).
One of ordinary skill in the art would be motivated to utilize the teachings of Wheeler in the Adams and Landman system in order to provide a convenient system to users.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Kwan et al. (US 8,769,260 B1), hereinafter Kwan.
Regarding claim 11, Adams and Landman disclose the method as described in claim 2. Adams and Landman do not explicitly disclose
the public key is provided to the another member by the secure management service on behalf of the member of the software supply chain.
However, Kwan discloses
the public key is provided to the another member by the secure management service on behalf of the member of the software supply chain (Col. 4, lines 43-52: the backend service is configured to send to the sender computer the public key of the recipient computer for encrypting the symmetric key used to encrypt the message content of the e-mail).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Kwan in Adams and Landman because Adams and Landman disclose obtaining public key from a public key repository (Adams: [0064]) and Kwan further suggests backend service sends public key of recipient computer to the sender computer (Col. 4, lines 43-52).
One of ordinary skill in the art would be motivated to utilize the teachings of Kwan in the Adams and Landman system in order to provide a convenient system.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Hamann et al. (US 2019/0215164 A1), hereinafter Hamann.
Regarding claim 12, Adams and Landman disclose the method as described in claim 2. Adams and Landman do not explicitly disclose
accepting, in the secure management service via an other one of the set of client interface modules, a request from the another member of the software supply chain to validate the signed designated information using the public key;
validating, in the secure management service, the signed designated information using the public key; and
providing the validation to the another member of the software supply chain.
However, Hamann discloses
accepting, in the secure management service via an other one of the set of client interface modules, a request from the another member of the software supply chain to validate the signed designated information using the public key ([0040]: sending the signed request to the authentication or registration service for validation against the public key);
validating, in the secure management service, the signed designated information using the public key ([0040]: if the authentication service successfully validates a signed request against the public key); and
providing the validation to the another member of the software supply chain ([0040]: the authentication service provides the requested protected resource to the user).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Hamann in Adams and Landman because Adams and Landman disclose receiving and processing code signing request (Adams: abstract) and Kwan further suggests validating a signed request against public key ([0040]).
One of ordinary skill in the art would be motivated to utilize the teachings of Hamann in the Adams and Landman system in order to provide a secure system.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Thompson et al. (US 12,363,156 B1), hereinafter Thompson, and in view of Swvigaradoss et al. (US 2024/0211373 A1), hereinafter Swvigaradoss.
Regarding claim 14, Adams and Landman disclose the method as described in claim 1. Adams and Landman further disclose
the designated information includes:
member login data (Landman: [0060]: login information);
a software build log (Landman: [0027]: stage data);
a quality assurance log (Landman: [0027]: stage data);
an integration log (Landman: [0027]: stage data);
a software end of life declaration (Landman: [0005]: end times).
Adams and Landman do not explicitly disclose
the designated information includes:
security requirements;
a software image;
a security declaration and security documentation;
security monitoring information;
a security patch; and
a software replacement recommendation.
However, Thompson discloses
the designated information includes:
security requirements (Col. 98, lines 29-42: security policies or compliance requirements);
a software image (Col. 33, lines 36-39: documented evidence can include logging the sequence of steps taken to apply a security patch, complete with timestamps and system snapshots);
a security declaration and security documentation (Col. 98, lines 29-42: security policies or compliance requirement);
security monitoring information (Col. 98, lines 29-42: safeguard data (e.g., implemented security controls or measures));
a security patch (Col. 33, lines 36-39: documented evidence can include logging the sequence of steps taken to apply a security patch, complete with timestamps and system snapshots).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Thompson in Adams and Landman because Adams and Landman disclose providing code signing services to software application developers (Adams: abstract) and Thompson further suggests documented evidence (Col. 33, lines 36-39).
One of ordinary skill in the art would be motivated to utilize the teachings of Thompson in the Adams and Landman system in order to provide a secure system.
Adams, Landman, and Thompson do not explicitly disclose
a software replacement recommendation.
However, Swvigaradoss discloses
a software replacement recommendation ([0160]: the process analyst might recommend that this software application be replaced).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Swvigaradoss in Adams, Landman, and Thompson because Adams, Landman, and Thompson disclose providing code signing services to software application developers (Adams: abstract) and Swvigaradoss further suggests recommend software application be replaced ([0160]).
One of ordinary skill in the art would be motivated to utilize the teachings of Swvigaradoss in the Adams, Landman, and Thompson system in order to enhance security and compliance.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Hart et al. (US 2021/0136014 A1), hereinafter Hart.
Regarding claim 15, Adams and Landman disclose the method as described in claim 1. Adams and Landman do not explicitly disclose
the secure management service generates a reminder for the member of the plurality of members of the software supply chain to sign the designated information.
However, Hart discloses
the secure management service generates a reminder for the member of the plurality of members of the software supply chain to sign the designated information ([0058]: the system may determine the user activity to be a remining the user to review and sign the record).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Hart in Adams and Landman because Adams and Landman disclose providing code signing services to software application developers (Adams: abstract) and Hart further suggests reminding user to sign a record ([0058]).
One of ordinary skill in the art would be motivated to utilize the teachings of Hart in the Adams and Landman system in order to provide a convenient system.
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Moran et al. (US 2024/0265083 A1), hereinafter Moran.
Regarding claim 17, Adams and Landman disclose the method as described in claim 16. Adams and Landman do not explicitly disclose
the secure storage stores the private key at a plurality of selectable security levels.
However, Moran discloses
the secure storage stores the private key at a plurality of selectable security levels ([0022]: store private keys without compromising the private keys (with at least some level of security)).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Kwan in Adams and Landman because Adams and Landman disclose generate a private key/public key pair and store the private key locally (Adams: [0095]) and Moran further suggests store private key with some level of security ([0022]).
One of ordinary skill in the art would be motivated to utilize the teachings of Moran in the Adams and Landman system in order to provide a secure system to store private keys without compromising the private keys.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Adams in view of Landman, and further in view of Hou et al. (US 2016/0315773 A1), hereinafter Hou.
Regarding claim 18, Adams and Landman disclose the method as described in claim 1. Adams and Landman do not explicitly disclose
the secure management service notifies the member of the software supply chain each time the secure management service uses the private key.
However, Hou discloses
the secure management service notifies the member of the software supply chain each time the secure management service uses the private key ([0044]: the device to be notified uses the private key to decrypt the modified access authentication information).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate feature of Hou in Adams and Landman because Adams and Landman disclose data encrypted using a private key of a private key/public key pair can only be decrypted using the corresponding public key of the pair, and vice-versa (Adams: [0061]) and Hou further suggests notify the uses the private key to decrypt ([0044]).
One of ordinary skill in the art would be motivated to utilize the teachings of Hou in the Adams and Landman system in order to provide an informative secure system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Choi (US 2015/0312041 A1). Notify a use of the private key by coercion from a third party ([0047]).
Nakano et al. (US 2007/0283151 A1). Storing the private key, the public key certification, the initial private key and the initial certification in different storing areas according to the security level ([0021]).
Asokan et al. (US 2005/0086467 A1). The indication is of knowledge of the generating entity regarding the level of security of the private key stored by the storing entity.
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 KAYLEE J HUANG whose telephone number is (571)272-0080. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, Joon H Hwang can be reached at 571-272-4036. 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.
Kaylee Huang
04/21/2026
/KAYLEE J HUANG/Primary Examiner, Art Unit 2447
Prosecution Insights