DETAILED ACTION
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 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 267890-the same under either status.
This Office Action is in response to the communication filed on 8/15/2025.
Claims 4 and 16 have been canceled.
Claims 1 and 13 have been amended.
Claims 1-3, 5-15 and 17-24 are pending for consideration.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/22/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Regarding to the Double Patenting Rejection, the pending claims are still rejectable on the ground of nonstatutory double patenting as being unpatentable over claims 1-38 of copending Application No. 17/548089. Therefore, the rejection has been maintained.
Applicant's arguments filed on 8/15/2025 have been fully considered but they are not persuasive.
Applicant argues on pages 7-8 of the Remarks that the combination references fail to teach “a machine learning (ML) engine, the traffic scanner of the SoC further configured to provide the feature information produced to the ML engine of the SoC and to employ the DPI engine of the SoC to compute at least a portion of the feature information associated with the non-payload content of encrypted packets in the received traffic stream that cannot be decrypted by the SoC”.
In response of the above argument, Examiner respectfully disagrees. Srivastav teaches feature information associated with non-payload content of data packets (Srivastav: paragraphs 0038-0039 and 0047, “The detection may be performed within milliseconds. Since data contents cannot be accessed at the network level, threat detection and monitoring is based on packet routing details. That is, the prediction model 206 finds or identifies anomaly patterns or behaviors in the network based on the packet routing details and prevents forwarding potentially hazardous incoming packets to the connected aircraft network 102. Further, the prediction model 206 may also find or identify threats in encrypted traffic, without the need for decryption, using network analytics and machine learning on packet metadata information”). Srivastav further teaches a machine learning (ML) engine (Srivastav: paragraph 0038, “the prediction model 206 may also find or identify threats in encrypted traffic, without the need for decryption, using network analytics and machine learning on packet metadata information”), the traffic scanner of the SoC further configured to provide the feature information produced (Srivastav: paragraphs 0036-0038, “ the mode generator 205 trains and updates the prediction model 206 based on, for example, particular aspects of the network traffic data 111, such as, the network data information relating to connection log data, time-window based features (e.g., the number of data packets sent between two ports during a predetermined amount time in milliseconds, seconds, etc.), IP address ranges, server locations, running operating systems (OS), software versions, types of devices, etc. In one embodiment, packet capturing software, ping commands, and traceroute commands are utilized to capture the connection log data at the one or more communication gateways”) to the ML engine of the SoC and to employ the DPI engine of the SoC to compute at least a portion of the feature information associated with the non-payload content of encrypted packets (Srivastav: paragraphs 0038-0039, “the anomaly detection module 207 is configured to retrieve or receive the prediction model 206 from the model generator 205. Further, the anomaly detection module 207 may be configured to detect anomaly or unknown patterns in the network traffic data 111 by utilizing the prediction model 206. ”… “the prediction model 206 may detect or identify threats in application level data by utilizing the prediction model 206 trained using deep learning techniques”).
Long teaches the non-payload content of encrypted packets in the received traffic stream that cannot be decrypted by the SoC (Long: paragraphs 0093 and 0114-0116, “Undecryptable received data messages are characterized as suspicious messages indicating that the previously encrypted message had been tampered with and is a candidate for analysis. These suspicious messages 210 are in effect filtered and placed in the data store 105, 212 as a filtered data message and retrieved by a Machine Learning site 108, 214, 302 for processing.”). Therefore, the combination of cited references does teach the disputed limitation .
Applicant’s arguments with respect to claim(s) 1-3, 5-15 and 17-24 have been considered but are moot.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 5-15 and 17-24 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-38 of copending Application No. 17/548,089 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications disclose a system-on-a-chip (SoC) and corresponding method implement an intrusion detection system. (See claims comparison table below)
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application 17/548,111
Copending Application 17/548,089
Claim 1:
A system-on-a-chip (SoC) comprising: a deep packet inspection (DPI) engine; at least one processor core, the at least one processor core of the SoC configured to implement a traffic scanner configured to produce feature information associated with non-payload content of encrypted packets in a received traffic stream that cannot be decrypted by the SoC; and a machine learning (ML) engine, the traffic scanner of the SoC further configured to provide the feature information produced to the ML engine of the SoC and to employ the DPI engine of the SoC to compute at least a portion of the feature information associated with the non-payload content of encrypted packets in the received traffic stream that cannot be decrypted by the SoC, the ML engine of the SoC implemented in hardware and configured to (i) assign a classification to the received traffic stream based on the feature information produced and (ii) based on the classification assigned, provide notification to the traffic scanner that malware traffic has been detected in the traffic stream, the traffic scanner further configured to perform, based on the notification provided, an action toward preventing malicious activity otherwise caused by malware traffic.
Claim 1:
A system-on-a-chip (SoC) comprising: a plurality of hardware engines, a classifier, and a traffic scanner, the SoC configured to employ the plurality of hardware engines to implement an intrusion detection system (IDS) configured to detect malware traffic in (i) a non-encrypted traffic stream, (ii) an encrypted traffic stream that can be decrypted by the SoC, and (iii) an encrypted traffic stream that cannot be decrypted by the SoC, the classifier of the SoC configured to classify the received traffic stream as (i), (ii), or (iii),the IDS further configured to perform an action responsive to detecting the malware traffic in a received traffic stream that is (i), (ii), or (iii), the action performed toward preventing malicious activity otherwise caused by the malware traffic, the traffic scanner of the SoC configured to produce feature information, associated with non- payload content of encrypted packets in the received traffic stream, in an event the received traffic stream is classified by the classifier as (iii).
Claim 3:
The SoC of Claim 1, wherein the plurality of hardware engines includes a machine learning (ML) engine, a cryptographic (CPT) engine, and a deep packet inspection (DPI) engine.
Claim 13:
A method comprising: producing, by a traffic scanner of a system-on-a-chip (SoC), feature information associated with non-payload content of encrypted packets in a received traffic stream that cannot be decrypted by the SoC; providing, by the traffic scanner of the SoC, the feature information produced to a machine learning (ML) engine of the SoC, the producing including employing, by the traffic scanner of the SoC, a DPI engine of the SoC to compute at least a portion of the feature information associated with the non-payload content of encrypted packets in the received traffic stream that cannot be decrypted by the SoC: by a machine learning (ML) the ML engine of the SoC, (i) assigning a classification to the received traffic stream based on the feature information produced and (ii) based on the classification assigned, providing notification to the traffic scanner that malware traffic has been detected in the traffic stream; and performing, by the traffic scanner, based on the notification provided, an action toward preventing malicious activity otherwise caused by malware traffic.
Claim 22:
A method comprising: receiving, at a system-on-a-chip (SoC), a traffic stream, the SoC including a plurality of hardware engines, a classifier, and a traffic scanner, the SoC employing the plurality of hardware engines to implement an intrusion detection system (IDS) capable of detecting malware traffic in (i) a non-encrypted traffic stream, (ii) an encrypted traffic stream that can be decrypted by the SoC, and (iii) an encrypted traffic stream that cannot be decrypted by the SoC; classifying, by the classifier of the SoC, the received traffic stream as (i), (ii), or (iii) and, in an event the received traffic stream is classified by the classifier as (iii),producing, by the traffic scanner of the SoC, feature information, the feature information associated with non-payload content of encrypted packets in the received traffic stream; detecting, by the IDS of the SoC, the malware traffic in the received traffic stream received as (i), (ii), or (iii); and performing an action responsive to the detecting, the action performed toward preventing malicious activity otherwise caused by the malware traffic.
Claim 24:
The method of Claim 22, wherein the plurality of hardware engines includes a machine learning (ML) engine, a cryptographic (CPT) engine, and a deep packet inspection (DPI) engine.
The dependent claims of the instant application recite language similar to the dependent claims of the copending application and are covered by the copending application.
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, 5-10, 13-15 and 17-22 are rejected under 35 U.S.C. 103 as being unpatentable over SRIVASTAV et al. (US 20220103578) (hereinafter Sri) in view of KLEIN et al. (US 20200334355) (hereinafter KLEIN), and further in view of Long et al. (US 20200293655) (hereinafter Long).
Regarding claim 1, Sri discloses a system-The machine learning techniques of the present disclosure may include deep learning algorithms or techniques”… “the prediction model 206 may detect or identify threats in application level data by utilizing the prediction model 206 trained using deep learning techniques”); at least one processor core, the at least one processor core of the SoC configured to implement a traffic scanner configured to produce feature information associated with non-payload content of encrypted packets in a received traffic stream Sri: paragraphs 0038-0039, 0041, 0047 and 0049-0050, “The detection may be performed within milliseconds. Since data contents cannot be accessed at the network level, threat detection and monitoring is based on packet routing details. That is, the prediction model 206 finds or identifies anomaly patterns or behaviors in the network based on the packet routing details and prevents forwarding potentially hazardous incoming packets to the connected aircraft network 102. Further, the prediction model 206 may also find or identify threats in encrypted traffic, without the need for decryption, using network analytics and machine learning on packet metadata information”); and a machine learning (ML) engine (Srivastav: paragraph 0038, “the prediction model 206 may also find or identify threats in encrypted traffic, without the need for decryption, using network analytics and machine learning on packet metadata information”), the traffic scanner of the SoC further configured to provide the feature information produced (Srivastav: paragraphs 0036-0038, “ the mode generator 205 trains and updates the prediction model 206 based on, for example, particular aspects of the network traffic data 111, such as, the network data information relating to connection log data, time-window based features (e.g., the number of data packets sent between two ports during a predetermined amount time in milliseconds, seconds, etc.), IP address ranges, server locations, running operating systems (OS), software versions, types of devices, etc. In one embodiment, packet capturing software, ping commands, and traceroute commands are utilized to capture the connection log data at the one or more communication gateways”) to the ML engine of the SoC and to employ the DPI engine of the SoC to compute at least a portion of the feature information associated with the non-payload content of encrypted packets in the received traffic stream (Srivastav: paragraphs 0038-0039, “the anomaly detection module 207 is configured to retrieve or receive the prediction model 206 from the model generator 205. Further, the anomaly detection module 207 may be configured to detect anomaly or unknown patterns in the network traffic data 111 by utilizing the prediction model 206. ”… “the prediction model 206 may detect or identify threats in application level data by utilizing the prediction model 206 trained using deep learning techniques”), the ML engine of the SoC implemented in hardware and configured to (i) assign a classification to the received traffic stream based on the feature information produced and (ii) based on the classification assigned, provide notification to the traffic scanner that malware traffic has been detected in the traffic stream (Sri: paragraphs 0038, 0039-0041 and 0048, “The summarization module 311 may classify the known and unknown data patterns of the network traffic data 303 into different types and/or levels of threat. By classifying the types of treat or malware in real-time, cyber security teams gain immediate visibility and knowledge of the threats or malware that attacks the systems or networks. Such immediate visibility and knowledge provides a better understanding of the impact cyberattacks have on the systems and networks.”), the traffic scanner further configured to perform, based on the notification provided, an action toward preventing malicious activity otherwise caused by malware traffic (Sri: paragraphs 0038-0039 and 0042, “the anomaly detection system 209 may generate alert signals and detection report or automatically discard packets determined to be anomalous”… “In one embodiment, the anomaly detection module 309 may automatically determine which data packets of incoming network data to discard and which data packets to allow to and from the connected network 302”).
Sri discloses the system that performs all the functions recited in claim 1. However, the system recited in Sri reference is not a system-on-a-chip. KLEIN, on the other hand, disclose a system-on-a-chip that has an intrusion detection unit made of hardware which is also used to detect malware (KLEIN: paragraphs 0009, 0037, 0060 and 0067, “an improved IDS in a system-on-a-chip for such a system-in-chip comprising a plurality of computing units, in particular computer cores and/or CPUs, at least one input/output unit, one storage unit and an input/output control unit that coordinates the communication between the computing units and the at least one input/output unit, wherein the system-on-a-chip further has an intrusion detection unit made of hardware”).
Sri and KLEIN are analogous art because they are from the same field of endeavor, malware protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Sri and KLEIN before him or her, to modify the system of Sri to include a system-on-a-chip that has an intrusion detection unit of KLEIN. The suggestion/motivation for doing so would have been to be able to analyze intrusions that have possibly taken place and to determine data for improving a data-processing unit or a software means used therein (KLEIN: paragraph 0067).
Sri in view of KLEIN does not explicitly disclose the following limitation which is disclosed by Long, the non-payload content of encrypted packets in a received traffic stream that cannot be decrypted (Long: paragraphs 0093 and 0114-0116, “Undecryptable received data messages are characterized as suspicious messages indicating that the previously encrypted message had been tampered with and is a candidate for analysis. These suspicious messages 210 are in effect filtered and placed in the data store 105, 212 as a filtered data message and retrieved by a Machine Learning site 108, 214, 302 for processing..”).
Sri in view of KLEIN and Long are analogous art because they are from the same field of endeavor, malware detection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Sri in view of KLEIN and Long before him or her, to modify the system of Sri in view of KLEIN to include a non-payload content of encrypted packets in a received traffic stream that cannot be decrypted of Long. The suggestion/motivation for doing so would have been in order to predict new Evolving Malware Threats (Long: paragraph 0114).
Regarding claim 13, claim 13 discloses a method claim that is substantially equivalent to the system of claim 1. Therefore, the arguments set forth above with respect to claim 1 are equally applicable to claim 13 and rejected for the same reasons.
Regarding claims 2 and 14, Sri as modified discloses wherein the action performed includes discarding the received traffic stream, generating an alert associated with the received traffic stream, or a combination thereof (Sri: paragraphs 0038 and 0039, “when a message in an air traffic controller is corrupted or misused, the prediction model 206 may utilize natural language processing to validate or discard the data packets or initiate a request to resend the data packets.”).
Regarding claims 3 and 15, Sri as modified discloses wherein the SoC further comprises a plurality of processor cores and wherein at least one processor core of the plurality of processor cores is configured to implement the traffic scanner (KLEIN: paragraphs 0007 and 0060, “seeking to realize an improved IDS in a system-on-a-chip for such a system-in-chip comprising a plurality of computing units, in particular computer cores and/or CPUs, at least one input/output unit, one storage unit and an input/output control unit that coordinates the communication between the computing units and the at least one input/output unit, wherein the system-on-a-chip further has an intrusion detection unit made of hardware”). The same motivation to modify Sri in view of KLEIN, as applied in claim 1 above, applies here.
Regarding claims 5 and 17, Sri as modified discloses wherein the classification assigned is normal, known malware, or unknown malware and wherein, in an event the classification assigned is known malware or unknown malware, the ML engine is further configured to provide the notification to the traffic scanner (Sri: paragraphs 0041-0042 and 0048, “the anomaly detection module 309 may transmit the identified known and unknown data patterns to a summarization module 311. The summarization module 311 may classify the known and unknown data patterns of the network traffic data 303 into different types and/or levels of threat. By classifying the types of treat or malware in real-time, cyber security teams gain immediate visibility and knowledge of the threats or malware that attacks the systems or networks.”).
Regarding claims 6 and 18, Sri as modified discloses wherein the traffic scanner is further configured to produce and share the feature information based on a time interval (Sri: paragraphs 0034, 0040 and 0048, “the prediction model 206 may be updated using the network traffic data 111 received in the data servers 203 in real-time. In one embodiment, the prediction model 206 is re-trained (i.e., updated) at periodic intervals or continuously in real-time based on the newly stored network traffic data”).
Regarding claims 7 and 19, Sri as modified discloses wherein the traffic scanner is further configured to apply a sliding window to the received traffic stream based on a time interval and wherein the sliding window is configured to capture packet data from the received traffic stream over the time interval on a time-interval-by-time-interval basis (Sri: paragraphs 0037 and 0038, “the mode generator 205 trains and updates the prediction model 206 based on, for example, particular aspects of the network traffic data 111, such as, the network data information relating to connection log data, time-window based features (e.g., the number of data packets sent between two ports during a predetermined amount time in milliseconds, seconds, etc.), IP address ranges, server locations, running operating systems (OS), software versions, types of devices, etc. In one embodiment, packet capturing software, ping commands, and traceroute commands are utilized to capture the connection log data at the one or more communication gateways”).
Regarding claims 8 and 20, Sri as modified discloses wherein the feature information includes a maximum packet length, minimum packet length, or combination thereof, determined based on the packet data captured within the sliding window (Sri: paragraphs 0037 and 0038, “the mode generator 205 trains and updates the prediction model 206 based on, for example, particular aspects of the network traffic data 111, such as, the network data information relating to connection log data, time-window based features (e.g., the number of data packets sent between two ports during a predetermined amount time in milliseconds, seconds, etc.), IP address ranges, server locations, running operating systems (OS), software versions, types of devices, etc. In one embodiment, packet capturing software, ping commands, and traceroute commands are utilized to capture the connection log data at the one or more communication gateways).
Regarding claims 9 and 21, Sri as modified discloses wherein the traffic scanner is further configured to produce the feature information by computing at least a portion of the feature information, wherein the computing is based on the packet data captured within the sliding window, and wherein the at least a portion of the feature information computed includes: packet size- based feature information, packet time-to-live-based feature information, packet time- based feature information, packet entropy-based feature information, or a combination thereof (Sri: paragraphs 0037 and 0038, “the mode generator 205 trains and updates the prediction model 206 based on, for example, particular aspects of the network traffic data 111, such as, the network data information relating to connection log data, time-window based features (e.g., the number of data packets sent between two ports during a predetermined amount time in milliseconds, seconds, etc.), IP address ranges, server locations, running operating systems (OS), software versions, types of devices, etc. In one embodiment, packet capturing software, ping commands, and traceroute commands are utilized to capture the connection log data at the one or more communication gateways).
Regarding claims 10 and 22, Sri as modified discloses wherein the received traffic stream is part of a secure session and wherein the feature information is further associated with non-encrypted content of an initial non-encrypted packet of the secure session (Sri: paragraphs 0038 and 0047, “the prediction model 206 may also find or identify threats in encrypted traffic, without the need for decryption, using network analytics and machine learning on packet metadata information”).
Claims 11 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Sri in view of KLEIN in view of Long, and further in view of Burns et al. (US 8341724) (hereinafter Burns).
Regarding claims 11 and 23, Sri in view of KLEIN in view of Long does not explicitly disclose the following limitation which is disclosed by Burns, wherein the feature information includes packet entropy-based feature information (Burns: column 14 lines 5-15, “any statistical method for determining randomness or entropy of data in packets may be used to determine whether data of a packet is encrypted. That is, encryption detection module 58 may determine that data of a packet is random by implementing any statistical randomness- or entropy-identifying technique. In general, when encryption detection module 58 determines that data of a packet is random or has high entropy, e.g., by exceeding a randomness or entropy threshold”).
Sri in view of KLEIN in view of Long and Burns are analogous art because they are from the same field of endeavor, malware protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Sri in view of KLEIN in view of Long and Burns before him or her, to modify the system of Sri in view of KLEIN in view of Long to include a feature information that includes packet entropy-based feature information of Burns. The suggestion/motivation for doing so would have been to prevent users from using certain applications due to various considerations (Burns: column 1 lines 27-30).
Claims 12 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Sri in view of KLEIN in view of Long, and further in view of Xaypanya et al. (US 20140215621) (hereinafter Xay).
Regarding claims 12 and 24, Sri in view of KLEIN in view of Long does not explicitly disclose the following limitation which is disclosed by Xay, wherein the feature information includes packet time-to-live-based feature information (Xay: paragraphs 0164 and 0187, “the present disclosure can cluster multiple malware detection and prediction techniques such as using abnormal Time-to-Live (TTL) values to identify malicious packets, using AI behavioral detection, and using a virtual machine safe/sandbox”).
Sri in view of KLEIN in view of Long and Xay are analogous art because they are from the same field of endeavor, malware protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Sri in view of KLEIN in view of Long and Xay before him or her, to modify the system of Sri in view of KLEIN in view of Long to include a feature information that includes packet time-to-live-based feature information of Xay. The suggestion/motivation for doing so would have been to prevent the further dissemination of malware to other networks, including the protected domain as well as other domains (Xay: paragraph 0155).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 TRANG T DOAN whose telephone number is (571)272-0740. The examiner can normally be reached Monday-Friday 7-4 ET.
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, Lynn D Feild can be reached on (571)272-2092. 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.
/TRANG T DOAN/Primary Examiner, Art Unit 2431