DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/20/2024 was filed before the mailing date of this office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 2-3 and 14-20 are rejected under 35 U.S.C. 102(a)(i) as being anticipated by Paraskevas et al. (US 2021/0075800 A1) (hereinafter, “Paraskevas”).
As to claim 2, Paraskevas discloses a device (Fig. 3), comprising:
logic to receive an Ethernet packet at a line rate (“Frequency of messages for a traffic flow (IDS monitors the overall rate of message arrival at a designated destination)” -e.g., see, [0033]; see also: “… network traffic across an embedded Ethernet switch for a designated controller is monitored in real time, a network traffic characteristic (e.g., frequency of messages for a traffic flow from a given node) is analyzed, and an anomaly is flagged if the analyzed characteristic is outside a vehicle-calibrated boundary (e.g., the frequency of messages exceeds a threshold value defined by off-line vehicle emulation and mapping).” -e.g., see, [0026]), the Ethernet packet identifying a source of the Ethernet packet and a destination of the Ethernet packet (“Source-destination pairs for a traffic flow (IDS monitors frames at both source and destination ECUs as well as switches)” -e.g., see, [0032]);
logic to identify a state of a vehicle (“… method 200 of FIG. 3 continues to input/output block 203 to receive, retrieve or otherwise determine a current state of operation of the motor vehicle. In an example, one of the networked controllers 112A-112N of FIG. 2 is embodied as an external object calculation module (EOCM) that is operable to execute a vehicle-assisted maneuver, e.g., for an autonomous vehicle operation, of vehicle 110. A primary EOCM may be programmed to selectively actuate a power steering motor, a motor-driven throttle valve, and/or hydraulic brake actuators to supplement one or more driver inputs, to counteract one or more driver inputs, and/or to assume driving control independent of driver input. A vehicle's current state of operation may be read from the EOCM in response to a prompt from the CCM or GCM. Operational states in autonomous driving scenarios may be in the form of electronic signals indicating an SAE Level 0-5 driving mode. SAE Level 0, for example, is generally typified as “unassisted” driving that allows for vehicle-generated warnings with momentary intervention, but otherwise relies solely on human control. By comparison, SAE Level 3 allows for unassisted, partially assisted, and fully assisted driving with sufficient vehicle automation for full vehicle control (steering, speed, acceleration/deceleration, etc.), while obliging driver intervention within a calibrated timeframe.” -e.g., see, [0027], see also, [0028]);
logic to determine, based at least in part on the state of the vehicle, one or more management actions to be taken on the packet (“Method 200 then proceeds to decision block 211 to determine if any of the traffic characteristics of the monitored network traffic flow is outside a respective calibrated boundary, which is extracted from a corresponding one of the network traffic pattern tables. Put another way, the IDS logic checks the boundaries of the network traffic patterns to realize possible anomalies on the network traffic flows. These boundaries may be established by statistical analysis, with the introduction of an appropriate confidence level, or by machine-learning techniques that are performed, e.g., by a backend server after collecting data for different scenarios. Each boundary may incorporate “relaxed” lower and upper thresholds so as to avoid the possibility of false positives.” -e.g., see, [0031], see also: “… determining a current state of operation of the motor vehicle; identifying a network traffic pattern table corresponding to the current state of operation of the motor vehicle; monitoring network traffic flow for one or more of the electronic controllers when each controller is exchanging data over the Ethernet communication interface while the motor vehicle is operating in the current state of operation; determining if a traffic characteristic of the monitored network traffic flow is outside a calibrated boundary determined from the network traffic pattern table; and, executing a remedial action in response to the traffic characteristic of the monitored network traffic flow being outside the calibrated boundary.” -e.g., see, [0008], see also: [0036], [0037]); and
logic to perform the one or more management actions on the packet (“In response to any one of the traffic characteristics associated with the monitored network traffic flow falling outside of its respective calibrated boundary (Block 211=YES), the method 200 proceeds to process block 213 and executes one or more corrective actions to remediate the network intrusion event accompanying the anomaly in network traffic flow. If a characteristic that defines network traffic patterns is not within calibrated boundaries, the IDS logic may raise an alarm and concomitantly inform a governing system controller about a possible attack. This alarm may then be input to an intrusion prevention system (IPS) that is operable to decide what, if any, counteractive measures will be taken to stop and/or offset the attack (e.g., turn the system to a safe mode to investigate or limit the effect of the attack). The remedial action of process block 213 may take any many different forms, such as transmitting an audio and/or visual alert to the vehicle driver warning them of a potential attack and the possible loss of vehicle functionality; transmitting an electronic alert to a manufacturer's or service provider's remote server indicating the detection of an anomaly and potential attack; generating an interrupt signal to discontinue any further exchange of data by the compromised controller; and/or storing in a memory device a record of detected anomaly (e.g., date of intrusion, type of anomaly, ID of corrupted ECU, etc.).” -e.g., see, [0037]).
As to claim 20, it is rejected using the similar rationale as for the rejection of claim 2.
As to claim 3, Paraskevas discloses the device of claim 2, Paraskevas further discloses wherein the vehicle comprises the device (Fig. 1, [0013]; herein, in-vehicle controller; see also, [0029]).
As to claim 14, Paraskevas discloses the device of claim 2, Paraskevas further discloses wherein information identifying the state of the vehicle is separate from the Ethernet packet (“… method 200 of FIG. 3 continues to input/output block 203 to receive, retrieve or otherwise determine a current state of operation of the motor vehicle. In an example, one of the networked controllers 112A-112N of FIG. 2 is embodied as an external object calculation module (EOCM) that is operable to execute a vehicle-assisted maneuver, e.g., for an autonomous vehicle operation, of vehicle 110. A primary EOCM may be programmed to selectively actuate a power steering motor, a motor-driven throttle valve, and/or hydraulic brake actuators to supplement one or more driver inputs, to counteract one or more driver inputs, and/or to assume driving control independent of driver input. A vehicle's current state of operation may be read from the EOCM in response to a prompt from the CCM or GCM. Operational states in autonomous driving scenarios may be in the form of electronic signals indicating an SAE Level 0-5 driving mode. SAE Level 0, for example, is generally typified as “unassisted” driving that allows for vehicle-generated warnings with momentary intervention, but otherwise relies solely on human control. By comparison, SAE Level 3 allows for unassisted, partially assisted, and fully assisted driving with sufficient vehicle automation for full vehicle control (steering, speed, acceleration/deceleration, etc.), while obliging driver intervention within a calibrated timeframe.” -e.g., see, [0027], see also, [0028]; herein, the state of the vehicle is separate from the Ethernet packet).
As to claim 15, Paraskevas discloses the device of claim 2, Paraskevas further discloses wherein identifying a state of the vehicle comprises accessing a configuration register that stores the information identifying the state of the vehicle (“A vehicle's current state of operation may be read from the EOCM in response to a prompt from the CCM or GCM. Operational states in autonomous driving scenarios may be in the form of electronic signals indicating an SAE Level 0-5 driving mode. SAE Level 0, for example, is generally typified as “unassisted” driving that allows for vehicle-generated warnings with momentary intervention, but otherwise relies solely on human control.” -e.g., see, [0027]).
As to claim 16, Paraskevas discloses the device of claim 2, Paraskevas further discloses wherein the logic comprises at least one of hardware instructions or firmware instructions that are executable by hardware independent of a processor (“… executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well-known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.).” -e.g., see, [0040]).
As to claim 17, Paraskevas discloses the device in claim 2, Paraskevas further wherein the device is a system on a chip (SoC) (“Communication capabilities with remote, off-board networked devices is provided via one or more or all of a cellular chipset/component 40, a wireless modem 42, a navigation and location chipset/component 44 (e.g., global positioning system (GPS)), a short-range wireless communication device 48 (e.g., a Bluetooth® unit), and/or a dual antenna 50.” -e.g., see, [0022]). Moreover, it’s well known to have device in a SoC and would be useful to combine the feature in order to reduce the physical size of the device while making the device more portable and suitable for various applications.
As to claim 18, Paraskevas discloses the device of claim 2, Paraskevas further discloses wherein the one or more management actions comprises one of the following actions: preventing delivery of the Ethernet packet to the identified destination, based at least in part on a determination that the Ethernet packet should be filtered; or allowing delivery of the Ethernet packet to the identified destination, based at least in part on an absence of a determination that the Ethernet packet should be filtered (“… generating an interrupt signal to discontinue any further exchange of data by the compromised controller; and/or storing in a memory device a record of detected anomaly (e.g., date of intrusion, type of anomaly, ID of corrupted ECU, etc.). At this juncture, the method 200 of FIG. 3 may loop back to terminal block 201 or input/output block 203, or may terminate and reset.” -e.g., see, [0037]).
As to claim 19, Paraskevas discloses the device of claim 18, Paraskevas further discloses wherein the one or more management actions further comprises at least one of the following actions: redirecting the packet for further processing and examination; allowing snooping of the packet for further examination while allowing the packet to be delivered to the identified destination; modifying one or more fields of the packet and delivering the packed with the modified one or more modified fields; or metering the packed and a plurality of subsequent packets to enforce specified data rate limits (“The remedial action of process block 213 may take any many different forms, such as transmitting an audio and/or visual alert to the vehicle driver warning them of a potential attack and the possible loss of vehicle functionality; transmitting an electronic alert to a manufacturer's or service provider's remote server indicating the detection of an anomaly and potential attack; generating an interrupt signal to discontinue any further exchange of data by the compromised controller; and/or storing in a memory device a record of detected anomaly (e.g., date of intrusion, type of anomaly, ID of corrupted ECU, etc.).” -e.g., see, [0037]).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4-6 and 8-12 are rejected under 35 U.S.C. 103 as being unpatentable over Paraskevas as applied to claims 2-3 above, and further in view of Atad et al. (US 2018/0262466 A1) (hereinafter, “Atad”).
As to claim 4, Paraskevas discloses the device of claim 2, Paraskevas doesn’t explicitly disclose further comprising: a ternary content addressable memory (TCAM). However, in analogous art, Atad discloses a ternary content addressable memory (TCAM) (“… a cyber threat may be based on a state and context of at least one of: the vehicle, the in-vehicle network and at least one component connected to the in-vehicle network. The switch may include a ternary content-addressable memory (TCAM) table, and the step of configuring the switch, by the IDPS unit, may include updating information in the TCAM table.” -e.g., see, Atad: [0009]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 5, Paraskevas in view of Atad discloses the device of claim 4, Atad further discloses comprising logic to store, in the TCAM, an access control list (ACL) comprising a plurality of filter rules (“… filter rules 205 may include a whitelist of allowed packets as well as a blacklist of blocked packets. Filter rules 205 may be based on any one of: the payload (metadata and content) of packets, current state of the vehicle (for example its speed) and/or the state of the system.” -e.g., see, [0055]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 6, Paraskevas in view of Atad discloses the device of claim 5, Atad further discloses wherein determining one or more management actions to be taken on the packet comprises: evaluating the Ethernet packet against at least one of the filter rules (“… a value indicating or representing a vehicle's state (e.g., stationary, engine is running, speed at which the vehicle is moving) may be loaded from vehicle state 142 into memory 120 and used, by controller 105, for selecting and/or applying a rule, identifying a cyber-threat, performing an action and so on as further described herein.” -e.g., see, Atad: [0036]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 8, Paraskevas in view of Atad discloses the device of claim 6, Atad further discloses wherein determining whether the Ethernet packet should be filtered further comprises: identifying one or more of the plurality of filter rules as applicable based on the state of the vehicle; and disregarding all the filter rules other than the identified one or more applicable filter rules when evaluating the Ethernet packet (“… a value indicating or representing a vehicle's state (e.g., stationary, engine is running, speed at which the vehicle is moving) may be loaded from vehicle state 142 into memory 120 and used, by controller 105, for selecting and/or applying a rule, identifying a cyber-threat, performing an action and so on as further described herein.” -e.g., see, Atad: [0036]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 9, Paraskevas in view of Atad discloses the device of claim 8, Atad further discloses wherein each of the plurality of filter rules comprises a field that identifies one or more of a plurality of possible states of the vehicle (“… filter rules 205 may include a whitelist of allowed packets as well as a blacklist of blocked packets. Filter rules 205 may be based on any one of: the payload (metadata and content) of packets, current state of the vehicle (for example its speed) and/or the state of the system.” -e.g., see, [0055]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 10, Paraskevas in view of Atad discloses the device of claim 9, Atad further discloses wherein the plurality of possible states of the vehicle comprises one or more of the following: vehicle gear status, vehicle engine status, vehicle location, vehicle speed, vehicle acceleration, vehicle direction, identity of driver or passengers in vehicle, objects proximate to vehicle and relative positions thereof, vehicle maintenance mode status, activation of maintenance required notifications, fuel level, battery charge level, whether or not the vehicle is in an autonomous driving mode; whether or not the vehicle is in an advanced driver assistance mode (“… a value indicating or representing a vehicle's state (e.g., stationary, engine is running, speed at which the vehicle is moving) may be loaded from vehicle state 142 into memory 120 and used, by controller 105, for selecting and/or applying a rule, identifying a cyber-threat, performing an action and so on as further described herein.” -e.g., see, Atad: [0036]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 11, Paraskevas in view of Atad discloses the device of claim 9, Atad further discloses wherein identifying one or more of the plurality of filter rules as applicable based on the state of the vehicle comprises: comparing the identified state of the vehicle with the field of each filter rule that identifies one or more of the plurality of possible states of the vehicle (“… filter rules 205 may include a whitelist of allowed packets as well as a blacklist of blocked packets. Filter rules 205 may be based on any one of: the payload (metadata and content) of packets, current state of the vehicle (for example its speed) and/or the state of the system.” -e.g., see, [0055]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
As to claim 12, Paraskevas in view of Atad discloses the device of claim 8, Atad further discloses wherein disregarding all the filter rules other than the identified one or more applicable filter rules when evaluating the Ethernet packet occurs before evaluating the Ethernet packet against any of the filter rules (“Accordingly, an embodiment may selectively block or prevent flows of packets from compromised ECUs or from ECUs suspected to be compromised. When or after IDPS 200 determines or identifies an attack is over, e.g., ECU 310 is no longer controlled by malicious code, IDPS 200 may remove a filter or otherwise configure or reconfigure TCAM 305, thus restoring normal operation of a system as well as freeing resources related to TCAM 305.” -e.g., see, Atad: [0070]; see also, [0069]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas as taught by Atad in order to enhance security of the in-vehicle devices by protecting the vehicle’s ECUs from potential attacks.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Atad as in view of Basso et al. (US 2014/0082122 A1) (hereinafter, “Basso”).
As to claim 1, Atad discloses a networking device in a vehicle, the networking device comprising:
a processor (Fig. 1, item 105);
a ternary content addressable memory (TCAM) (Fig. 3, item 305);
circuitry to receive an Ethernet packet (Fig. 2, (201) “Incoming Eth. Stream”) comprising an Internet Protocol (IP) packet (“embodiments may protect against vulnerabilities and attacks related to […] TCP/IP”) at a line rate (“in real-time” -e.g., see, [0070]), the Ethernet packet identifying a source of the Ethernet packet and a destination of the Ethernet packet (“… metadata of a message may be […] a source and destination” -e.g., see, [0078]);
circuitry to access a configuration register of the vehicle to identify a state of the vehicle (“… a value indicating or representing a vehicle’s state […] may be loaded from vehicle state 142” -e.g., see, [0036]);
circuitry to access, in the TCAM, a static … comprising a plurality of filter rules (“… an embodiment may apply […] rules using a switch’s TCAM” -e.g., see, [0070]), …; and
comprises a field that identifies one or more of a plurality of possible states of the vehicle (“… a value indicating or representing a vehicle’s state […] may be loaded from vehicle state 142 into memory 120 and used, by controller 105, for selecting […] a rule” -e.g., see, [0036]);
circuitry to compare the identified state of the vehicle with the field of each filter rule that identifies one or more of the plurality of possible states of the vehicle to identify one or more of the plurality of filter rules as applicable, based on the state of the vehicle (“… a value indicating or representing a vehicle’s state […] may be loaded from vehicle state 142 into memory 120 and used, by controller 105, for selecting […] a rule” -e.g., see, [0036]);
circuitry to evaluate the Ethernet packet against at least one of the one or more applicable filter rules by order of priority of the one or more applicable filter rules (“… an embodiment may apply […] rules using a switch’s TCAM” -e.g., see, [0070]);
circuitry to determine, at the line rate (“in real-time” -e.g., see, [0070]) and based at least in part on the evaluation of the Ethernet packet against at least one of the one or more applicable filter rules, one or more management actions to perform on the packet (“… a value indicating or representing a vehicle’s state […] may be […] used, by controller 105, for selecting and/or applying a rule, identifying a cyber-threat, performing an action” -e.g., see, [0036]); and
circuitry to perform the one or more management actions on the packet (“IDPS 200 may […] cause the switch to drop or discard anomalous packets” -e.g., see, [0065]).
Atad does not explicitly disclose a static access control list (ACL); wherein each of the plurality of filter rules: has a priority;
However, in an analogous art, Basso discloses a static access control list (ACL); wherein each of the plurality of filter rules: has a priority (“In one embodiment, to prevent conflicts within the same ACL, the rules are arranged in a hierarchy, usually based on the order the rules are listed in the ACL. Thus, the identified action may change based on the ordering of the rules in the hierarchy.” -e.g., see, Basso: [0031]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Atad as taught by Basso in order to effectively use the filter rules and reduce the use of resources.
Claims 7 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Paraskevas in view of Atad as applied to claims 4-6 above, and further in view of Basso.
As to claim 7, Paraskevas in view of Atad discloses the device of claim 6, Paraskevas in view of Atad doesn’t explicitly disclose wherein each of the plurality of filter rules has a priority, and wherein evaluating the Ethernet packet against at least one of the filter rules comprises evaluating the Ethernet packet against the at least one of the filter rules according to the priority of each of the at least one filter rules.
However, in an analogous art, Basso discloses wherein each of the plurality of filter rules has a priority, and wherein evaluating the Ethernet packet against at least one of the filter rules comprises evaluating the Ethernet packet against the at least one of the filter rules according to the priority of each of the at least one filter rules (“In one embodiment, to prevent conflicts within the same ACL, the rules are arranged in a hierarchy, usually based on the order the rules are listed in the ACL. Thus, the identified action may change based on the ordering of the rules in the hierarchy.” -e.g., see, Basso: [0031]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas and Atad as taught by Basso in order to effectively use the filter rules and reduce the use of resources.
As to claim 13, Paraskevas in view of Atad discloses the device of claim 8, Paraskevas in view of Atad does not explicitly discloses further comprising: logic to mask, in one or more of the plurality of filter rules, the field identifying one of the plurality of possible states of the vehicle to identify at least two of the plurality of possible states of the vehicle.
However, in an analogous art, Basso discloses logic to mask, in one or more of the plurality of filter rules, the field identifying one of the plurality of possible states of the vehicle to identify at least two of the plurality of possible states of the vehicle (“… the conditions stored in the TCAM 105 are made using a pattern and mask. For example, the pattern may be "9.00.000.0", and the mask may be "255.000.00.0". The portion "255" (i.e., the highest possible bit value for that portion of the pattern) indicates that this portion of the pattern is to be matched precisely. Conversely, the portion of zeros (i.e., the lowest possible bit value for that portion of the pattern) indicate that these portions of the pattern are "don't care" bits. Thus, the resulting logic is "9.*.*.*". Using a pattern and mask, the TCAM 105 can be programmed to determine whether different portions of a received frame match a condition in the TCAM 105.” -e.g., see, Basso: [0036]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was to modify the teaching of Paraskevas and Atad as taught by Basso in order to effectively use the filter rules and reduce the use of resources.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
