CTNF 18/925,106 CTNF 101867 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Status Claims 1-12 are under examination. Priority 02-26 AIA Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Applicant’s claim to foreign priority to the following foreign application has been acknowledged by the examiner: JP2023-188149 (11/02/2023). Claim Objections 07-29-01 AIA Claim 1 is objected to because of the following informalities: “a asset of the system” should read “an asset of the system” . Appropriate correction is required. 07-30-03-h AIA 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. 07-30-05 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. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not 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 not 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 function without reciting sufficient structure, material or acts to entirely perform the recited function. This application includes one or more claim limitations that do not use the word “means”, but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “input unit that inputs”, “threat scenario generation unit that generates”, “risk level assessment unit that obtains”, “takeover possibility assessment unit that estimates”, “additional threat scenario generation unit that generates”, and “output unit that outputs” in claim 1; “asset extraction unit that obtains”, “a feasibility assessment unit that obtains”, “security countermeasure determination unit that determines”, and “feasibility reassessment unit that obtains” in claim 2; “input unit further inputs” in claim 3; “takeover possibility assessment unit identifies” in claim 5; “additional threat scenario generation unit generates” in claim 6; “impact assessment unit that obtains” and “risk level assessment unit obtains” in claim 7. Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 112(a) The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. Claims 1-7 and 10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications The limitations in claims 1-3 and 5-7 described under the “Claim Interpretation” above section invoke interpretation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. A review of the specification reveals no sufficient structure is disclosed to perform the claimed functions. Thus, the claims are indefinite under 35 U.S.C. 112(b) (see related rejection herein, infra). When functional claim language is found indefinite, it typically lacks an adequate written description under § 112(a), because an indefinite, unbounded functional limitation would cover all ways of performing a function and indicate that the inventor has not provided sufficient disclosure to show possession of the invention. Thus, a 112(b) rejection that is based on functional language having unclear claim boundaries should be accompanied by a rejection under 12(a) based on failure to provide a written description for the claim. Claims 4 and 10 are similarly rejected based on their dependency on claim 1. Claim Rejections - 35 USC § 112(b) 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. Claims 1-7 and 10-12 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, 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. 07-34-23 Regarding claims 1-3 and 5-7, their limitations described under the “Claim Interpretation” section above invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claims are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Applicant may: (a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; (b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)). If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either: (a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181. The dependent claims 4 and 10 inherit this rejection. Regarding claim 11, it recites the limitation “component of scenario” in line 11. There is insufficient antecedent basis for this limitation in the claim as it is unclear whether it refers to the “first scenario” or a different scenario. For examination purposes, “component of scenario” is interpreted as referring to the “first scenario”. Claim 12 is rejected based on its dependency of claim 11. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claim s 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Hovor et al. (US Patent Publication No. 2017/0048266), hereinafter Hovor, in view of Fellows et al. (US Patent Publication No. 2025/0030725), hereinafter Fellows, in view of Hasegawa et al. (US Patent Publication No. 2021/0409434), hereinafter Hasegawa . Regarding claim 11, a security design support device comprising: a processor capable of executing computer program instructions (Hovor ¶127: “The system 600 includes a processor 610, a memory 620, a storage device 630, and an input/output device 640.”) ; and a memory connected to the processor and storing the computer program instructions, wherein the processor, by executing the computer program instructions stored in the memory (Hovor ¶121: “The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.”) , receives system information including information of a system to be analyzed, the system including subsystems (Hovor ¶20: “A system may receive threat data, describing asset vulnerabilities, ways in which those vulnerabilities are exploited, frequencies of exploit utilization and success, and likely paths of compromise, and receive data that defines assets of an entity and which assets provide access to which of the other assets of the entity, e.g., an asset topology.”) , generates a first scenario indicating a potential security attack that occurs using a predetermined component of scenario from the system information and information indicating functions of the subsystems or data held by the subsystems (Hovor ¶21: “The system simulates an attack by determining the probability that a particular asset will be attacked and the probability that an attack will be successful. For instance, the system may select a particular external facing asset, that is connected to an external network or is otherwise accessible to people who do not work for the entity, and determines, using the threat data, the probability that vulnerabilities of the particular external facing asset will be compromised by an adversary.”) , obtains a risk level of the first scenario using a first feasibility, which is feasibility of the first scenario (Hovor ¶21: “The system determines, using the threat data, probabilities that each of those assets will be compromised by an adversary.”) , the risk level of the first scenario being determined based on the first feasibility and impact rating (Hovor ¶45: “The system may analyze the multiple paths each from a different simulation to determine high risk paths, e.g., that have a high probability of occurring given the threat data or occurred most frequently, high risk assets, e.g., that have the highest probability of being compromised, or both.”) , [extracts the first scenario of which the risk level is equal to or higher than a predetermined level], calculates a second feasibility which is feasibility of the first scenario when a countermeasure is implemented against the first scenario (Hovor ¶43: “the system may determine that one or more network security devices, e.g., firewalls, intrusion detection systems, or intrusion prevention systems, should be purchased and installed … to reduce the probability that an asset may be targeted, compromised, or both, by an adversary's device.”) [of which the risk level is equal to or higher than the predetermined level], estimates a takeover possibility, which is possibility that control over the subsystem is obtained, using the second feasibility (Hovor ¶90-91: “The system identifies, using the threat data, one or more vulnerabilities of the first computer asset (408) …the system may determine a probability of compromise for the first computer asset using the vulnerabilities of the first computer asset.”) , generates a second scenario indicating a potential security attack (Hovor ¶95: “The system determines, using the threat data, one or more vulnerabilities of the second computer asset (412)”) that occurs with the subsystem that is taken over as a starting point (Hovor ¶92: “The system determines, using the asset topology and the threat data, a path from the first computer asset to a second computer asset that is one of the second computer assets (410)”) [when the takeover possibility is equal to or higher than a predetermined value], and outputs the first scenario, the risk level, the countermeasure, the takeover possibility, and the second scenario as image data or text data (Hovor ¶104: “The system may generate instructions for presentation of a list of the assets and the corresponding probabilities of compromise in a user interface. The presentation may include information about the paths of compromise used to access each of the assets, e.g., the path with the highest probability of being used, all of the paths, or all of the paths and corresponding probabilities of being used. The instructions may include instructions for presentation of the path information on the same screen in the user interface as the list of the assets or a different screen in the user interface as the list of the assets.”) , but Hovor fails to teach extracts the first scenario of which the risk level is equal to or higher than a predetermined level of which the risk level is equal to or higher than the predetermined level when the takeover possibility is equal to or higher than a predetermined value. However, Fellows teaches extracts the first scenario of which the risk level is equal to or higher than a predetermined level (Fellows ¶113: “The autonomous response engine 140, rather than the human taking the action, is configured to autonomously cause the one or more mitigation actions to be taken to contain the cyber threat when a threat risk parameter from an assessment module in the detection engine is equal to or above an actionable threshold.”) of which the risk level is equal to or higher than the predetermined level (Fellows ¶113: “The autonomous response engine 140, rather than the human taking the action, is configured to autonomously cause the one or more mitigation actions to be taken to contain the cyber threat when a threat risk parameter from an assessment module in the detection engine is equal to or above an actionable threshold.”) when the takeover possibility is equal to or higher than a predetermined value (Fellows ¶113: “The autonomous response engine 140, rather than the human taking the action, is configured to autonomously cause the one or more mitigation actions to be taken to contain the cyber threat when a threat risk parameter from an assessment module in the detection engine is equal to or above an actionable threshold.”) It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hovor in view of Fellows to only proceed with a scenario and takeover simulation when a risk level is higher than a predetermined value to prevent producing an overwhelming number of simulations by avoiding false positives and low impact scenarios (Fellows ¶47: “However, thousands to millions of low level anomalies occur in a domain under analysis all of the time; and thus, most other systems need to set the threshold of trying to detect a cyberattack by a cyber threat at level higher than the low level anomalies examined by the cyber threat analyst module 120 just to not have too many false positive indications of a cyberattack when one is not actually occurring, as well as to not overwhelm a human cyber security analyst receiving the alerts with so many notifications of low level anomalies that they just start tuning out those alerts.”). Hovor and Fellows fail to teach the security design support device evaluates security risk in a vehicle dispatch system. However, Hasegawa teaches the security design support device evaluates security risk in a vehicle dispatch system (Hasegawa ¶26: “The monitoring server 10 is one or more computers that detect the occurrence of an anomaly in the vehicle 20 and analyze contents of the anomaly based on data trans mitted (or uploaded) from the vehicle 20. An example of the anomaly is a network-based cyber-attack against the vehicle 20”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hovor and Fellows to be implemented in a vehicle dispatch system as vehicles and their control can be subjected to cyber-attacks and need cybersecurity solutions in place to prevent malicious actions (Hasegawa ¶3: “With respect to the above, similarly with conventional IT devices, a concern that vehicles and control devices of the vehicles may be subjected to cyber-attacks from malicious attackers as a result of being connected to external networks has been raised.”). Claims 1,8 and 9 and are substantially similar to claim 11 and are rejected under the same rationale. In addition, Hovor teaches claim 1’s an input unit (640 – Fig. 6) a threat scenario generation unit (310 – Fig. 3) a risk level assessment unit (312 – Fig. 3) a takeover possibility assessment unit (312 – Fig. 3) an additional threat scenario generation unit (310 – Fig. 3) an output unit (640 – Fig. 6) Regarding claim 2, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 1, Hovor and Fellows further teach further comprising; at least one of an asset extraction unit that obtains the asset information from the system information (Hovor ¶73: “The cyber-risk system 302 may include a topology generation system 308 that receives an asset inventory and generates the asset topology 306 using the asset inventory and information about how the assets in the asset inventory connect and interact with each other.”) ; a feasibility assessment unit that obtains the first feasibility which is a feasibility of the first threat scenario (Hovor ¶80: “The cyber-risk system 302 includes a trend analysis system 314 that analyzes data from multiple computer-based attack simulations. The data may include the paths generated during the simulations, probabilities of being targeted, probabilities of compromise, vulnerabilities identified, vulnerabilities used during the simulation, e.g., with a highest probability of compromise for an asset, or a combination of these.”) ; a security countermeasure determination unit that determines the necessary countermeasure against the first threat scenario (Hovor ¶43: “the system may determine that one or more network security devices, e.g., firewalls, intrusion detection systems, or intrusion prevention systems, should be purchased and installed … to reduce the probability that an asset may be targeted, compromised, or both, by an adversary's device.”) of which the risk level is equal to or higher than the predetermined level (Fellows, as in claim 11, teaches countermeasure on predetermined level) ; and a feasibility reassessment unit that obtains the second feasibility which is a feasibility of the first threat scenario when the necessary countermeasure is implemented (Hovor ¶97: “The system determines, using the asset topology, a change to the asset topology to reduce the probability that the second computer asset will be compromised by an adversary (416). The system may use the vulnerabilities of the second computer asset to determine the change to the asset topology.”) . Regarding claim 3, Hovor, Fellows, and Hasegawa teach security design support device according to claim 1, Hovor further teaches wherein the input unit further inputs at least one of the asset information, the first feasibility, the necessary countermeasure, and the second feasibility (Hovor ¶82: “The threat data 320 may include, among other types of threat data, exploits 322, incidents 324, and adversary tactics, techniques, and procedures (TTPs) 326.”) . Regarding claim 4, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 1, Hovor further teaches wherein the component of the threat scenario indicating the starting point of a threat is either inside the subsystem or outside the subsystem (Hovor ¶22: “The system determines the probabilities for multiple assets, making a ‘path’ through the assets from the particular external facing asset to a current asset, e.g., an asset currently being analyzed by the system.”) . Regarding claim 5, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 1, Hovor further teaches wherein the takeover possibility assessment unit identifies the first threat scenario that satisfies at least one of a condition that matches a path of the takeover a condition that matches a subjective perception of the takeover, a condition that matches a result of the takeover, and a condition that matches means of the takeover, among the first threat scenario for which the second feasibility is obtained (Hovor 58: “Indicators of compromise (IOC) may include certain observable conditions as well as contextual information about patterns of those observable conditions and how and when a pattern should be acted on … The patterns of the observable conditions may be mapped to related TTP context information, include relevant metadata about confidence in the indicator's assertion, handling restrictions, valid time windows, likely impact, sightings of the information indicator, structured test mechanisms for detection, related campaigns, or suggested COA, or both related TTP context information and relevant metadata.”) , classifies the identified first threat scenario for each subsystem that is the asset targeted by the identified first threat scenarios and obtains the takeover possibility for each subsystem based on the second feasibility of each of first threat scenarios (Hovor ¶21: “The system determines the assets connected to the particular external facing asset and, for each of those assets, may determine probabilities that the assets will be targeted by the adversary. The system determines, using the threat data, probabilities that each of those assets will be compromised by an adversary”) . Regarding claim 6, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 4, Hovor further teaches wherein the additional threat scenario generation unit generates the second threat scenario by rewriting the starting point of the threat in the first threat scenario generated by the threat scenario generation unit to the subsystem that will be taken over (Hovor ¶92: “The system determines, using the asset topology and the threat data, a path from the first computer asset to a second computer asset that is one of the second computer assets (410) … The second computer asset may be an intended destination for the attack simulation, e.g., which may contain data potential adversary may want to access, or may be an end destination on the path, e.g., from which the system cannot access any other assets to which the system did not already gain access when creating the path during the attack simulation.”) . Regarding claim 7, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 1, Hovor further teaches further comprising: an impact rating assessment unit that obtains an impact rating of the asset on risk (Hovor ¶80:“The cyber-risk system 302 includes a trend analysis system 314 that analyzes data from multiple computer-based attack simulations. The data may include the paths generated during the simulations, probabilities of being targeted, probabilities of compromise, vulnerabilities identified, vulnerabilities used during the simulation, e.g. with a highest probability of compromise for an asset, or a combination of these.”) , wherein the risk level assessment unit obtains the risk level of the first threat scenario using the first feasibility and the impact rating (Hovor ¶45: “The system may analyze the multiple paths each from a different simulation to determine high risk paths, e.g. that have a high probability of occurring given the threat data or occurred most frequently, high risk assets, e.g. that have the highest probability of being compromised, or both.”) . Regarding claim 10, Hovor, Fellows, and Hasegawa teach the security design support device according to claim 1, Hovor further teaches further comprising: a processor capable of executing computer program instructions (Hovor ¶121: “The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.”) ; and a memory connected to the processor and storing the computer program instructions (Hovor ¶121: “The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data.”) , wherein by executing the computer program instructions stored in the memory, the processor provides the input unit, the thread scenario generation unit, the risk level assessment unit, the takeover possibility assessment unit, the additional threat scenario generation unit, and the output unit (Hovor ¶117: “Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory program carrier for execution by, or to control the operation of, data processing apparatus.”) , but Hovor fails to teach and the security design support device evaluates security risk in a vehicle dispatch system including a vehicle dispatch server, a smartphone, and a vehicle management server as subsystem. However, Hasegawa teaches and the security design support device evaluates security risk in a vehicle dispatch system including a vehicle dispatch server (Hasegawa ¶25: “The service providing server 30a, the service providing server 30, and the like (which will be hereinafter referred to as the ‘service providing server 30’ if they are not distinguished) are one or more computers that provide a predetermined service, to the vehicle 20”) , a smartphone (Hasegawa ¶86: “the present embodiment may be applied to … a communication terminal (e.g. , a smartphone and a tablet terminal , and a device generally referred to as an Internet of Things ( IoT ) device”) , and a vehicle management server as subsystem (Hasegawa ¶26: “The monitoring server 10 is one or more computers that detect the occurrence of an anomaly in the vehicle 20 and analyze contents of the anomaly based on data trans mitted ( or uploaded ) from the vehicle 20.”) . It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Hovor and Fellows to be implemented in a vehicle dispatch system as vehicles and their control can be subjected to cyber-attacks and need cybersecurity solutions in place to prevent malicious actions (Hasegawa ¶3: “With respect to the above, similarly with conventional IT devices, a concern that vehicles and control devices of the vehicles may be subjected to cyber-attacks from malicious attackers as a result of being connected to external networks has been raised.”). Claim 12 is substantially similar to claim 10 and is rejected under the same rationale. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEC ANKRUM whose telephone number is (571)272-9209. The examiner can normally be reached M-F 7:15am-3:15pm. 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, Ali Shayanfar can be reached at 571-270-1050. 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. /A.C.A./Examiner, Art Unit 2434 /NOURA ZOUBAIR/Primary Examiner, Art Unit 2434 Application/Control Number: 18/925,106 Page 2 Art Unit: 2434
Prosecution Insights