DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on 03/26/2025.
Status of claims in the instant application:
Claims 1-17 are pending.
Priority
This application is a CON of 17/578,293, now PAT US 12301600 B2, filed on 01/18/2022.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 05/14/2025, 09/18/2025, 10/24/2025, 06/04/2026 and 08/31/2026 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 03/26/2025 have been inspected, and it’s in compliance with MPEP 608.02.
Specification
Specification filed on 03/26/2025 has been inspected and it’s in compliance with MPEP 608.01.
Claim Objections
Claims 14 and 15 are objected to because of the following informalities:
Claims 14 and 15 recite, “The system of claim 1, wherein an OUI for the given device corresponds to a network …”
The abbreviated term “OUI” needs to be used in it’s full form first, along with the abbreviation, and then it can be referenced using the abbreviation only.
Appropriate correction is required.
*** Note: Applicant is directed to claim 13 for proper format (claim language) that uses the same abbreviated term as claims 14 and 15.
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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 and 21 of U.S. Patent No. US 12301600 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are just broader version of claims of the issued patent US 12301600 B2 that make the claims of the instant application obvious.
Instant Application
Reference Patent (12301600)
1. A system, comprising: a processor configured to: receive a set of training data associated with a plurality of exemplary Internet of Things (IoT) devices, wherein the set of training data includes, for at least some of the exemplary IoT devices, a set of time series features for applications used by the IoT devices; and generate a model, using at least a portion of the received training data, wherein the model is usable to classify a given device; and a memory coupled to the processor and configured to provide the processor with instructions.
2. The system of claim 1, wherein the set of time series features comprise at least one of: (1) a bucket count feature for a given application used by a given device, or (2) a session activity statistic feature for the given application used by the given device.
1. A system, comprising: a processor configured to: receive information associated with a network communication of an Internet of Things (IOT) device; determine whether the IoT device has previously been classified; in response to determining that the IoT device has not previously been classified, determine that a probability match for the IoT device against a behavior signature exceeds a threshold, wherein the behavior signature includes at least a first time series feature for an application used by the IoT device, and wherein the first time series feature for the application used by the IoT device comprises at least one of: (1) a bucket count feature for the application used by the IoT device, or (2) a session activity statistic feature for the application used by the IoT device; and based at least in part on the probability match, provide a classification of the IoT device to a security appliance configured to apply a policy to the IoT device; and a memory coupled to the processor and configured to provide the processor with instructions.
2. The system of claim 1, wherein the processor is further configured to use at least a portion of the received information to generate a vector that bucketizes usage of the application by the IoT device.
3. The system of claim 2, wherein the processor is further configured to use the vector to generate a set of time series statistical features of the usage of the application by the IoT device.
3. The system of claim 1, wherein the set of time series features includes a maximum usage of a given application across a plurality of time buckets.
4. The system of claim 3, wherein the set of time series statistical features includes a maximum usage of the application across a plurality of time buckets.
4. The system of claim 1, wherein the set of time series features includes a minimum usage of a given application across a plurality of time buckets.
5. The system of claim 3, wherein the set of time series statistical features includes a minimum usage of the application across a plurality of time buckets.
5. The system of claim 1, wherein the set of time series features includes a count of a number of non-zero buckets corresponding to times during which a given application was used.
6. The system of claim 3, wherein the set of time series statistical features includes a count of a number of non-zero buckets corresponding to times during which the application was used.
6. The system of claim 1, wherein the set of time series features includes a sum of usage of a given application across a plurality of time buckets.
7. The system of claim 3, wherein the set of time series statistical features includes a sum of usage of the application across a plurality of time buckets.
7. The system of claim 1, wherein the set of time series features includes a mean of usage of a given application across a plurality of time buckets.
8. The system of claim 3, wherein the set of time series statistical features includes a mean of usage of the application across a plurality of time buckets.
8. The system of claim 1, wherein the set of time series features includes a variance of usage of a given application across a plurality of time buckets.
9. The system of claim 3, wherein the set of time series statistical features includes a variance of usage of the application across a plurality of time buckets.
9. The system of claim 1, wherein the set of time series features includes a median of usage of a given application across a plurality of time buckets.
10. The system of claim 3, wherein the set of time series statistical features includes a median of usage of the application across a plurality of time buckets.
10. The system of claim 1, wherein the set of time series features includes a kurtosis of usage of a given application across a plurality of time buckets.
11. The system of claim 3, wherein the set of time series statistical features includes a kurtosis of usage of the application across a plurality of time buckets.
11. The system of claim 1, wherein the set of time series features includes a skewness of usage of a given application across a plurality of time buckets.
12. The system of claim 3, wherein the set of time series statistical features includes a skewness of usage of the application across a plurality of time buckets.
12. The system of claim 1, wherein the set of time series features includes a quantile of usage of a given application across a plurality of time buckets.
13. The system of claim 3, wherein the set of time series statistical features includes a quantile of usage of the application across a plurality of time buckets.
13. The system of claim 1, wherein an organizationally unique identifier (OUI) for the given device is not available.
14. The system of claim 1, wherein an organizationally unique identifier (OUI) for the IoT device is not available.
14. The system of claim 1, wherein an OUI for the given device corresponds to a network card and wherein the given device is not a network card.
15. The system of claim 1, wherein an QUI for the IoT device corresponds to a network card and wherein the IoT device is not a network card.
15. The system of claim 1, wherein an OUI for the given device corresponds to a network appliance and wherein the given device is not a network appliance.
16. The system of claim 1, wherein an OUI for the IoT device corresponds to a network appliance and wherein the IoT device is not a network appliance.
16. The system of claim 1, wherein at least a portion of a network communication made by the given device is encrypted.
17. The system of claim 1, wherein at least a portion of the network communication is encrypted.
17. A method, comprising: receiving a set of training data associated with a plurality of exemplary Internet of Things (IoT) devices, wherein the set of training data includes, for at least some of the exemplary IoT devices, a set of time series features for applications used by the IoT devices; and generating a model, using at least a portion of the received training data, wherein the model is usable to classify a given device.
21. A method, comprising: receiving information associated with a network communication of an Internet of Things (IoT) device; determining whether the IoT device has previously been classified; in response to determining that the IoT device has not previously been classified, determining that a probability match for the IoT device against a behavior signature exceeds a threshold, wherein the behavior signature includes at least a first time series feature for an application used by the IOT device, and wherein the first time series feature for the application used by the IoT device comprises at least one of: (1) a bucket count feature for the application used by the IoT device, or (2) a session activity statistic feature for the application used by the IoT device; and based at least in part on the probability match, providing a classification of the IOT device to a security appliance configured to apply a policy to the IoT device.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210360406 A1 to Heiland et al. (hereinafter “Heiland”) in view of Pub. No.: US 20200195679 A1 to Du; Jun (hereinafter “Du”).
Regarding Claim 1. Heiland discloses A system (Heiland, Abstract, FIG. 3, FIG. 9, Para [0037]: … Methods and systems for classifying a device on a network. The systems and methods may receive network activity data associated with an unknown device. A classifier executing one or more machine learning models may then classify the device as an internet of things (IoT) device or a non-IoT device …), comprising:
a processor (Heiland, Para [0012, 0015, 0054], FIG. 3: … a processor executing instructions stored on memory … the processor is further configured to … The processor(s) 308 may be any hardware device capable of executing instructions stored on memory 310 to accomplish the objectives of the various embodiments described herein …) configured to:
receive a set of training data associated with a plurality of exemplary Internet of Things (IoT) devices (Heiland, Para [0108-0110], FIG. 9: … FIG. 9 depicts a flowchart of a method 900 for training an internet of things (IoT) device classifier in accordance with one embodiment … Step 906 involves receiving network activity data associated with each of the IoT device and the non-IoT device. The IoT and non-IoT devices may be monitored for any period(s) of time, as long as the received data is sufficient to train at least one machine learning model to accomplish the features of the embodiments described herein …), wherein the set of training data includes, for at least some of the exemplary IoT devices, a set of time series features for applications used by the IoT devices; and
However, Heiland does not explicitly teach, but Du from same or similar field of endeavor teaches:
“wherein the set of training data includes, for at least some of the exemplary IoT devices, a set of time series features for applications used by the IoT devices (Du, Para [0053, 0057, 0064, 0067, 0070, 0075]: … the network datastore 402 includes events based on messages transmitted by (or to) an IoT device. For example, one or a plurality of data packets transmitted by (or to) an IoT device can be characterized as events that can subsequently be used to determine whether the IoT device is behaving appropriately for the IoT device's given context. As another example, one or a plurality of data packets transmitted by (or to) an IoT device can be correlated to an event of a specific application being executed on the IoT device … An analytics feature is a transformation of one or more timestamped events, including composite events. As used in this paper, a composite event comprises multiple event parameters, but is referred to as an “event,” which is a more general term intended to represent a discrete event or a combination of event parameters (which can include one or more discrete events). For example, a discrete event, such as a signal transmitted from a thermometer associated with a discrete temperature sensing instance, can be combined with an event parameters for the destination of the signal, historical signal transmissions, transmissions of similarly classified IoT devices, and the like, to generate a composite event. The machine learning analytics engine 406 can determine analytics features of IoT devices in operation based on messages transmitted to or from IoT devices. For example, the machine learning analytics engine 406 can examine messages transmitted to an IoT device to determine an event which can subsequently be timestamped to create an analytics feature of the IoT device in operation. The machine learning analytics engine 406 can generate analytics features of IoT devices in operation within a time window. For example, the machine learning analytics engine 406 can examine all messages transmitted from an IoT device within a one hour period to determine a feature of the IoT device in operation. A time window, also referred to as a data rollup window, can be used by the machine learning analytics engine 406 to generate features of an IoT device in operation. For example, the machine learning analytics engine 406 can examine packets transmitted from a first IoT device over a 24 hour period and examine packets transmitted from a second IoT device over a five minute period to extract features of the first and second IoT devices in operation. A time window used by the machine learning analytics engine 406 to extract features of IoT devices in operation can vary based on contexts of the IoT devices. For example, the machine learning analytics engine 406 can vary time windows used to extract features of IoT devices in operation based on device types of the IoT devices … In a specific implementation, the machine learning analytics engine 406 trains models, represented by the models datastore 408, which are subsequently used to determine undesired behavior in IoT device operation through application of a context-based undesired behavior detection model to events and features of an IoT device … the machine learning analytics engine 406 functions to apply a context-based undesired behavior detection model to aggregated events and features of an IoT device collected in event buffers in IoT device personality classification. Advantageously, aggregation based on remote, per application, per IP, or other factors can be on a granular level. For example, the machine learning analytics engine 406 can apply a context-based undesired behavior detection model to aggregated events and features in a buffer, in an order of the events and features in the buffer. The machine learning analytics engine 406 can apply specific context-based undesired behavior detection models to events and features based on a specific event buffer in which the events and features are collected. For example, if aggregated events are in an event buffer associated with applications executing on an IoT device, then the machine learning analytics engine 406 can apply context-based undesired behavior detection models for IoT device personality classification when applications are executed at the IoT device … The machine learning analytics engine 406 can maintain a context-based undesired behavior detection model based on operation of an IoT device within a specific data window. For example, the machine learning analytics engine 406 can adjust a context-based undesired behavior detection model offline daily based on IoT device operation during the day … In an example of operation of the example system shown in FIG. 4, the machine learning analytics engine 406 identifies events of IoT devices represented as the IoT device datastore 404 from a communication medium or datastore represented as the network datastore 402, uses machine learning to train behavioral models represented as the models datastore 408, and outputs event-related risk parameters associated with IoT device behavior to the predicted risk parameters datastore 410 … …)”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Du into the teachings of Heiland, because it discloses that, “In a specific implementation, the machine learning analytics engine 406 functions to apply a context-based undesired behavior detection model to aggregated events and features of an IoT device collected in event buffers in IoT device personality classification. Advantageously, aggregation based on remote, per application, per IP, or other factors can be on a granular level. For example, the machine learning analytics engine 406 can apply a context-based undesired behavior detection model to aggregated events and features in a buffer, in an order of the events and features in the buffer. The machine learning analytics engine 406 can apply specific context-based undesired behavior detection models to events and features based on a specific event buffer in which the events and features are collected. For example, if aggregated events are in an event buffer associated with applications executing on an IoT device, then the machine learning analytics engine 406 can apply context-based undesired behavior detection models for IoT device personality classification when applications are executed at the IoT device (Du, Para [0068])”.
Heiland further discloses:
“generate a model, using at least a portion of the received training data, wherein the model is usable to classify a given device (Heiland, Para [0067-0068, 0076], FIG. 3, FIG. 9: … The collected data regarding the network activity essentially acts a training set that can be communicated to the model generation module 322 to train one or more machine learning models to distinguish between IoT devices and non-IoT devices … Before the gathered data is communicated to the model generation module 322, however, the feature engineering module 320 may perform any appropriate feature engineering process … the model generation module 322 may receive the engineered data, along with an indication of whether each device associated with the data is an IoT device or a non-IoT device. The model generation module 322 may then build one or more models to be used by the classifier 324 to classify unlabeled network devices as IoT devices or non-IoT devices …); and
a memory coupled to the processor and configured to provide the processor with instructions (Heiland, Para [0012]: … embodiments relate to a system for classifying a device on a network. The system includes an interface for receiving network activity data associated with a device on a network, and a processor executing instructions stored on memory …).”
Regarding Claim 2. The combination of Heiland-Du discloses the system of claim 1, Du further discloses, “wherein the set of time series features comprise at least one of: (1) a bucket count feature for a given application used by a given device, or (2) a session activity statistic feature for the given application used by the given device (Du, Para [0064]: … In a specific implementation, the machine learning analytics engine 406 functions to add aggregated events and features into an event buffer. An event buffer includes a collection of events and features that are held for a period of time and analyzed to determine whether an IoT device is exhibiting undesired behavior in operation. An event buffer can be specific to a context associated with an IoT device in operation. For example, an event buffer can be associated with or specific to an application and can be used to determine whether an IoT device is exhibiting undesired behavior in operation when the application is executing at the IoT device. In another example, an event buffer can be associated with IoT devices of a specific device type and can be used to determine whether an IoT device of the device type is exhibiting undesired behavior in operation. The machine learning analytics engine 406 can buffer aggregated events and features into event buffers based on contexts associated with aggregated events and features, e.g. contexts of an IoT device in operation. For example, the machine learning analytics engine 406 can buffer aggregated events and features into an event buffer based on whether the events are one or a combination of device sensor events, session events, application events, user events, protocol events, and status events …).”
The motivation to further combine Du remains same as in claim 1.
Regarding Claim 16. The combination of Heiland-Du discloses the system of claim 1, Du further discloses, “wherein at least a portion of a network communication made by the given device is encrypted (Du, Para [0083]: … FIG. 6 depicts a progressive risk prediction graph 600. The progressive risk prediction graph 600 illustrates how activity graphs (specifically, those activity graphs associated with baseline risk and threat vectors) can be meaningfully combined with IoT device behavior to provide risk scores in a human-understandable format. The progressive risk prediction graph 600 includes data 602-1 to data 602-n (collectively the data 602), respectively associated with input layer features 604-1 to input layer features 604-n (collectively the input layer features 604). For illustrative purposes, the input layer feature 604-1 is “remote IPs,” the input layer feature 604-2 is “risky sites,” and the input layer feature 604-3 is “insecure apps,” but the specific designation is not critical to understanding. Depending upon implementation-specific, configuration-specific, or other factors, the input layer features can include publicly recognized vulnerabilities (e.g., CVEs), power off in operational state, malfunction causes health risk, type of device, Wi-Fi, encrypted Wi-Fi, Bluetooth, public DNS, or the like. …).”
The motivation to further combine Du remains same as in claim 1.
Regarding Claim 17. This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
Claims 3-4, 6-12 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210360406 A1 to Heiland et al. (hereinafter “Heiland”) in view of Pub. No.: US 20200195679 A1 to Du; Jun (hereinafter “Du”), as applied to claim 1 above, and further in view of Pub. No. US 20220393987 A1 to SAWABE; Anan (hereinafter “SAWABE”).
Regarding Claim 3. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a maximum usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: … FIG. 1 illustrates an example of a schematic configuration of a system 1 according to the first example embodiment. With reference to FIG. 1, the system 1 includes a network 10, a source apparatus (source device) 20 … the source apparatus 20 transmits packets (in other words, data) to the destination apparatus 30 via the network 10. For example, a series of packets (a series of data) transmitted from the source apparatus 20 to the destination apparatus 30 may be referred to as traffic or communication traffic. The series of packets (the series of data) may be referred to as a communication flow. The communication flow herein means a series of packets (a series of data) having the same Internet Protocol (IP) address and the same port number, for example. It can be said that the IP address is a location identifier of an apparatus (device), and the port number is an identifier of an application in the apparatus … the source apparatus 20 is an IoT device, and the destination apparatus 30 is a server (for example, a cloud server) that receives data from the IoT device … the conversion apparatus 100 (determination section 140) determines the transmission timing of each of the plurality of divided communication flows so that the transmission timing of each of the plurality of divided communication flows matches the selected traffic characteristic … The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like) … FIG. 9 illustrates an example of a transmission timing determination method of individual divided communication flows … transmission timing of communication flow 1 is a start time point of a cycle, transmission timing of communication flow 2 is a time point that is time 41 later than the start time point of the cycle, transmission timing of communication flow 3 is a time point that is time 43 later than the start time point of the cycle, and transmission timing of communication flow 4 is a time point that is time 45 later than the start time point of the cycle … The transmission timings of the divided communication flows determined by the conversion apparatus 100 (determination section 140) may be specific timings (the time 41, the time 43, and the time 45) as illustrated in FIG. 9 … The source apparatus 20 transmits a packet belonging to the original communication flow (in other words, a packet of data generated by an application operating in the source apparatus 20) (S410). The conversion apparatus 100 (reception section 110) receives the packet belonging to the original communication flow …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 4. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a minimum usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 6. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a sum of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0143, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each … as described above, not only one traffic characteristic but two or more traffic characteristics may be selected. In this case, the following combinatorial problem may be solved: how many communication flows matching each of the two or more traffic characteristics are necessary for reconstruction of the original communication flow. For example, provided that each of the two or more traffic characteristics is represented by index i, the number of packets in a cycle necessary for implementation of the traffic characteristic i is represented by Ni, the number of communication flows matching the traffic characteristic i is represented by Mi, and the number of packets in a cycle of the original communication flow is represented by x, Mi is a minimum integer that satisfies the following relationship. x≤ΣN.sub.i×M.sub.i …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 7. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a mean of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 8. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a variance of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 9. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a median of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 10. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a kurtosis of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 11. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a skewness of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Regarding Claim 12. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but SAWABE from same or similar field of endeavor teaches, “wherein the set of time series features includes a quantile of usage of a given application across a plurality of time buckets (SAWABE, Abstract, Para [0048-0053, 0058, 0112, 0152-0158]: ... The traffic characteristic includes, for example, distribution of a packet size (bit) and/or a packet arrival interval (s) or statistical amounts (the maximum value, the minimum value, the average value, the median, variance, standard deviation, kurtosis, skewness, and/or the like). In many cases, communication of an IoT device has cyclicity, and thus the traffic characteristic may include a cycle (s) and/or a packet string for each …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of SAWABE into the teachings of Heiland-Du, because it discloses that, “owing to enhancement of data analysis technology such as statistics and machine learning, analysis of characteristics of communication traffic such as statistical amounts of a packet size and a packet arrival interval has enabled identification of not only a communication protocol but also an application and an IoT device type. Such analysis technology of communication traffic can be utilized for improvement of communication quality for encrypted traffic and the like. However, if a malicious user uses the analysis technology, information of a transmission source of communication traffic may be indirectly estimated, which may lead to an attack to IoT services as described above. Performing a security attack using information of a transmission source indirectly estimated by analyzing communication traffic as described above is known as Traffic analysis attack. With Traffic analysis attack, in particular, a web access destination of a user may be estimated from the communication traffic, and privacy such as access tendency of each user may become known to the malicious user … object of the present disclosure is to provide a method, a system, and a conversion apparatus that cause incorrect estimation regarding a transmission source through analysis of communication traffic … (SAWABE, Para [0004, 0008])”.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210360406 A1 to Heiland et al. (hereinafter “Heiland”) in view of Pub. No.: US 20200195679 A1 to Du; Jun (hereinafter “Du”), as applied to claim 1 above, and further in view of Pub. No. US 20200177485 A1 to Shurtleff et al. (hereinafter “Shurtleff”).
Regarding Claim 5. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but Shurtleff from same or similar field of endeavor teaches, “wherein the set of time series features includes a count of a number of non-zero buckets corresponding to times during which a given application was used (Shurtleff, Abstract, Para [0032, 0109], FIG. 5: … An IoT management system can determine historical traffic volumes of a plurality of IoT devices over one or more time intervals. The IoT management system can determine historical temporal traffic metrics of the IoT devices over the time intervals. The IoT management system can determine standard deviation information for at least one of the historical traffic volumes or the historical temporal traffic metrics over the time intervals. The IoT management system can determine current traffic volumes of the IoT devices. The IoT management system can determine current temporal traffic volumes of the IoT devices … The telemetry subsystem 210 can alternatively or additionally capture or compute statistical information (e.g., mean, median, mode, minimum, maximum, standard deviation(s), etc.) and/or other measures of network performance (e.g., bandwidth or capacity, throughput, delay, latency, jitter, data loss and other errors, etc.). The telemetry subsystem 210 can also generate reports from the network traffic data for presentation (e.g., via the user interface subsystem 206) to end users … During the course of monitoring the IoT devices, the IoT management system can track various network traffic metrics for each IoT device over various intervals of time, such as over one-hour periods, two-hour periods, four-hour periods, eight-hour periods, 12-hour periods, daily periods, weekly periods, bi-weekly periods, monthly periods, and so forth. For example, the IoT management can calculate at step 506 the network traffic volumes of the IoT devices over the various intervals. In some embodiments, the IoT management system can distinguish between upload network traffic volumes and download network traffic volumes of each IoT device. In some embodiments, the IoT management system can also calculate at step 508 temporal network traffic metrics of the IoT devices over the same time intervals. Temporal network traffic metrics can include upload and/or download throughputs (e.g., traffic volume per unit of time, such as Mb/s, MB/s, Gb/s, GB/s, etc.), changes in upload and/or download throughputs (e.g., throughput per unit of time, such as Mb/s.sup.2, MB/s.sup.2, Gb/s.sup.2, GB/s.sup.2, etc.), latencies, jitter, data loss, errors, and other network traffic metrics relative to time …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shurtleff into the teachings of Heiland-Du, because it discloses that, “The secure connection 118 may utilize portions of the WAN 112. For example, packets that are transmitted via the secure connection 118 can be marked and/or contain header fields that enable the prioritization of the secure tunnel packets on at least some portions of the WAN 112. In some embodiments, the prioritization of the secure tunnel packets can include the use of private, dedicated routing paths between the management network 114, the fog cloud 120, and/or the IoT cloud 130 to reduce latency and/or improve reliability (Shurtleff, Para [0018])”.
Claims 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210360406 A1 to Heiland et al. (hereinafter “Heiland”) in view of Pub. No.: US 20200195679 A1 to Du; Jun (hereinafter “Du”), as applied to claim 1 above, and further in view of Pub. No. US 20170093915 A1 to Ellis et al. (hereinafter “Ellis”).
Regarding Claim 13. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but Ellis from same or similar field of endeavor teaches, “wherein an organizationally unique identifier (OUI) for the given device is not available (Ellis, Para [0036]: … In the event a query or control command is sent from the user access device 124 when participating and/or otherwise connected to a network other than the HAN 120, then the example cloud user access device interface 142 of the cloud server 134 generates a runtime trigger. The query or control command information, which includes a target IoT device name and/or identifier (e.g., Device 1, Device 2, etc.), is used by the example cloud policy resolution manager 140 in a query to the example cloud tag data storage 146 of the cloud storage 144. In the event parameters associated with the IoT device name and/or identifier are unavailable, then the query and/or control command is not authorized, and the cloud user access device interface 142 notifies the requesting user access device 124 that access to the requested IoT device is unavailable. As described above, information associated with devices that are not authorized to be accessed outside the HAN 120 and/or by one or more third parties may be withheld from storage in the example cloud storage 144, thereby prohibiting disclosure of personal information …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ellis into the teachings of Heiland-Du, because it discloses that, “As described above, information associated with devices that are not authorized to be accessed outside the HAN 120 and/or by one or more third parties may be withheld from storage in the example cloud storage 144, thereby prohibiting disclosure of personal information (Ellis, Para [0036])”.
Regarding Claim 14. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but Ellis from same or similar field of endeavor teaches, “wherein an OUI for the given device corresponds to a network io card (Ellis, Para [0063]: … The interface circuit 920 of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network 926 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.) …) and wherein the given device is not a network card appliance (Ellis, Para [0007]: … The example IoT thermostat may also include logic to transmit the temperature information to a network destination, such as a power utility company. In some examples, the power utility company can control the actuators based on energy savings opportunities, such as reduced energy rates during certain times of day. In still other examples, the IoT thermostat may include logic to identify user trends within the room and control the actuator(s) based on observed user behaviors without transmitting the temperature data on the network. However, without receiving and/or otherwise retrieving the temperature data, the power utility company may not be able to calculate and/or otherwise generate suggestions, incentives and/or promotions for the facility (e.g., household, building, business, factory, etc.) in which the IoT thermostat resides …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ellis into the teachings of Heiland-Du, because it discloses that, “in the event a household elects to completely disable the networking capabilities of the example IoT thermostat, then troubleshooting and/or service opportunities of the device cannot be fixed. In other words, because the example IoT thermostat cannot separate personal data from operational data, household user adoption of IoT devices aimed at providing both consumer benefits and utility benefits cannot be realized. Examples disclosed herein protect user privacy by separating user data from operational data. As such, a greater degree of trust for any IoT devices is fostered and IoT service adoption is improve (Ellis, Para [0008])”.
Regarding Claim 15. The combination of Heiland-Du discloses the system of claim 1, however it does not explicitly teach, but Ellis from same or similar field of endeavor teaches, “wherein an OUI for the given device corresponds to a network appliance and wherein the given device is not a network appliance (Ellis, Para [0052]: … Additional detail associated with managing runtime trigger(s) (block 308) is shown in FIG. 8A. In the illustrated example of FIG. 8A, the example system 100 determines whether a runtime trigger occurs from one or more of (1) an IoT device, (2) a user access device 124 within the HAN 120, or (3) a user access device 124 outside the HAN 120 (block 802). If the example edge node interface 112 detects a trigger from an IoT device, such as one or more of the example first sensor 114, the example second sensor 116, etc. (block 802), then the example smart building gateway 102 manages the IoT device trigger (block 804), as described in further detail below in connection with FIG. 8B. If the example local user access device interface 122 or the example cloud user access device interface 142 detects a trigger from a user access device 124 (block 802), then a respective one of the example smart building gateway 102 or the example cloud server 134 manages the user device trigger (block 806), as described in further detail below in connection with FIG. 8C. As described above, the example network identifier 170, which could be a user installed application on a mobile phone, may force communication to occur only via WiFi when the example HAN 120 is detected …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ellis into the teachings of Heiland-Du, because it discloses that, “in the event a household elects to completely disable the networking capabilities of the example IoT thermostat, then troubleshooting and/or service opportunities of the device cannot be fixed. In other words, because the example IoT thermostat cannot separate personal data from operational data, household user adoption of IoT devices aimed at providing both consumer benefits and utility benefits cannot be realized. Examples disclosed herein protect user privacy by separating user data from operational data. As such, a greater degree of trust for any IoT devices is fostered and IoT service adoption is improved (Ellis, Para [0008])”.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20210203565 A1; Arora et al.: Arora discloses methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for training and using machine learning models to classify network traffic as IoT traffic or non-IoT traffic and managing the traffic based on the classification. In some implementations, machine learning parameters of a local machine learning model trained by the edge device is received each of at least a subset of a set of edge devices. The machine learning parameters received from an edge device are parameters of the local machine learning model trained by the edge device based on local network traffic processed by the edge device and to classify the network traffic as Internet of Things (IoT) traffic or non-IoT traffic. A global machine learning model is generated, using the machine learning parameters, to classify network traffic processed by edge devices as IoT traffic or non-IoT traffic.
US 20220086071 A1; SIVARAMAN et al.: SIVARAMAN discloses A network device classification process, including: monitoring network traffic of networked devices in a communications network to generate device behaviour data representing network traffic behaviours of the networked devices at different time granularities; processing the device behaviour data to classify a plurality of the networked devices as IoT devices, and others of the networked devices as non-IoT devices; accessing IoT device type data representing predetermined network traffic characteristics of respective known IoT device types; processing the device behaviour data of the IoT devices and the IoT device type data to classify each of the IoT devices as being a corresponding one of the plurality of known IoT device types; and for each of the IoT devices classified as a corresponding known IoT device type, classifying the IoT device as being in a corresponding operating state based on network traffic behaviours of the IoT device at different time granularities.
US 20230188552 A1; SERN et al.: SERN discloses a system and method for detecting the presence of Internet of Things (IoTs) from network traffic that has undergone a Network Address Translation (NAT) process, i.e., NATed network traffic, regardless of whether the network traffic comprises IP Flow Information Export (IPFIX) type of traffic or Domain Name System (DNS) type of traffic. Such a capability is crucial as the adoption rate of IoTs have increased exponentially over the past few years. In order to protect IoTs from cyber-attacks, one would first have to understand what type of IoTs are being used, and how many/how widely used these IoTs are. Once the IoT landscape has been defined, cyber defenders may then dedicate resources to identify and subsequently address vulnerabilities that may be in these IoTs.
US 20190098028 A1; Ektare et al.: Ektare discloses techniques for visualizing IoT device management. A system utilizing such techniques can include an IoT device risk assessment system and an IoT device management visualization system. A method utilizing such techniques can include grouping IoT devices into an IoT device dimension group based on IoT device dimensions defining the group and controlling presentation of management data for the IoT devices based on the grouping of the IoT devices into the IoT device dimension group.
US 20200409957 A1; Zhang et al.: Zhang discloses A query requesting a count of unique data values for a specific attribute is received. The received query is used to generate and transmit a plurality of non-overlapping queries to a data store. A plurality of responses is received from the data store. Results from the plurality of responses is summed and the resulting sum is returned.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST 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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434
Prosecution Insights