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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 08, 2026 has been entered.
Status of Claims
The Amendment filed on April 08, 2026 has been entered. Claims 2, 11, and 17 were canceled. Claims 1, 10 and 16 were amended. As a result, claims 1, 3-10, 12-16 and 18-23 are pending, of which claims 1, 10 and 16 are in independent form.
Response to Amendment
Applicant’s amendment and arguments regarding the independent claims 1, 10, and 16 obviate the rejection under 35 U.S.C. 101, therefore the 35 U.S.C. 101 rejection is withdrawn.
Applicant’s amendment and arguments regarding the limitation “portions of vulnerability information” of claims 1, 10, and 16 obviate the rejection under 35 U.S.C. 112(b), therefore the 35 U.S.C. 112(b) rejection is withdrawn.
Applicant’s amendment and arguments regarding the limitation “wherein the method is performed by at least one processing device comprising a processor coupled to a memory” of claims 1, 10, and 16 obviate the rejection under 35 U.S.C. 112(b), therefore the 35 U.S.C. 112(b) rejection is withdrawn.
Response to Arguments
Applicant’s argument filed 04/08/2026 have been fully considered but they are not persuasive.
Section 103
On pages 7-11 of remarks, Applicant argues that “the network adapter 314 of VM2 is reporting detected malicious events regarding VM1. Thus, the reported "vulnerability information" is not "regarding" the passthrough network adapter 314”. However, the independent claim 1 does not require that the exchanged vulnerability information identify a vulnerability of the passthrough channel itself. Rather, claim 1 recites exchanged vulnerability information “regarding a passthrough channel between a first component of the at least one component in a first layer of the multi-layer infrastructure stack and a second component…”. Under the broadest reasonable interpretation, information concerning malicious activity or vulnerability communicated through associated with the passthrough channel constitutes information regarding that passthrough channel.
Steinberg expressly discloses a physical passthrough network adapter that permits communication between virtualized resources and external devices. Steinberg further discloses detection of malicious detection of malicious events, exploit indicators (see. Col. 11, lines 26-32), and security related information associated with activity occurring while the virtual machine environment is executing. Thus, Steinberg teaches security related information exchanged in connection with operation of a passthrough communication path. The claims do not require that the vulnerability information describe a defect in the adapter itself.
Further, Applicant argues that network adapter 314 is not a passthrough channel between components is non-adjacent layers is not persuasive. Figure 3 of Steinberg discloses multiple layers including virtual machines, guest operating systems, guest monitor components, a micro-hypervisor, and a virtualization layer. The pass-through network adapter provides communication between sources residing in the virtual machine layer and lower-level hardware/virtualization resources through the hypervisor architecture. Therefore, Steinberg teaches communication across multiple architectural layers, including layers separated by one or more intermediate layers.
Furthermore, the rejection relies on the combined teachings of Steinberg and Viswambharan. teaches obtaining and distributing vulnerability information from vulnerability databases and catalogs throughout a multi-layer infrastructure environment. Steinberg teaches virtualization architectures including virtual machines, host resources, hypervisor functionality, management components, and passthrough devices enabling communication across virtualization boundaries. One of ordinary skill in the art would have recognized that the vulnerability information of Viswambharan could be exchanged through the virtualization and passthrough communication mechanisms thought by Steinberg to identify vulnerabilities associated with components connected through such passthrough paths.
Thus, Applicant’s arguments are not persuasive.
Dependent Claims
As to the dependent claims 3-9, 12-15 and 18-23, these claims remain rejected by virtue of dependency to their independent claims.
Therefore, the examiner maintains the rejection under 35 USC § 103.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1, 3-10, 12-16 and 18-23 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 claim(s) contains 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 subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “deploying a multi-layer infrastructure stack comprising a plurality of layers”.
The non-provisional specification fails to provide written description support for the claim limitation of “deploying a multi-layer infrastructure stack …”. Although the specification may disclose various computing components and system elements (at least some of the functionality of the security vulnerability identification and mitigation process of FIG. 8 may be implemented in a management console that services multiple deployments of a given infrastructure stack (or portions thereof), in paragraph [0083]), the specification, however, fails to describe the act of deploying a multi-layer infrastructure stack, identify the plurality of layers, or explain how the layers are arranged and deployed as an infrastructure stack. Accordingly, the specification does not provide sufficient written description support for the claimed “deploying a multi-layer infrastructure stack comprising a plurality of layers”.
Claim 1 recites “establishing a network connection with at least one vulnerability database to obtain vulnerability information associated with one or more security vulnerabilities for at least one component in a server device”.
The non-provisional specification fails to provide written description support for the claim limitation of “establishing a network connection with at least one vulnerability database …”. Although the specification describes obtaining vulnerability information from external vulnerability feeds and vulnerability database (a protocol can be established where the exchange starts on an operation, and then continues until equilibrium is reached, as would be apparent to a person of ordinary skill in the art, in paragraph [0078]), the specification, however, does not describe establishing a network connection with such database, nor does it disclose any mechanism, process or operation by which the claimed network connection is established. Accordingly, the specification does not provide sufficient written description support for the claimed “establishing a network connection with at least one vulnerability database”.
Claim 1 recites “one or more remedial actions to mitigate the at least one security vulnerability for the one or more components in the server device by updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability”.
The non-provisional specification fails to provide written description support for the claim limitation of “updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability”. Although the specification describes identifying security vulnerabilities and determining remedial actions (The host configuration/monitoring module 410, in one or more embodiments, is configured to perform one or more functions for configuring, updating and/or monitoring one or more of the host computing devices 120 or other devices in the system 100 of FIG. 1 , in paragraph [0055]), the specification, however, does not describe updating a component of the server device as the remedial action. The originally files disclosure does not describe applying alerts, patches, any updates or modifications to a component for mitigating a security vulnerability. Accordingly, the specification does not provide sufficient written description support for the claimed “updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability”.
The independent claim 10 and 16 are similarly rejected. As to the dependent claims 3-9, 12-15 and 18-23, these claims remain rejected by virtue of dependency to their independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-10, 12-16 and 18-23 are rejected under 35 U.S.C. 103 as being unpatentable over Steinberg (US 11,113,086 B1), hereinafter Steinberg in view of Viswambharan et al. (US 2020/0358802 A1), hereinafter Viswambharan.
In regards to claim 1, Steinberg discloses a method, comprising:
deploying a multi-layer infrastructure stack comprising a plurality of layers, wherein each of the plurality of layers comprises one or more infrastructure elements (Steinberg, Fig. 3, Col. 13, Lines 7-13, the first virtual machine 170 transitions from an active state to an inactive state when the second virtual machine 175 is deployed as a separate virtual machine . When the recovery OS 310 is substituted for the guest OS 300 within the first virtual machine 170 , the second virtual machine 175 is effectively the reconfigured first virtual machine 170);
wherein the server device is associated with the multi- layer infrastructure stack (Steinberg, Fig. 1B-3),
exchanging, using one or more passthrough channel data structures the vulnerability information (Steinberg, Col. 3, Lines 12-22, after completion of the boot process, the second virtual machine is capable of driving a physical pass-through network adapter (e.g., physical NIC or software-emulated NIC) to establish a network connection to another computing device for reporting one or more detected malicious events that occurred while the first virtual machine was executing. This reporting may include the transmission of an alert in a message format (e.g., a Short Message Service “SMS” message, Extended Message Service “EMS” message, Multimedia Messaging Service “MMS”, Email, etc.) and (Steinberg, Col. 11, Lines 26-34, the static analysis process 330 may be configured to compare a bit pattern of the object 335 content with a “blacklist” of suspicious exploit indicator patterns. For example, a simple indicator check (e.g., hash) against the hashes of the blacklist (i.e., exploit indicators of objects deemed suspicious) may reveal a match, where a score may be subsequently generated (based on the content) by the threat protection component 376 to identify that the object may include malware) and (Steinberg, Col. 12, Lines 8-15, it is contemplated that the presence of a guest OS anomaly, which may be detected by malware detection processes 302 or malware detection modules/drivers 345 in the guest OS kernel 301, may be detected and reported to the host environment 180 (e.g., guest monitor component 374 and/or threat protection component 376) and/or reporting module 336)), for the at least one component in the server device, among one or more subsets of the plurality of layers(Steinberg, Fig. 3, Col. 12, Lines 8-15, it is contemplated that the presence of a guest OS anomaly, which may be detected by malware detection processes 302 or malware detection modules/drivers 345 in the guest OS kernel 301, may be detected and reported to the host environment 180 (e.g., guest monitor component 374 and/or threat protection component 376) and/or reporting module 336));
wherein the exchanged vulnerability information in the one or more passthrough channel data structures is exchanged between two or more of a virtual resource (Steinberg, Col. 19, Lines 40-50, the guest monitor component 374 transmits at least a portion of the state information to the threat protection component 376, which analyzes the state information to determine whether the state information suggests that the first guest OS is compromised (operations 435-437)) and (Steinberg, Col. 3, Lines 12-18, after completion of the boot process, the second virtual machine is capable of driving a physical pass-through network adapter (e.g., physical NIC or software-emulated NIC) to establish a network connection to another computing device for reporting one or more detected malicious events that occurred while the first virtual machine was executing.), a host processor, a hypervisor and a management controller in different layers of the multi-layer infrastructure stack and comprises vulnerability information, for at least one component in the server device (Steinberg, Fig. 4A), regarding a passthrough channel between a first component of the at least one component in a first layer of the multi-layer infrastructure stack and a second component of the at least one component in a second layer of the multi-layer infrastructure stack, wherein the first and the second layer comprise non- adjacent layers of the multi-layer infrastructure stack (Steinberg, Col. 3, Lines 12-18, after completion of the boot process, the second virtual machine is capable of driving a physical pass-through network adapter (e.g., physical NIC or software-emulated NIC) to establish a network connection to another computing device for reporting one or more detected malicious events that occurred while the first virtual machine was executing) (Steinberg, Col. 19, Lines 9-13, upon receipt of the state information, the master controller component 372 determines, in accordance with the policy rules governing operability of the network adapter (network adapter 304), whether the guest OS 300 has been compromised (operation 405));
Steinberg does not explicitly teach establishing a network connection with at least one vulnerability database to obtain vulnerability information associated with one or more security vulnerabilities for at least one component in a server device, wherein the vulnerability database identifies the one or more security vulnerabilities for one or more of the at least one component associated with the multi- layer infrastructure stack;
identifying, by at least one processing device comprising a processor coupled to a memory, one or more remedial actions to mitigate at least one of the one or more security vulnerabilities using one or more update catalogs that identify at least one remedial action for one or more of the at least one component to mitigate a corresponding security vulnerability; and automatically initiating an execution, by the at least one processing device, of at least one of the one or more remedial actions to mitigate the at least one security vulnerability for the one or more components in the server device by updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability.
However, Viswambharan teaches establishing a network connection with at least one vulnerability database to obtain vulnerability information associated with one or more security vulnerabilities for at least one component in a server device (Viswambharan, Para. 0056, the service mesh 302 may also be in communication with various other external feeds 307, 309… a software vulnerability database cloud consortium 306 may source vulnerability information from various repositories and standards, such as the National Vulnerability Database (NVD), Product Security Incident Response Team (PSIRT), etc., and supply this information on the external feed 307 to the service mesh 302), wherein the vulnerability database identifies the one or more security vulnerabilities for one or more of the at least one component associated with the multi- layer infrastructure stack (Viswambharan, Para. 0019, The operations can include receiving information on one or more software vulnerabilities from one or more external feeds, and identifying, from a services catalog, one or more vulnerable service instances supported by a service mesh, the one or more vulnerable service instances identified as having one or more software vulnerabilities based on the received information, wherein the services catalog comprises data associated with one or more service instances supported by the service mesh);
identifying, by at least one processing device comprising a processor coupled to a memory, one or more remedial actions to mitigate at least one of the one or more security vulnerabilities using one or more update catalogs that identify at least one remedial action for one or more of the at least one component to mitigate a corresponding security vulnerability (Viswambharan, Para. 0080, the SVP 318 may identify a website (e.g., Uniform Resource Locator or “URL”) or remote server location which may have a version with a fix or a patch for the vulnerability available and initiate a download of the fixed version or the patch) and (Viswambharan, Para. 0019, the SVP 318 may implement the following processes detecting vulnerabilities which may affect the service mesh 302. The SVP 318 may monitor the external feeds 307, 309 and consult the services catalog 320 to determine if any vulnerability is reported on the external feeds 307, 309 which may affect one or more services in the services catalog 320. Further, as and when any new services are added in the service mesh 302 or service discovery functions identify new services in the service mesh 302, the SVP 318 may update the services catalog 320); and
automatically initiating an execution, by the at least one processing device, of at least one of the one or more remedial actions to mitigate the at least one security vulnerability for the one or more components in the server device by updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability (Viswambharan, Para. 0067, the SVP 318 may coordinate with the orchestration system 304 if automatic patching of software is supported for the vulnerable services, and if so, the vulnerable service, e.g., the service instance 328 a in the above example may be automatically fixed and restored) and (Viswambharan, Para. 0069, the SVP 318 may perform a service discovery to determine software versions of all the software instances and determine if any of the versions have been updated).
Steinberg and Viswambharan are both considered to be analogues to the claim invention because they are in the same field of assessing one or more security vulnerability within a multi-layer infrastructure stack. Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Steinberg to incorporate the teachings of Viswambharan to include establishing a network connection with at least one vulnerability database to obtain vulnerability information associated with one or more security vulnerabilities for at least one component in a server device (Viswambharan, Para. 0056), wherein the vulnerability database identifies the one or more security vulnerabilities for one or more of the at least one component associated with the multi- layer infrastructure stack (Viswambharan, Para. 0019); identifying, by at least one processing device comprising a processor coupled to a memory, one or more remedial actions to mitigate at least one of the one or more security vulnerabilities using one or more update catalogs that identify at least one remedial action for one or more of the at least one component to mitigate a corresponding security vulnerability (Viswambharan, Para. 0080) and (Viswambharan, Para. 0019); and automatically initiating an execution, by the at least one processing device, of at least one of the one or more remedial actions to mitigate the at least one security vulnerability for the one or more components in the server device by updating at least one of the one or more components in the sever device to mitigate the at least one security vulnerability (Viswambharan, Para. 0067) and (Viswambharan, Para. 0069). Doing so would aid to provide the cloud-native applications to utilize various software services for functions such as load balancing, traffic managing, routing, health monitoring, security policies, service and user authentication, protection against intrusion, distributed denial of service (DDoS) attacks (Viswambharan, Para. 0025).
In regards to claim 3, the combination of Steinberg in view of Viswambharan teaches the method of claim 1, the combination of Steinberg and Viswambharan teaches wherein the vulnerability information for a given security vulnerability identifies, for a given layer of the multi-layer infrastructure stack, one or more of: the one or more of the at least one component associated with the given security vulnerability and an object representation exchanged between boundaries to a next layer of the multi-layer infrastructure stack (Steinberg, Fig. 3, Col. 12, Lines 8-15, it is contemplated that the presence of a guest OS anomaly, which may be detected by malware detection processes 302 or malware detection modules/drivers 345 in the guest OS kernel 301, may be detected and reported to the host environment 180 (e.g., guest monitor component 374 and/or threat protection component 376) and/or reporting module 336)).
In regards to claim 4, the combination of Steinberg in view of Viswambharan teaches the method of claim 3, wherein a given layer of the multi-layer infrastructure stack resolves the one or more of the at least one component associated with the given security vulnerability in the exchanged vulnerability information using one or more universal identifiers of the one or more of the at least one component (Steinberg, Col. 10, Lines 43-51, a web page, email, email attachment, file or universal resource locator. Static analysis may conduct a brief examination of characteristics (internal content) of the object 335 to determine whether it is suspicious, while dynamic analysis may analyze behaviors associated with events that occur during virtual execution of the object 335, especially characteristics involving a network adapter such as a physical pass-through network interface card (NIC) (hereinafter “network adapter”) 304).
In regards to claim 5, the combination of Steinberg in view of Viswambharan teaches the method of claim 1, further comprising determining whether one or more of a communication channel and one or more of the at least one component associated with a given security vulnerability is enabled to determine if the given security vulnerability is exposed (Steinberg, Col. 3, Lines 7-18, the purpose of transitioning from the first virtual machine to the second virtual machine is to provide a clean, uninfected and trustworthy platform environment, given that the second virtual machine was dormant (e.g., pre-boot state and not running) when the malicious attack occurred. After completion of the boot process, the second virtual machine is capable of driving a physical pass-through network adapter (e.g., physical NIC or software-emulated NIC) to establish a network connection to another computing device for reporting one or more detected malicious events that occurred while the first virtual machine was executing).
In regards to claim 6, the combination of Steinberg in view of Viswambharan teaches the method of claim 1, wherein the vulnerability information is separately obtained for each layer of the multi-layer infrastructure stack (Steinberg, Col. 12, Lines 43-46, a portion of the guest OS 300 or operating as a separate module, the guest agent 172 is configured to provide metadata to the virtualization layer 185 in response to at least one selected event).
In regards to claim 7, the combination of Steinberg in view of Viswambharan teaches the method of claim 6, wherein a given layer of the multi-layer infrastructure stack employs one or more corresponding vulnerability catalogs that identify the one or more security vulnerabilities for one or more of the at least one component associated with the given layer (Viswambharan, Para. 0019, the SVP 318 may implement the following processes detecting vulnerabilities which may affect the service mesh 302. The SVP 318 may monitor the external feeds 307, 309 and consult the services catalog 320 to determine if any vulnerability is reported on the external feeds 307, 309 which may affect one or more services in the services catalog 320. Further, as and when any new services are added in the service mesh 302 or service discovery functions identify new services in the service mesh 302, the SVP 318 may update the services catalog 320). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Steinberg to incorporate the teachings of Viswambharan to include wherein a given layer of the multi-layer infrastructure stack employs one or more corresponding vulnerability catalogs that identify the one or more security vulnerabilities for one or more of the at least one component associated with the given layer (Viswambharan, Para. 0019). Doing so would aid to provide the cloud-native applications to utilize various software services for functions such as load balancing, traffic managing, routing, health monitoring, security policies, service and user authentication, protection against intrusion, distributed denial of service (DDoS) attacks (Viswambharan, Para. 0025).
In regards to claim 8, the combination of Steinberg in view of Viswambharan teaches the method of claim 1, wherein the one or more update catalogs identify one or more versions of a given at least one component that address one or more of the security vulnerabilities associated with the given at least one component (Viswambharan, Para. 0057, further, as and when any new services are added in the service mesh 302 or service discovery functions identify new services in the service mesh 302, the SVP 318 may update the services catalog 320 and monitor the external feeds 307, 309 to determine if any new or updated information added to the services catalog 320 may have vulnerabilities reported by the external feeds 307, 309).
Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Steinberg to incorporate the teachings of Viswambharan to include wherein the one or more update catalogs identify one or more versions of a given at least one component that address one or more of the security vulnerabilities associated with the given at least one component (Viswambharan, Para. 0057). Doing so would aid to provide the cloud-native applications to utilize various software services for functions such as load balancing, traffic managing, routing, health monitoring, security policies, service and user authentication, protection against intrusion, distributed denial of service (DDoS) attacks (Viswambharan, Para. 0025).
In regards to claim 9, the combination of Steinberg in view of Viswambharan teaches the method of claim 1, further comprising prioritizing the one or more remedial actions based at least in part on an assessment of a business impact of at least one security vulnerability associated with each remedial action (Viswambharan, Paras. 0059-0060, the numerical score can then be translated into a qualitative representation (e.g., low, medium, high, and critical) to help in assessing and prioritizing the handling of the vulnerability) and (Viswambharan, Para. 0061, The CVE obtained by the SVP 318 may further include a determination of symptoms and remedies associated with the detected vulnerability). Therefore, it would have been obvious to someone ordinary skill in the art before the effective filling date of the claimed invention to have modified Steinberg to incorporate the teachings of Viswambharan to include further comprising prioritizing the one or more remedial actions based at least in part on an assessment of a business impact of at least one security vulnerability associated with each remedial action (Viswambharan, Paras. 0059-0060) and (Viswambharan, Para. 0061). Doing so would aid to provide the cloud-native applications to utilize various software services for functions such as load balancing, traffic managing, routing, health monitoring, security policies, service and user authentication, protection against intrusion, distributed denial of service (DDoS) attacks (Viswambharan, Para. 0025).
In regards to claim 10, the apparatus of claim 10 relates to the method claim 1. Therefore, claim 10 is rejected for the same reason.
In regards to claim 12, the apparatus of claim 12 relates to the method claim 3. Therefore, claim 12 is rejected for the same reason.
In regards to claim 13, the apparatus of claim 13 relates to the method claim 5. Therefore, claim 13 is rejected for the same reason.
In regards to claim 14, the apparatus of claim 14 relates to the method claim 7. Therefore, claim 14 is rejected for the same reason.
In regards to claim 15, the apparatus of claim 15 relates to the method claim 8. Therefore, claim 15 is rejected for the same reason.
In regards to claim 16, the non-transitory processor-readable storage medium of claim 16 relates to the method and apparatus claims 1 and 10. Therefore, claim 16 is rejected for the same reason.
In regards to claim 18, the non-transitory processor-readable storage medium of claim 18 relates to the method and apparatus claims 3 and 12. Therefore, claim 18 is rejected for the same reason.
In regards to claim 19, the non-transitory processor-readable storage medium of claim 19 relates to the method and apparatus claims 7 and 14. Therefore, claim 19 is rejected for the same reason.
In regards to claim 20, the non-transitory processor-readable storage medium of claim 20 relates to the method and apparatus claims 8 and 15. Therefore, claim 20 is rejected for the same reason.
In regards to claim 21, the apparatus of claim 21 relates to the method claim 4. Therefore, claim 21 is rejected for the same reason.
In regards to claim 22, the apparatus of claim 22 relates to the method claim 9. Therefore, claim 22 is rejected for the same reason.
In regards to claim 23, the non-transitory processor-readable storage medium of claim 23 relates to apparatus claim 22. Therefore, claim 23 is rejected for the same reason.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GITA FARAMARZI whose telephone number is (571)272-0248. The examiner can normally be reached Monday- Friday 9:00 am- 6: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, Jorge L. Ortiz-Criado can be reached at (571)272-7624. 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.
/GITA FARAMARZI/Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights