Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Office Action is in response to the Reply filed by Applicant on 4/27/2026. Claims 22 and 23 we added as New. Claims 1-23 are pending. This Office Action is Final.
Response to Arguments
A) Applicant argues Kanso fails to disclose, teach or even suggest “detecting a plurality of entities deployed in a cloud computing environment, wherein each entity of the plurality of entities is distinct and is one of a resource and a principal; inspecting each entity of the plurality of entities for a cybersecurity object, wherein the cybersecurity object indicates a cybersecurity issue,” as recited in claim 1 and similarly recited in claims 10 and 11. Examiner respectfully disagrees.
Examiner submits the Kanso teaches the limitations above. Kanso, Paragraph 0112 recites “At 1302, computer-implemented method 1300 can comprise examining (e.g., via vulnerability risk assessment system 102 and/or inspection component 108), using a processor (e.g., processor 106), the vulnerability of a vulnerable computing resource component (e.g., vulnerable pod 506a) in a network (e.g., system 500, cloud computing environment 950, and/or another network).” Kanso, Paragraph 0034 recites “For example, as described in detail below, vulnerability risk assessment system 102 can facilitate (e.g., via processor 106): inspecting a set of container images respectively associated with pods; identifying a first subset of the pods that contain a vulnerability; classifying the first subset of the pods as primary-infected pods; generating a first list of namespaces in which the primary-infected pods are deployed within a network; checking network policies in connection with the first list of namespaces to determine secondary-suspect pods that have ability to communicate with the primary-infected pods; generating a list of secondary-suspect namespaces in which the secondary-suspect pods are deployed within the network; identifying one or more secondary-suspect pods that communicated with one or more primary-infected pods; and/or generating a list of secondary-infected pods.”
Kanso is further describing how the system is inspecting a plurality of entities, in this case inspecting a set of container images respectively associated with pods and where the vulnerable computing resource is e.g., the number of container images. While Kanso is using different terminology its system is inspecting a plurality of entities, which are container images, and which will inspect each image and each image is related to determining a vulnerability in a computing resource. As a result, Kanso teaches the limitations argued above.
B) Applicant argues Danino fails to disclose, teach or even suggest “generating an inspection plan based on a result of inspecting each entity of the plurality of entities, wherein the result includes detecting a cybersecurity object on at least an entity of the plurality of entities; inspecting the cloud computing environment based on the inspection plan to detect the cybersecurity object and initiating a remediation action in the cloud computing environment in response to detecting the cybersecurity object on the at least an entity of the cloud computing environment, wherein the remediation action resolves the cybersecurity issue,” as recited in claim 1 and similarly recited in claims 10 and 11. Examiner respectfully disagrees.
Examiner submits the Danino teaches the limitations above. Applicant is arguing that Danino does not teach generating an inspection plan. While Danino does not explicitly use the term inspection plan, Danino Paragraph 0371 recites “The process 3300 can further include wherein the one or more remediation recommendations each includes a step-by-step list of actions required to resolve the risky configurations and risky activities. The generating one or more remediation recommendations can be performed by a trained Large Language Model (LLM). The steps can further include collecting data, wherein the data includes cloud provider documentation and cloud security system documentation; and training the LLM with the collected data. A different LLM can be trained for each tenant of a cloud-based system. The steps can further include periodically collecting updated data; and retraining the LLM with the updated data. The one or more remediation recommendations can be provided via a Command Line Interface (CLI) command. The one or more remediation recommendations can be generated based on one or more generic remediations generated by a Cloud-Native Application Protection Platform (CNAPP) system. The steps can further include performing actions associated with the one or more remediation recommendations automatically.” It is here where Danino is teaches remediation recommendations, which the Examiner has interpreted to read on the term “inspection plan.” The remediation recommendations are provided to the administrators for protecting a cloud environment.
As a result, Danino teaches the limitations argued above.
C) Applicant's arguments, regarding the dependent claims, have been fully considered but they are not persuasive. The independent claims are still rejected under 35 USC 103 therefore the 103 rejections of the dependent claims remain rejected as well.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 2, 4, 5, 8, 10, 11, 12, 14, 15, 18 and 20-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kanso et al. (US 2022/0131888) in view of Danino (US 2025/0211551).
As per claim 1, Kanso teaches a method for inspecting a cloud computing environment for cybersecurity issues based on constraints, comprising: detecting a plurality of entities deployed in a cloud computing environment, wherein each entity of the plurality of entities is distinct and is one of a resource and a principal; inspecting each entity of the plurality of entities for a cybersecurity object, wherein the cybersecurity object indicates a cybersecurity issue (Kanso, Paragraph 0112 recites “At 1302, computer-implemented method 1300 can comprise examining (e.g., via vulnerability risk assessment system 102 and/or inspection component 108), using a processor (e.g., processor 106), the vulnerability of a vulnerable computing resource component (e.g., vulnerable pod 506a) in a network (e.g., system 500, cloud computing environment 950, and/or another network). For example, for a particular vulnerability, vulnerability risk assessment system 102 and/or inspection component 108 can examine a vulnerability description and/or corresponding CVE score available on the National Vulnerability Database (NVD).”).
But fails to teach generating an inspection plan based on a result of inspecting each entity of the plurality of entities, wherein the result includes detecting a cybersecurity object on at least an entity of the plurality of entities; inspecting the cloud computing environment based on the inspection plan to detect the cybersecurity object and initiating a remediation action in the cloud computing environment in response to detecting the cybersecurity object on the at least an entity of the cloud computing environment, wherein the remediation action resolves the cybersecurity issue.
However, in an analogous art Danino teaches generating an inspection plan based on a result of inspecting each entity of the plurality of entities, wherein the result includes detecting a cybersecurity object on at least an entity of the plurality of entities; inspecting the cloud computing environment based on the inspection plan to detect the cybersecurity object and initiating a remediation action in the cloud computing environment in response to detecting the cybersecurity object on the at least an entity of the cloud computing environment, wherein the remediation action resolves the cybersecurity issue (Danino, Paragraph 0370 recites “FIG. 33 is a flow chart of a process 3300 for utilizing an LLM for generating detailed remediation recommendations for cloud alerts. The process 3300 includes scanning a cloud environment for posture control data (step 3302); generating one or more alerts related to any of risky configurations and risky activities associated with the cloud environment (step 3304); generating one or more remediation recommendations based on the one or more alerts (step 3306); and providing the one or more alerts and the one or more remediation recommendations to administrators of the cloud environment (step 3308).” And Paragraph 0371 recites “The process 3300 can further include wherein the one or more remediation recommendations each includes a step-by-step list of actions required to resolve the risky configurations and risky activities. The generating one or more remediation recommendations can be performed by a trained Large Language Model (LLM). The steps can further include collecting data, wherein the data includes cloud provider documentation and cloud security system documentation; and training the LLM with the collected data. A different LLM can be trained for each tenant of a cloud-based system. The steps can further include periodically collecting updated data; and retraining the LLM with the updated data. The one or more remediation recommendations can be provided via a Command Line Interface (CLI) command. The one or more remediation recommendations can be generated based on one or more generic remediations generated by a Cloud-Native Application Protection Platform (CNAPP) system. The steps can further include performing actions associated with the one or more remediation recommendations automatically. The posture control data can include any of assets, identities, network flow logs, activities, and code repositories in the cloud environment, wherein the one or more alerts correspond to risks associated therewith.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Danino’s Systems And Methods For Cloud Security System Assistance Utilizing Custom Large Language Models (LLMs) with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of providing global policy and configuration as well as real-time analytics.
As per claim 2, Kanso in combination with Danino teaches the method of claim 1, Danino further teaches generating the inspection plan based on a cybersecurity risk detecting during a first inspection of the cloud computing environment (Danino, Paragraph 0370 recites “FIG. 33 is a flow chart of a process 3300 for utilizing an LLM for generating detailed remediation recommendations for cloud alerts. The process 3300 includes scanning a cloud environment for posture control data (step 3302); generating one or more alerts related to any of risky configurations and risky activities associated with the cloud environment (step 3304); generating one or more remediation recommendations based on the one or more alerts (step 3306); and providing the one or more alerts and the one or more remediation recommendations to administrators of the cloud environment (step 3308).” And Paragraph 0371 recites “The process 3300 can further include wherein the one or more remediation recommendations each includes a step-by-step list of actions required to resolve the risky configurations and risky activities. The generating one or more remediation recommendations can be performed by a trained Large Language Model (LLM). The steps can further include collecting data, wherein the data includes cloud provider documentation and cloud security system documentation; and training the LLM with the collected data. A different LLM can be trained for each tenant of a cloud-based system. The steps can further include periodically collecting updated data; and retraining the LLM with the updated data. The one or more remediation recommendations can be provided via a Command Line Interface (CLI) command. The one or more remediation recommendations can be generated based on one or more generic remediations generated by a Cloud-Native Application Protection Platform (CNAPP) system. The steps can further include performing actions associated with the one or more remediation recommendations automatically. The posture control data can include any of assets, identities, network flow logs, activities, and code repositories in the cloud environment, wherein the one or more alerts correspond to risks associated therewith.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Danino’s Systems And Methods For Cloud Security System Assistance Utilizing Custom Large Language Models (LLMs) with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of providing global policy and configuration as well as real-time analytics.
As per claim 4, Kanso in combination with Danino teaches the method of claim 1, Kanso further teaches inspecting each entity of the plurality of entities for a plurality of cybersecurity objects (Kanso, Paragraph 0112 recites “At 1302, computer-implemented method 1300 can comprise examining (e.g., via vulnerability risk assessment system 102 and/or inspection component 108), using a processor (e.g., processor 106), the vulnerability of a vulnerable computing resource component (e.g., vulnerable pod 506a) in a network (e.g., system 500, cloud computing environment 950, and/or another network). For example, for a particular vulnerability, vulnerability risk assessment system 102 and/or inspection component 108 can examine a vulnerability description and/or corresponding CVE score available on the National Vulnerability Database (NVD).”).
As per claim 5, Kanso in combination with Danino teaches the method of claim 4, Danino further teaches generating the inspection plan to inspect a portion of the entities of the plurality of entities for a portion of the plurality of cybersecurity objects at a first time (Danino, Paragraph 0370 recites “FIG. 33 is a flow chart of a process 3300 for utilizing an LLM for generating detailed remediation recommendations for cloud alerts. The process 3300 includes scanning a cloud environment for posture control data (step 3302); generating one or more alerts related to any of risky configurations and risky activities associated with the cloud environment (step 3304); generating one or more remediation recommendations based on the one or more alerts (step 3306); and providing the one or more alerts and the one or more remediation recommendations to administrators of the cloud environment (step 3308).” And Paragraph 0371 recites “The process 3300 can further include wherein the one or more remediation recommendations each includes a step-by-step list of actions required to resolve the risky configurations and risky activities. The generating one or more remediation recommendations can be performed by a trained Large Language Model (LLM). The steps can further include collecting data, wherein the data includes cloud provider documentation and cloud security system documentation; and training the LLM with the collected data. A different LLM can be trained for each tenant of a cloud-based system. The steps can further include periodically collecting updated data; and retraining the LLM with the updated data. The one or more remediation recommendations can be provided via a Command Line Interface (CLI) command. The one or more remediation recommendations can be generated based on one or more generic remediations generated by a Cloud-Native Application Protection Platform (CNAPP) system. The steps can further include performing actions associated with the one or more remediation recommendations automatically. The posture control data can include any of assets, identities, network flow logs, activities, and code repositories in the cloud environment, wherein the one or more alerts correspond to risks associated therewith.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Danino’s Systems And Methods For Cloud Security System Assistance Utilizing Custom Large Language Models (LLMs) with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of providing global policy and configuration as well as real-time analytics.
As per claim 8, Kanso in combination with Danino teaches the method of claim 1, Danino further teaches generating a representation of the cloud computing environment in a security database; associating a representation of each entity of the plurality of entities with a representation of a detected cybersecurity object in the security database; and store a result of the inspection of the computing environment, based on the inspection plan, in the security database, wherein the result relates to an entity of the plurality of entities (Danino, Paragraph 0125 recites “FIG. 22 is a flow chart of a process 2200 for agentless vulnerability scanning. The process 2200 includes creating a snapshot of a workload in a cloud environment (step 2202); analyzing workload data from the snapshot to identify one or more characteristics of the workload (step 2204); identifying vulnerabilities present in the workload by correlating the one or more characteristics of the workload (step 2206); and persisting the identified vulnerabilities in a database (step 2208).”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Danino’s Systems And Methods For Cloud Security System Assistance Utilizing Custom Large Language Models (LLMs) with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of providing global policy and configuration as well as real-time analytics.
Regarding claims 10 and 11, claims 10 and 11 are directed to a non-transitory computer readable medium and a system associated with the method of claim 1. Claims 10 and 11 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Regarding claim 12, claim 12 is directed to a similar method associated with the method of claim 2 respectively. Claim 12 is similar in scope to claim 2, respectively, and are therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a similar method associated with the method of claim 4 respectively. Claim 14 is similar in scope to claim 4, respectively, and are therefore rejected under similar rationale.
Regarding claim 15, claim 15 is directed to a similar method associated with the method of claim 5 respectively. Claim 15 is similar in scope to claim 5, respectively, and are therefore rejected under similar rationale.
Regarding claim 18, claim 18 is directed to a similar method associated with the method of claim 8 respectively. Claim 18 is similar in scope to claim 8, respectively, and are therefore rejected under similar rationale.
As per claim 20, Kanso in combination with Danino teaches the method of claim 1, Kanso further teaches wherein the cloud computing environment is deployed on a cloud computing infrastructure (Kanso, Paragraph 0112 recites “At 1302, computer-implemented method 1300 can comprise examining (e.g., via vulnerability risk assessment system 102 and/or inspection component 108), using a processor (e.g., processor 106), the vulnerability of a vulnerable computing resource component (e.g., vulnerable pod 506a) in a network (e.g., system 500, cloud computing environment 950, and/or another network). For example, for a particular vulnerability, vulnerability risk assessment system 102 and/or inspection component 108 can examine a vulnerability description and/or corresponding CVE score available on the National Vulnerability Database (NVD).”).
As per claim 21, Kanso in combination with Danino teaches the method of claim 1, Kanso further teaches wherein inspecting each entity of the plurality of entities for a cybersecurity object further comprises inspecting an inspectable disk derived from each respective entity being inspected (Kanso, Paragraph 0047 recites “Resource component 204 can determine total resource capacity that respective infected containers associated with the primary-infected pods and the secondary-infected pods have ability to consume to generate a total-capacity-at-risk measure. For example, resource component 204 can calculate the total capacity for each computing resource that the infected containers in the primary and secondary-infected pods can consume. To calculate the total capacity for each computing resource that the infected containers in the primary and secondary-infected pods can consume, resource component 204 can assess bounded capacity of each of such computing resource. For instance, resource component 204 can assess bounded capacity of at least one of: processor, memory, or disk. Resource component 204 can perform the above described total capacity calculation based on the assumption that unbounded containers can consume the total machine capacity of a computing resource or the total computing resource itself (e.g., in the case of a remote disk not on the machine). In these examples, based on performing the above described total capacity calculation for each infected container in the primary and secondary-infected pods, resource component 204 can thereby produce a total-capacity-at-risk measure.”)
As per claim 22, Kanso in combination with Danino teaches the method of claim 1, Kanso further teaches wherein the inspection plan includes a list of identifiers of resources which as inspected (Kanso, Paragraph 0006 recites “and a network component that checks network policies in connection with the first list of namespaces to determine secondary-suspect pods that have ability to communicate with the primary-infected pods, wherein the namespace component generates a list of secondary-suspect namespaces in which the secondary-suspect pods are deployed within the network, the network component identifies one or more secondary-suspect pods that communicated with one or more primary-infected pods, and wherein the inspection component generates a list of secondary-infected pods. An advantage of such a system is that it can protect one or more computing resources in the network.”).
As per claim 23, Kanso in combination with Danino teaches the method of claim 1, Kanso further teaches wherein the inspection plan further includes an indicator for an inspector which determines which resource is inspected and for which cybersecurity object the resource is inspected (Kanso, Paragraph 0066 recites “Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.”).
Claim(s) 3, 9, 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kanso et al. (US 2022/0131888) and Danino (US 2025/0211551) and in further in view of Biswas (US 2015/0127829).
As per claim 3, Kanso in combination with Danino teaches the method of claim 1, but fails to teach generating the inspection plan to inspect a resource of a first type at a first frequency; and generating the inspection plan to inspect a resource of a second type at a second frequency.
However, in an analogous art Biswas teaches generating the inspection plan to inspect a resource of a first type at a first frequency; and generating the inspection plan to inspect a resource of a second type at a second frequency (Biswas, Paragraph 0043 recites “App A uses your location data. The app collects this data by accessing satellite based positioning resources on your phone. The resources are accessed with frequency F. The accessed data is only stored locally on your phone. The collected location data is used to infer your location in real-time. The app uses stored historical location data to infer your movement patterns, frequently visited places (e.g., office, home, etc.), etc. Although the example use case described above pertains to a mapping process for a `Location` data type, in one embodiment, it is contemplated that the mapping process for other data types such as contacts, content, etc. can be performed by the system 100 in the same manner. In one embodiment, the system 100 can also cause, at least in part, a mapping of the one or more invocation characteristics (e.g., frequency of access) determined by the system 100 from the one or more simulation results against one or more policy templates to cause, at least in part, a generation of at least one policy for the relative application code.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Biswas’ Method and apparatus for transforming application access and data storage details to privacy policies with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of creating a plan on accesses frequency is a good measure to determine vulnerabilities in a system.
As per claim 9, Kanso in combination with Danino teaches the method of claim 1, but fails to teach generating the inspection plan based on a cybersecurity risk constraint and a resource constraint.
However, in an analogous art Biswas teaches generating the inspection plan based on a cybersecurity risk constraint and a resource constraint (Biswas, Paragraph 0043 recites “App A uses your location data. The app collects this data by accessing satellite based positioning resources on your phone. The resources are accessed with frequency F. The accessed data is only stored locally on your phone. The collected location data is used to infer your location in real-time. The app uses stored historical location data to infer your movement patterns, frequently visited places (e.g., office, home, etc.), etc. Although the example use case described above pertains to a mapping process for a `Location` data type, in one embodiment, it is contemplated that the mapping process for other data types such as contacts, content, etc. can be performed by the system 100 in the same manner. In one embodiment, the system 100 can also cause, at least in part, a mapping of the one or more invocation characteristics (e.g., frequency of access) determined by the system 100 from the one or more simulation results against one or more policy templates to cause, at least in part, a generation of at least one policy for the relative application code.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Biswas’ Method and apparatus for transforming application access and data storage details to privacy policies with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of creating a plan on accesses frequency is a good measure to determine vulnerabilities in a system.
Regarding claim 13, claim 13 is directed to a similar method associated with the method of claim 3 respectively. Claim 13 is similar in scope to claim 3, respectively, and are therefore rejected under similar rationale.
Regarding claim 19, claim 19 is directed to a similar method associated with the method of claim 9 respectively. Claim 19 is similar in scope to claim 9, respectively, and are therefore rejected under similar rationale.
Claim(s) 6, 7, 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kanso et al. (US 2022/0131888) and Danino (US 2025/0211551) and in further view of Cristina et al. (US 2021/0258151).
As per claim 6, Kanso in combination with Danino teaches the method of claim 1, but fails to teach generating the inspection plan based on a resource constraint.
However, in an analogous art Cristina teaches generating the inspection plan based on a resource constraint (Cristina, Paragraphs 0037 and 0039 recites “According to the invention, there is provided a method of controlling a communications device to operate according to a prescribed policy, wherein an encryption server remote from the device selects a respective encryption policy for each of one or more applications running on the device and generates an encryption agent for transmission to the device for deployment, the agent being configured to control the device to encrypt data according to the encryption policies selected by the encryption server according to the application that is to process the data. This allows encryption types and key lengths to be set for individual applications based on the type of IoT device and applications being run….Embodiments of the invention provide adjustment due to resource usage (CPU, bandwidth, battery etc), data sensitivity, external events and notifications of vulnerabilities to device type and applications used, in order to allocate resources more efficiently.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Cristina’s dynamic data encryption with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of creating a plan based on resource usage is a good measure to determine vulnerabilities in a system.
As per claim 7, Kanso in combination with Danino and Cristina teaches the method of claim 6, Cristina further teaches wherein the resource constraint is based on any one of: processor utilization, storage utilization, network bandwidth utilization, and any combination thereof (Cristina, Paragraphs 0037 and 0039 recites “According to the invention, there is provided a method of controlling a communications device to operate according to a prescribed policy, wherein an encryption server remote from the device selects a respective encryption policy for each of one or more applications running on the device and generates an encryption agent for transmission to the device for deployment, the agent being configured to control the device to encrypt data according to the encryption policies selected by the encryption server according to the application that is to process the data. This allows encryption types and key lengths to be set for individual applications based on the type of IoT device and applications being run….Embodiments of the invention provide adjustment due to resource usage (CPU, bandwidth, battery etc), data sensitivity, external events and notifications of vulnerabilities to device type and applications used, in order to allocate resources more efficiently.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Cristina’s dynamic data encryption with Kanso’s context based risk assessment of a computing resource vulnerability because it offers the advantage of creating a plan based on resource usage is a good measure to determine vulnerabilities in a system.
Regarding claim 16, claim 16 is directed to a similar method associated with the method of claim 6 respectively. Claim 16 is similar in scope to claim 6, respectively, and are therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a similar method associated with the method of claim 7 respectively. Claim 17 is similar in scope to claim 7, respectively, and are therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached on 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/ Primary Examiner, Art Unit 2439
Prosecution Insights