CTNF 19/015,224 CTNF 88883 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. 12-151 AIA 26-51 12-51 Status of Claims Claims 12-21 are pending. Information Disclosure Statement The information disclosure statement (IDS) submitted on 3/6/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 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. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. 07-30-06 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: “A honeypot generation device, configured to generate a honeypot” in claim 8. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/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 this/these limitation(s) 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 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-23 Claim limitation “A honeypot generation device, configured to generate a honeypot” invokes 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. While the specification describes functional structure which comprises the “honeypot generation device” (e.g. page 11 line 6-15), the structure described in the specification does not perform the entire function in the claim. Therefore, claim 20 is indefinite and is 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. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 8 recites “a honeypot creating device, configured to create a honeypot”. However, despite being claimed as an apparatus, no hardware is described as part of the device. Further, the claim does not appear to be a process, manufacture, or composition of matter. To correct this, the examiner suggests incorporating an element of hardware which the device comprises, such as a memory or hardware processor. 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-21-aia AIA Claim (s) 12-17, 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo et al (PGPUB 2019/0081980), and further in view of Ismael et al (US 9,367,681) . Regarding Claims 12, 20, and 21: Luo teaches a method for generating a honeypot, a non-transitory computer-readable medium on which are stored commands for generating a honeypot, the commands, when executed by a processor, causing the processor to perform steps, and a honeypot generation device configured to generate a honeypot, the honeypot generation device configured to: send messages to a target system ([0051] a first step to build an intelligent-interaction IoT honeypot is to collect responses from all types of IoT devices; fortunately, from the Internet, we can generally find all/many of the physical IoT devices that are accessible; therefore, we designed and implemented a module, IoT-Scanner (e.g., IoTScanner 116 as shown in FIG. 1), to actively probe the IoT devices (i.e., the physical IoT devices) on the Internet and collect their responses to several of the requests we have captured from the honeypot; scanned results can be stored in the central database (e.g., IoT Oracle database 104 as shown in FIG. 1) as the ‘raw’ knowledge for the further learning procedure) ; observe responses of the target system to the messages ([0051] we designed and implemented a module, IoT-Scanner (e.g., IoTScanner 116 as shown in FIG. 1), to actively probe the IoT devices (i.e., the physical IoT devices) on the Internet and collect their responses to several of the requests we have captured from the honeypot; scanned results can be stored in the central database (e.g., IoT Oracle database 104 as shown in FIG. 1) as the ‘raw’ knowledge for the further learning procedure) ; generate, according to the observed responses of the target system, a state machine model for one or more interfaces of the target system ([0085] with the help of IoTScanner (e.g., shown as IoTScanner 116 in FIG. 1), our honeypot can reply by sending a valid response to a client based on the received request instead of responding to the fixed one; in this section, we discuss how to leverage a Markov decision process model to optimize the response selection with the maximal possibility to capture attacks; [0089] in some embodiments, we first randomly select the response from the candidate pool and record the next move from client side; we assume if we happen to select the correct one, attackers will believe our honeypot is the vulnerable target IoT device, and they continue to send the malicious payload (e.g. injected command); therefore, we store each transaction in a session table, and leverage machine learning techniques (MLT) to extract the correct behaviors from the dataset; [0090] FIG. 5 illustrates an architecture of the IoTLearner module in accordance with some embodiments; specifically, the architecture of the IoTLearner module is depicted in FIG. 5 to fetch raw responses 110 from the database 104 and record each transaction to the database 104; [0091] each decision that is made by the selection engine creates a new transaction to extend the current session; all of the session information is stored in the session table (e.g., shown as session info 108 of FIG. 1); [0121] FIG. 6 is a visualization of building a Markov decision process (MDP) state graph from a session table in accordance with some embodiments; in this example, we will use the real world example to explain how we build MDP and calculate the probabilities for each response) ; ascertain, for each one or more known vulnerabilities, a corresponding chain of states of the state machine model that, when followed, makes it possible to exploit the vulnerability ([0107] in our context, the immediate reward r(x.sub.t, a.sub.t) reflects the progress we have made during the interaction process when we choose response a.sub.t to request x.sub.t and we move to the next state x.sub.t+1; since the progress can be either negative or positive, the reward function can be negative or positive as well; the heuristics of defining reward is that if the response a is the target device type expected by the attacker and the attack launch the attack by sending the exploit code in the next request, the reward must be positive and huge; on the contrary, if the response is not an expected one (e.g., reflects a is not a vulnerable device version), the attacker may stop the attack and end the session; this leads to the dead end state, and causes the negative reward; in other words, we reward the responses that could lead us to the final attack packet, and punish the ones that lead to the dead end session; [0108] one of our designs is to assign reward as a value equals to the length of the final sessions, since we believe the longer request sent by the attackers, the higher chance the malicious payload is contained; the standard session is two which means after we send our response, there is at least another incoming request from the same IP at the same port; if no further transition is observed, we assign a negative reward for that response; other alternative reward assignments could be based on whether we receive some known exploits packets or not) ; and generate a honeypot that responds to messages according to the state machine model ([0090] FIG. 5 illustrates an architecture of the IoTLearner module in accordance with some embodiments; specifically, the architecture of the IoTLearner module is depicted in FIG. 5 to fetch raw responses 110 from the database 104 and record each transaction to the database 104; every incoming request to the honeypot is forwarded to this module, and the selected response is returned to the client based on the Req_Rsp Mapping 508; a core part of the module is a selection engine shown as a selector component 504, which normalizes the request and fetches the potential responses list 110 from the scanning result; in MDP selection mode (as further described below), it first locates the state in the graph from the normalized request using a state locator component 502, and followed by the model to select the best response) . Luo does not explicitly teach removing, for each of the one or more vulnerabilities, at least one state of the corresponding chain from the state machine model. However, Ismael teaches the concept of removing, for each of one or more vulnerabilities, at least one state of a corresponding chain from a state machine model ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application, the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function and determines that such states should be modified to remove or otherwise squelch this ability) . It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the state removal teachings of Ismael with the honeypot creation teachings of Luo, in order to create a robust, high-interaction honeypot which stalls, inhibits, or distracts malicious agents for increasing amounts of time, allowing for the malicious agents to be redirected, monitored, identified, blacklisted, etc., while preventing avenues of attack and system destabilization by pruning vulnerable states, thereby maximizing utility and security while minimizing risk. Regarding Claim 13: Luo in view of Ismael teaches the method according to claim 12. In addition, Ismael teaches wherein, for each of the one or more vulnerabilities, a state is ascertained in the corresponding chain of states and removed from the state machine model, which prevents the vulnerability from being exploited, wherein a state that is as far back as possible in the chain of states, but, upon reaching of which, damage is not yet caused, is ascertained as the state ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application, the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function and determines that such states should be modified to remove or otherwise squelch this ability) . The rationale to combine Luo and Ismael is the same as provided for claim 12, due to the overlapping subject matter between claims 12 and 13. Regarding Claim 14: Luo in view of Ismael teaches the method according to claim 12. In addition, Ismael teaches wherein, for each of the one or more vulnerabilities, a state upon reaching of which communication with a third-party system is carried out is ascertained in the corresponding chain of states and removed from the state machine model ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application (i.e. “communication with a third-party system”), the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function (i.e. “communication with a third-party system)) and determines that such states should be modified to remove or otherwise squelch this ability) . The rationale to combine Luo and Ismael is the same as provided for claim 12, due to the overlapping subject matter between claims 12 and 14. Regarding Claim 15: Luo in view of Ismael teaches the method according to claim 12. In addition, Luo teaches wherein the state machine model is generated by adapting a previously generated other state machine model for another target system according to the observed responses of the target system ([0044] in this example implementation, there are four major components running separately but sharing the data to each other during the learning process; IoT-Oracle 104 is a central database that stores information that we obtained regarding the IoT devices; a honeypot module includes honeypot instances 102a-c that we deployed on Amazon AWS and Digital Ocean; the honeypot instances receive the traffic of attack and interact with attackers to allure them to perform the real exploitation; they will periodically synchronize with IoT-Oracle 104 to push newly received raw requests to the table raw request 106 associated with the session information stored in the session information table 108, and retrieve the IoT knowledge table 112 for up-to-date knowledge information of IoT devices; EXAMINER’S NOTE: previous honeypot instances (i.e. “state machine models”) are therefore used to update future honeypot models ) . Regarding Claim 16: Luo in view of Ismael teaches the method according to claim 15. In addition, Luo teaches wherein the other state machine model is generated by sending the requests and/or other requests to the other target system, observing responses of the other target system to the requests or the other requests, and generating the other state machine model according to the observed responses of the other target system ([0044] as above, honeypot instances are used to update honeypot instances with up-to-date knowledge information of IoT devices; [0045] the module, IoTScanner 116, which includes a filter 118, leverages captured attack's requests as the seed knowledge, and scans the Internet 128 to perform active probing (126) for any IoT devices that can respond to these requests; the collected responses will be stored in the table raw response 110 for further analysis; the module, IoTLearner 120, which includes an IoT-ID component 122 and machine learning (ML) component 124, utilizes a machine learning algorithm to train a model based on the feedback (114) from attackers with given responses; after several round of learning iterations, our high-interaction IoT honeypot can optimize a model to reply to attackers (e.g., nefarious actors/hackers targeting IoT devices)) . Regarding Claim 17: Luo in view of Ismael teaches the method according to claim 15. In addition, Luo teaches wherein the adapting of the other state machine model includes adapting, according to the observed responses of the target system, a version of the one or more interfaces whose behavior is modeled by the other state machine model ([0044] as above, honeypot instances are used to update honeypot instances with up-to-date knowledge information of IoT devices; [0045] the module, IoTScanner 116, which includes a filter 118, leverages captured attack's requests as the seed knowledge, and scans the Internet 128 to perform active probing (126) for any IoT devices that can respond to these requests; the collected responses will be stored in the table raw response 110 for further analysis; the module, IoTLearner 120, which includes an IoT-ID component 122 and machine learning (ML) component 124, utilizes a machine learning algorithm to train a model based on the feedback (114) from attackers with given responses; after several round of learning iterations, our high-interaction IoT honeypot can optimize a model to reply to attackers (e.g., nefarious actors/hackers targeting IoT devices); [0048], [0062]-[0063], [0078], [0133] HTTP protocol) . 07-21-aia AIA Claim (s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Ismael, and further in view of Sharifi Mehr (US 11,050,787) . Regarding Claim 18: Luo in view of Ismael teaches the method according to claim 15. Neither Luo nor Ismael explicitly teaches wherein the other state machine model is selected from a set of other state machine models for the other target system or one or more other target systems, based on a check as to whether the other state machine model fulfills functions required for imitating the target system. However, Sharifi Mehr teaches the concept wherein an other state machine model is selected from a set of other state machine models for an other target system, or one or more other target systems, based on a check as to whether the other state machine model fulfills functions required for imitating the target system ([abstract] adaptively configuring and deploying honeypots in user compute resources; [col 10 line 27-44] honeypot configuration system 120 can use at least a portion of profile information for a virtual network (e.g., profile information 116 generated by network scanning system 112) to identify one or more honeypot configurations that may be suitable for deployment into network 104; for example, honeypot configuration system 120 can access at least a portion of profile information (e.g., profile information 116) about network 104 from network profile database 118, and can use the information to identify potentially suitable configurations; [col 10 line 45-col 11 line 9] honeypot configuration system 120 can retrieve information from a repository of available honeypot configurations 122 using the profile information; honeypot repository 122 can include information about preconfigured honeypot templates that can be used to provide a honeypot customized for network 104, and/or information that can be used to deploy the preconfigured honeypot templates (e.g., virtual machine images, software images, an executable file, source code, machine code, etc.); honeypot configuration system 120 can use properties of one or more virtual machine instances (e.g., which type of function(s) are being performed) being used in network 104 to query a database for honeypot configurations that are compatible with the virtual machine instance; software images can, for example, represent the entire state of a software application at the time it was imaged, such that the software application can be restored to that point by restoring/launching the software image; additionally, virtual machine images can, for example, represent the entire state of a virtual machine instance at the time it was imaged) . It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine suitability check teachings of Sharifi Mehr with the honeypot creation teachings of Luo in view of Ismael, with the benefit of improving system efficiency and security by checking and selecting the most suitable honeypot configuration to use as a baseline, thereby preventing misconfiguration and targeting expected attacks . 07-21-aia AIA Claim (s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Ismael, and further in view of Hebert et al (PGPUB 2020/0186567) Regarding Claim 19: Luo in view of Ismael teaches the method according to claim 12. Neither Luo nor Ismael explicitly teaches wherein, when generating the state machine model, information about the target system that is to be kept confidential according to a confidentiality criterion is removed from the state machine model. However, Hebert teaches the concept wherein, when generating a [honeypot] model, information about a target system that is to be kept confidential according to a confidentiality criterion is removed from the [honeypot] model ([abstract] fake data is subsequently used to seed and enable a honeypot so that access to such honeypot and fake data can be monitored and/or logged; [0018] differential privacy as provided herein allows for diverse anonymization techniques for building usable data for generating honeypot data and/or by running diverse analytics tasks, while removing any user sensitive data) ; and Luo teaches wherein the [honeypot] model is the state machine model ([0121] FIG. 6 is a visualization of building a Markov decision process (MDP) state graph from a session table in accordance with some embodiments; in this example, we will use the real world example to explain how we build MDP and calculate the probabilities for each response) . It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the sensitive data removal teachings of Hebert with the honeypot creation teachings of Luo in view of Ismael. A honeypot is a security concept which is designed to act as a decoy, providing a target for attackers to waste effort on while the rest of the system remains secure; providing a honeypot which comprised (accidentally or otherwise) sensitive data would be counterproductive, resulting in a failure to protect sensitive data; it would therefore be obvious to remove such data to prevent leakage. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F. 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, William Korzuch can be reached at (571) 272-7589. 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. /FORREST L CAREY/Examiner, Art Unit 2491 /WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491 Application/Control Number: 19/015,224 Page 2 Art Unit: 2491 Application/Control Number: 19/015,224 Page 3 Art Unit: 2491 Application/Control Number: 19/015,224 Page 4 Art Unit: 2491 Application/Control Number: 19/015,224 Page 5 Art Unit: 2491 Application/Control Number: 19/015,224 Page 6 Art Unit: 2491 Application/Control Number: 19/015,224 Page 7 Art Unit: 2491 Application/Control Number: 19/015,224 Page 8 Art Unit: 2491 Application/Control Number: 19/015,224 Page 9 Art Unit: 2491 Application/Control Number: 19/015,224 Page 10 Art Unit: 2491 Application/Control Number: 19/015,224 Page 11 Art Unit: 2491 Application/Control Number: 19/015,224 Page 12 Art Unit: 2491 Application/Control Number: 19/015,224 Page 13 Art Unit: 2491 Application/Control Number: 19/015,224 Page 14 Art Unit: 2491 Application/Control Number: 19/015,224 Page 15 Art Unit: 2491 Application/Control Number: 19/015,224 Page 16 Art Unit: 2491
Prosecution Insights