DETAILED ACTION
This office action is in response to the application filed on 08/26/2026. Claim(s) 1, 6-9, 11-14, 16-18, and 20 is/are pending and are examined. Claim(s) 2-5, 10, 15, and 19 are cancelled.
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 .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 07/05/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Response to Arguments
Applicant's arguments filed on 08/26/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
Eksten relates to a method for determining trust levels for components of computing applications using a blockchain. Eksten discloses that a blockchain comprising one or more blocks may be provided by system, and each block may contain a component, and a block may also contain a digital signature associated with one or more digital certificates. (Eksten, par. [0094].) Eksten further discloses that digital signature may include a pointer to block containing preceding component, and a pointer to a block containing a following component. (Eksten, par. [0123].) However, Eksten fails to disclose that the multi-dimensional attestation for a
component includes an attestation reference to, or a signed attestation for, the at least one other component, wherein the at least one other component includes at least one of a dependency on which the at least one component is dependent, a previous release of the at least one component, another component with which the at least one component communicates, or a software layer on which the at least one component runs.
(Applicant’s response filed on 08/26/2026, page 6-7).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Eksten¶ 94 teaches, “A block may also contain a digital signature associated with one or more digital certificates. A digital signature may be generated by blockchain manager prior to addition or update of a block to blockchain. ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component.)” which clearly demonstrates that the digital signature of the block is multi-dimensional in that it contains multiple different parts of information to confirm attestation/authenticity along with containing a pointer pointing to a previous of next component. Further in Eksten ¶ 38 teaches, " deploying each component the deployment subsystem queries the license server to determine whether the component is linked to the digital certificate associated with the user computing subsystem and the digital certificate associated with the component provider subsystem.” Meaning each component that is being pointed to contains a signed certificate which is a form of attestation. As such the Eksten teaches the claimed limitation above.
Applicant’s Argument:
With respect to claims 2-4, Examiner cites paragraphs [0151]-[0154] and [0027] for disclosing the features of claims 2-4. However, the description in paragraphs [015 1]-[0154] and [0027] is merely regarding design-time software architecture, not signed attestation content. There is no disclosure in Eksten that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a dependency on which the component is dependent, a previous release of the component, another component with which the component communicates, or a software layer on which the component runs. (Applicant’s response filed on 08/26/2026, page 6-7).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portions of Eksten ¶ 151-154 teaches, “the component dependencies may also be isolated, referring exclusively to the specific component and version(s) they depend on. This may enable the system to realize complex workflows while resolving components dependencies without user intervention.” Which clearly shows that a component contains dependency and version information. The component pieces are pointed to by Eksten as discussed above. This shows that the signed digital certificate of Eksten that points to another component containing a digital certificate also contains the dependency and version information that the limitation calls for, as such Eksten teaches the claimed limitation above.
Applicant’s Argument:
In rejecting claim 1, Examiner relies on the Eksten's blockchain digital-signature scheme. Eksten discloses that digital signature may include a pointer to a block containing a preceding component and a pointer to a block containing a following component. Examiner equates this pointer data structure with the attestation reference of claim 1. However, none of cited paragraphs [0151]-[0154] and [0027] mentions blocks, blockchains, digital signatures, or the pointer fields.
Eksten discloses that components may be self-contained and isolated from a dependency point of view, and the entire dependency set of a component may be self-contained, being specified and packaged in the component distribution unit (e.g. plugin), and the component dependencies may also be isolated, referring exclusively to the specific component and version(s) they depend on. (Eksten, par. [0151].)
This describes a packaging/build-time property of a component. Eksten merely discloses that its dependency set is bundled and isolated within the component's own distribution unit (e.g., a plugin package) so that the runtime system can resolve dependencies without user intervention. This says nothing about a signed data structure that references a dependency. Eksten merely discloses how a component's own dependency set is packaged internally. There is no disclosure about a signed attestation reference to a dependency component in paragraphs [0151]-[0154] of Eksten. Eksten fails to disclose that the multi- dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a dependency on which the component is dependent.
(Applicant’s response filed on 08/26/2026, page 7-8).
Examiner’s Response:
The Examiner respectfully disagrees. As discussed above the cited portions of Eksten demonstrate the content that a component contains. The signed digital certificate as stated above points to another component which also contains a digital certificate, the components as shown by the cited portions of Eksten contain the claimed information including dependency and version information. As such Eksten teaches the claimed limitation.
Applicant’s Argument:
Eksten discloses in par. [0027] that the component is associated with one or more versions, wherein the trust matrix links one or more trust levels to each of the versions of the
component, and the blueprint comprises a reference to a solution set of components, wherein the solution set identifies a version for the component.
Eksten merely discloses that the trust matrix links trust-level scores to different versions of a component. The trust matrix is a separate data structure distinct from the blockchain/digital structure. Eksten discloses a version-selection mechanism for choosing a specific component version at build/deployment time. There is no disclosure in Eksten that the trust matrix or solution-set reference is included in, or forms part of, the digital signature or blocks used for the attestation reference. Eksten merely discloses that multiple versions of a component can each separately have trust levels tracked in the trust matrix. Eksten fails to disclose that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a previous release of the component.
Eksten discloses in pars. [0152]-[0154] that components may have pins, there may be different types of pins, and pins may be used to pass data between components. This is merely regarding connecting the input/output pins of one component to another when authoring a graph or blueprint. A pin is a connection point in the graphical editor, not a signed record, and connecting pins is not the same as generating or including, within a signed attestation for one component, a reference to another, separately-attested communicating component. Eksten fails to disclose that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, another component with which the at least one component communicates.
None of the cited paragraphs of Eksten (pars. [0151]-[0154] and [0027]) discusses the blockchain, blocks, digital signature, or pointer fields that the Examiner relies on to meet the attestation reference of claim 1. Those paragraphs instead describe a different, general-purpose software feature of the development/deployment platform. Eksten discloses component packaging and dependency isolation (par. [0151]), version tracking via the trust matrix and solution sets (par. [0027]), and graphical pin-based wiring between components (pars. [0152]- [0154]). Eksten does not disclose any link between these features and the attestation structure of claim 1. Examiner merely shows that Eksten's overall platform happens to have some notion of dependencies, versions, and inter-component connections somewhere in its disclosure. However, there is no disclosure in Eksten that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a dependency on which the component is dependent, a previous release of the component, another component with which the component communicates, or a software layer on which the component runs.
(Applicant’s response filed on 08/26/2026, page 6-7).
Examiner’s Response:
The Examiner respectfully disagrees. The Applicant seems to be taking each cited portion of Eksten as separate individual information that do not relate to one another. However, the cited portions of Eksten as discussed shows that each component of Eksten contains these pieces of information within each component. As further clarified by Eksten ¶ 27 “the component is associated with one or more versions, wherein the trust matrix links one or more trust levels to each of the versions of the component, and wherein the blueprint comprises a reference to a solution set of components, wherein the solution set identifies a version for the component.” While the cited paragraph itself does not claim attestation or a signature the cited paragraph teaches that the components contain version information within them which when put together with the earlier cited paragraphs and as discussed above shows that pointed to component does contain the information that the limitation specifies. As such Eksten teaches the claimed limitation.
Applicant’s Argument:
Eksten merely mentions, in disconnected passages describing unrelated aspects of a software- development platform, dependency packaging, version tracking, and pin-based component wiring, and none of them is shown to be signed, attested, or part of the reference structure as recited in claim 1.
Eksten fails to disclose that the multi-dimensional attestation for the at least one component includes a signed attestation for a respective component and either an attestation reference to at least one other component of the software application that is related to the respective component or a signed attestation for the at least one other component, wherein the at least one other component includes at least one of a dependency on which the at least one component is dependent, a previous release of the at least one component, another component with which the at least one component communicates, or a software layer on which the at least one component runs. Therefore, claim 1 and its dependent claims are not anticipated by Eksten.
(Applicant’s response filed on 08/26/2026, page 6-7).
Examiner’s Response:
The Examiner respectfully disagrees. As discussed above each cited paragraph contributes to the overall teaching of Eksten to cover the claimed limitation and teach the claimed multi-dimensional attestation. The Examiner thoroughly discussed how the cited portions of Eksten teaches the claimed limitations.
Applicant’s Argument:
Crabtree relates to cybersecurity and threat analytics. Crabtree discloses a method for determining privilege escalation attack pathways by performing a cybersecurity threat assessment of software applications based on the totality of vulnerabilities from all levels of the software supply chain to determine attack paths for a privilege escalation attack. (Crabtree, par. [0035].) However, Crabtree fails to disclose or suggest a software layer attestation reference as recited in claim 1.
Crabtree discloses that the cyber-physical graph represents the relationships between a software application, the vulnerabilities and levels associated, and the level of access to the
hardware. (Crabtree, par. [0130].) This disclosure does not correspond to the feature that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a software layer on which the at least one component runs. The "levels" mentioned in par. [0130] of Crabtree are privilege/protection rings, not software stack layers on which a component runs. Crabtree merely discloses a vulnerability-scoring graph. The cyber- physical graph in Crabtree is not a signed or attested structure.
In addition, Crabtree does not even mention attestations, signed data, digital signatures, or cryptographic verification of any kind. Crabtree discloses a vulnerability-discovery and risk- scoring system, not a system for generating cryptographically signed attestations of software components. Examiner relies on Crabtree only for the "software layer/level" phrase in isolation, not for any attestation-reference/signed-attestation structure incorporating it. There is no reason that a person of ordinary skill in the art would have looked to a privilege-escalation vulnerability-scoring graph of Crabtree, completely lacking any attestation or cryptographic- signature concept, to modify a blockchain trust-level signature scheme of Eksten to add a signed attestation or reference to a software layer on which the component runs.
The combination of Eksten and Crabtree fails to teach that the multi-dimensional attestation for a component includes an attestation reference to, or a signed attestation for, a software layer on which the component runs. Therefore, claim 1 and its dependent claims are not obvious over Eksten and Crabtree.
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Crab ¶ 130 and Fig. 25 teaches, “the cyber-physical graph represents the relationships between a software application, the vulnerabilities and levels associated, and the level of access to the hardware.” Is meant to fill the gap left by the teachings of Eksten, which as discussed above teaches the currently claimed multi-dimensional attestation for a component that includes an attestation reference, that gap being a data component containing information about a components different layers which the cited portion of Crab does. As such the cited portion of Crab when taken in combination with the teachings of Eksten teaches the claimed limitations. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Eksten with Crab, to modify the method for determining trust level for computer components of Eksten with the cyber-physical graph of Crab. The motivation to do so, ¶ 130, to show privilege attack pathways represented as a directed graph with identification of the sources of specific software packages and possible vulnerabilities.
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, 6-7, 9, 11-12, 14, 16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eksten (US 2018/0157825 A1), hereinafter Eksten in view of Crabtree (US 2022/0210202 A1), hereinafter Crab.
Regarding Claim(s) 1 and 14 Eksten teaches:
A method for generating multi-dimensional attestations for a software application, comprising:
obtaining signed attestations for components of the software application; (Eksten ¶ 101 teaches, blockchain may be operable to enable auditable transactions (e.g. generation or updating of a block) and provide irrefutable proof of transaction to a third party upon request. The irrefutable proof of transaction may be provided by way of a digital signature associated with a block.)
constructing a multi-dimensional attestation for at least one component of the software application, wherein the multi-dimensional attestation for the at least one component includes a signed attestation for a respective component and either an attestation reference to at least one other component of the software application that is related to the respective component or a signed attestation for the at least one other component; and (Eksten¶ 94 teaches, A block may also contain a digital signature associated with one or more digital certificates. A digital signature may be generated by blockchain manager prior to addition or update of a block to blockchain. ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component.))
transmitting the multi-dimensional attestation to a customer or a verifier, (Eksten ¶ 140 teaches, each of digital signatures may be unique such that a third party may independently verify the authentication of the signature as belonging to a trustworthy source.)
wherein the at least one other component includes a dependency on which the at least one component is dependent, (Eksten ¶ 151-154 teaches, the component dependencies may also be isolated, referring exclusively to the specific component and version(s) they depend on. This may enable the system to realize complex workflows while resolving components dependencies without user intervention.) , a previous release of the at least one component, (Eksten ¶ 27 teaches, the component is associated with one or more versions, wherein the trust matrix links one or more trust levels to each of the versions of the component, and wherein the blueprint comprises a reference to a solution set of components, wherein the solution set identifies a version for the component.) , another component with which the at least one component communicates, (Eksten ¶ 152-154 teaches, Components may have pins. Pins connect to pins on other components. A push pin pushes its output to the next pin and a pull pin calls for data on its input pin. The pin model controls the flow of data between components. There are output pins. There are control pins, including event (out), property (in/out), and command (in) pins.)
Eksten does not appear to explicitly teach but in related art:
, or a software layer on which the at least one component runs. (Crab ¶ 130 and Fig. 25 teaches, the cyber-physical graph represents the relationships between a software application, the vulnerabilities and levels associated, and the level of access to the hardware.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Eksten with Crab, to modify the method for determining trust level for computer components of Eksten with the cyber-physical graph of Crab. The motivation to do so, ¶ 130, to show privilege attack pathways represented as a directed graph with identification of the sources of specific software packages and possible vulnerabilities.
Regarding Claim(s) 6 and 16 Eksten teaches:
The method of claim 1, (Eksten teaches the parent claim above.) wherein the attestation reference includes identifying information of a signed attestation that is referenced in the attestation reference. (Eksten ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component. Eksten ¶ 171 teaches, properties may include a name, class name, unique identifier (such as a GUID for example), a description, one or more categories, and one or more trust levels.)
Regarding Claim(s) 7 Eksten teaches:
The method of claim 6, (Eksten teaches the parent claim above.) wherein the identifying information uses a standard identifier format. (Eksten ¶ 171 teaches, properties may include a name, class name, unique identifier (such as a GUID for example), (i.e., GUID is a standard identifier format) a description, one or more categories, and one or more trust levels.)
Regarding Claim(s) 9 and 18 Eksten teaches:
A method for attestation verification of a software application, comprising:
obtaining a multi-dimensional attestation for at least one component of the software application, wherein the multi-dimensional attestation includes a signed attestation for a respective component and either an attestation reference for at least one other component related to the respective component or a signed attestation for the at least one other component; (Eksten¶ 94 teaches, A block may also contain a digital signature associated with one or more digital certificates. A digital signature may be generated by blockchain manager prior to addition or update of a block to blockchain. ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component.))
obtaining the signed attestation for the at least one other component based on the attestation reference if the multi-dimensional attestation includes the attestation reference; (Eksten ¶ 124 teaches, the digital certificates field may contain a pointer to each applicable digital certificate associated with one or more authorities that have provided and accepted the component 24b. Prior to generating field, blockchain manager may, via cryptography unit to verify that the digital certificates are authentic.)
verifying integrity of at least part of the software application based on the obtained signed attestations; and (Eksten ¶ 124 teaches, the digital certificates field may contain a pointer to each applicable digital certificate associated with one or more authorities that have provided and accepted the component 24b. Prior to generating field, blockchain manager may, via cryptography unit to verify that the digital certificates are authentic.)
wherein the at least one other component includes at least one of a dependency on which the at least one component is dependent, a previous release of the at least one component, another component with which the at least one component communicates, or a software layer on which the at least one component runs. (Eksten ¶ 27 teaches, the component is associated with one or more versions, wherein the trust matrix links one or more trust levels to each of the versions of the component, and wherein the blueprint comprises a reference to a solution set of components, wherein the solution set identifies a version for the component.)
Eksten does not appear to explicitly teach but in related art:
outputting a verification result. (Crab ¶ 128 teaches, the software list and scoring can be used to provide a verified or certified risk level (i.e., verification result) that can be used in many industries where cybersecurity risk is a concern.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Eksten with Crab, to modify the method for determining trust level for computer components of Eksten with the cyber-physical graph of Crab. The motivation to do so, ¶ 128, to provide a verified or certified risk level that can be used in many industries where cybersecurity risk is a concern.
Regarding Claim(s) 11 Eksten in view of Crab teaches:
The method of claim 9, (Eksten in view of Crab teaches the parent claim above.) wherein the attestation reference includes identifying information of the signed attestation for the at least one other component. (Eksten ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component. Eksten ¶ 171 teaches, properties may include a name, class name, unique identifier (such as a GUID for example), a description, one or more categories, and one or more trust levels.)
Regarding Claim(s) 12 Eksten in view of Crab teaches:
The method of claim 11, (Eksten in view of Crab teaches the parent claim above.) wherein the identifying information uses a standard identifier format. (Eksten ¶ 171 teaches, properties may include a name, class name, unique identifier (such as a GUID for example), a description, one or more categories, and one or more trust levels.)
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eksten as applied to claim 1 and 14 above, and further in view of Avetisov (US 2020/0067907 A1), hereinafter Avetisov.
Regarding Claim(s) 8 and 17 Eksten teaches:
The method of claim 6, (Eksten teaches the parent claim above.)
Eksten does not appear to explicitly teach but in related art:
wherein the attestation reference further includes a digest of the signed attestation that is referenced in the attestation reference. (Avetisov ¶ 136 teaches, recording of information like a transaction to the directed acyclic graph of cryptographic hash pointers is achieved by storing a cryptographic hash digest of the information in node content of the directed acyclic graph of cryptographic hash pointers.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Eksten with Avetisov, to modify the method for determining trust level for computer components of Eksten with the reference digest of Avetisov. The motivation to do so, Avetisov ¶ 136, to identify or verify information associated with the transaction.
Claim(s) 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eksten in view of Crab as applied to claim 9 above, and further in view of Avetisov.
Regarding Claim(s) 13 Eksten in view of Crab teaches:
The method of claim 11, (Eksten in view of Crab teaches the parent claim above.) wherein the attestation reference includes a digest of the signed attestation for the at least one other component, and the method further comprises verifying integrity of the obtained signed attestation for the at least one other component based on the digest. (Avetisov ¶ 136-138 teaches, recording of information like a transaction to the directed acyclic graph of cryptographic hash pointers is achieved by storing a cryptographic hash digest of the information in node content of the directed acyclic graph of cryptographic hash pointers. Where the transaction record includes cryptographic hash pointers to other transaction records in a hash digest, those other transaction records may also be verified.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Eksten in view of Crab with Avetisov, to modify the method for determining trust level for computer components of Eksten with the reference digest of Avetisov. The motivation to do so, Avetisov ¶ 136, to identify or verify information associated with the transaction.
Regarding Claim(s) 20 Eksten in view of Crab teaches:
The apparatus of claim 18, (Eksten in view of Crab teaches the parent claim above.)
wherein the attestation reference includes identifying information of the signed attestation for the at least one other component, (Eksten ¶ 123-124 teaches, digital signature may include one or more of the following fields: digital certificates, timestamp (including date), (i.e., multi-dimensional) trust level, function or purpose, category of use, expiry date, a pointer to block containing preceding component, (i.e., reference to related component) and if applicable, a pointer to a block containing a following (or subsequent) component. Eksten ¶ 171 teaches, properties may include a name, class name, unique identifier (such as a GUID for example), a description, one or more categories, and one or more trust levels.)
and a digest of the signed attestation for the at least one other component, wherein the circuitry is further configured to verify integrity of the obtained signed attestation for the at least one other component based on the digest. (Avetisov ¶ 136-138 teaches, recording of information like a transaction to the directed acyclic graph of cryptographic hash pointers is achieved by storing a cryptographic hash digest of the information in node content of the directed acyclic graph of cryptographic hash pointers. Where the transaction record includes cryptographic hash pointers to other transaction records in a hash digest, those other transaction records may also be verified.)
The motive given in Claim 13 is equally applicable to the above claim.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0205868 A1 - METHODS FOR MANAGING VERIFICATION AND VALIDATION OF THIRD-PARTY CODE AND DEVICES THEREOF
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 JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8: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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights