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 .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant’s arguments in view of the amended claim limitation “a second given tag included in the set of tag labels indicates a particular home server location that devices of the specific first model connect to” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lin (US 9,038,178 B1).
Where Applicant argues that “[n]either Devi Reddy nor Epstein, whether considered individually or in combination, discloses identifying a particular device as a specific model in such a manner or taking such an action in response to determination of a bad personality,” It is noted that Reddy in combination with Epstein describes aspects of the claim elements as per the rejection below. For instance, at least [0031] and [0097]-[0099] of Reddy concern generating threat scores for entities in the local network. The threat scores may be numeric values that represent the likelihood that an entity is associated with a security threat. In some embodiments, the security analytics system uses a threshold for a threat score to determine whether an entity is exhibiting malicious behavior. If the security analytics system determines that a security threat is present in the local network, it can provide an indication of the security threat to a network administrator for the local network. Upon determining that a security threat is present in the local network, the threat control module alerts the network administrator to the security threat. In some embodiments, the network administrator is alerted through a user interface of an application that is running on a client device associated with the network administrator. In some embodiments, the network administrator is alerted through an email, text message, phone call, or notification on a mobile application.
Reddy does not specify identifying “that the first device is of a specific model” as per Applicant’s arguments. However, at least the abstract, FIG. 2, [0013]-[0014], [0017], [0019], [0023], [0028], and [0032] of Epstein concern identifying all devices in a home from a domain of many device models. For instance, device signatures are grouped according to clusters describing device information (e.g., the OS of the device), and the device signatures are used for identifying unknown devices as being a particular one of the models (e.g., ACME TV XT430).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: the “network administration engine; domain knowledge datastore; IoT device demographics generation engine; IoT personality datastore; personality classification engine; signal correlation engine; new personality discovery engine; personality aware enrichment engine; and offline modeling engine” in claims 12-22.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For instance, paragraphs [0027]-[0030] of the specification describing engines and datastores.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-9, 11-20, and 22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Independent claim 1 contains the following subject matter which was not described in the specification: “wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag.” While [0045], [0073], and [0075] of the instant specification describe device models having shared tags / labels, they do not explicitly define tags / labels unique to a particular device model. In [0098], “ID” and “MAC address” are mentioned as being used to classify and label devices, but IDs need not be unique and MAC addresses may be spoofed. Without an explicit recitation of uniqueness, these may not necessarily comprise second device models not sharing at least tags. Additionally, the claimed “first given tag” and “second given tag” are defined as being drawn to “a particular operating system” and “a particular home server location that devices of the specific first model connect to.” These are not described as being unique or exclusive in the instant specification.
Independent claim 12 recites substantially the same claim language and is therefore likewise rejected for the same reasons. The dependent claims do not rectify the above issue, and are therefore likewise rejected with their respective parent claims.
For the purpose of applying prior art, “wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag” has been interpreted as a general statement that different device models may have different tags (e.g., having a different operating system or calling a different server).
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9, 11-20, and 22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Independent claim 1 recites “wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag,” because it is not clear whether the other devices of a second specific model and their respective tags are part of the claim scope. The claim does not positively recite the “other devices of a second specific model” beyond the passing mention in the limitation. These other devices may have nothing to do with any of the claim steps and claim structure. For example, “other devices of a second specific model” may be referring to kitchen tools or vehicle engines, or other such devices without any network functionality or behavior. This claim limitation may also be interpreted as referring to “other devices” on the same network which are classified as part of the flow of the claim steps. Therefore, the language of the claim is such that a person of ordinary skill in the art could not interpret the metes and bounds of the claim so as to understand how to avoid infringement.
Independent claim 12 recites substantially the same claim language and is therefore likewise rejected for the same reasons. The dependent claims do not rectify the above issue, and are therefore likewise rejected with their respective parent claims.
For the purpose of applying prior art, “wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag” has been interpreted as a general statement that different device models may have different tags (e.g., having a different operating system or calling a different server).
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.
Claim(s) 1-5, 11-16, and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Devi Reddy (US 2017/0118240 A1), hereinafter “Reddy,” in view of Epstein (US 2017/0262523 A1) and Lin (US 9,038,178 B1).
Regarding claim 1, Reddy discloses: A method comprising:
for a first device included in a plurality of Internet of Things (IoT) devices (e.g., FIG. 1 and [0032] of Reddy concerning client devices; as per [0132]-[0133] of Reddy, the client may be an IoT device):
identifying a context of the device in operation at least in part by analyzing packets sent to and from the device, determining a set of events associated with the device and occurring within a window, and aggregating a plurality of events within the window based on the identified context;
Refer to at least [0038]-[0056] and [0065]-[0066] of Reddy with respect to collecting raw data such as network traffic and DPI logs, aggregating the data, and timestamps and normalization associated with the context of the raw data.
performing common factor aggregation of enriched metadata derived from event parameters associated with the plurality of IoT devices to obtain aggregated metadata permutations, wherein the first device has at least a first behavior aggregation factor and a second behavior aggregation factor and wherein a second device included in the plurality of IoT devices has a third behavior aggregation factor that is different from the first and second behavior aggregation factors;
Refer to at least [0104], [0070]-[0071], [0105], and FIG. 7, of Reddy with respect to determining properties of identified entities and information such as the type and/or MAC address of the entity. Shared properties are identified and mapped.
Refer to at least FIG. 6 and [0060]-[0067] of Reddy with respect to data normalization.
using machine learning to obtain domain knowledge, including knowledge regarding at least one bad IoT personality, from a network administration engine, wherein a given personality includes one or more modelled behavior patterns, and wherein the bad IoT personality includes at least one modelled behavior pattern indicative of undesired behavior;
Refer to at least [0091], [0096], and [0058] of Reddy with respect to obtaining third-party and/or administrator-provided information of known security threats.
Refer to at least [0090] and [0113] of Reddy with respect to generating machine-learned models of the entities. Examples include behavior such as the range of IP addresses with which an entity communicates, as well as a learned type of the entity (user, device, role).
defining a personality, including data samples associated with the personality, using the aggregated metadata permutations obtained by performing the common factor aggregation, the domain knowledge, and prior personality data set feedback from a new personality profile discovery engine;
Refer to at least FIG. 5, FIG. 6, [0117], and [0113] of Reddy with respect to generating machine-learned models of the entities based on information from the previous steps.
classifying the personality using the data samples and IoT personality models, wherein the personality has a signal associated therewith; and
correlating the signal to reach a verdict, including by determining a degree of risk of undesirable behavior for the first device,
Refer to at least 540-570 in FIG. 5 and [0098] of Reddy with respect to determining a threat score.
Refer to at least [0031] and [0097]-[0099] of Reddy with respect to a threshold for the threat score to determine whether an entity is exhibiting malicious behavior.
and providing a bad personality alert to the network administration engine in response to determining that the degree of risk of undesirable behavior exceeds an actionable intelligence threshold.
Refer to at least [0098] of Reddy with respect to determining a threat score and a resultant remedial action, such as alerting a user. The threat control module alerts the network administrator to the security threat. In some embodiments, the network administrator is alerted through a user interface of an application that is running on a client device associated with the network administrator. In some embodiments, the network administrator is alerted through an email, text message, phone call, or notification on a mobile application.
Reddy does not fully disclose: wherein classifying the personality includes identifying, and providing as output, that the first device is of a specific first model, wherein other devices of the specific first model share a set of tag labels that describe particular behaviors taken by devices of the specific first model, wherein first a given tag included in the set of tag labels indicates: a particular operating system that devices of the specific first model run and a second given tag included in the set of tag labels indicates a particular home server location that devices of the specific first model connect to, and wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag; the correlating being further based at least in part on the identified specific first model. However, Reddy in view of Epstein discloses: wherein classifying the personality includes identifying, and providing as output, that the first device is of a specific first model,
Refer to at least [0014], [0023], and [0032] of Epstein with respect to outputting a name for device identification based on device signatures. For example, “ACME TV XT430” in FIG. 2 of Epstein.
wherein other devices of the specific first model share a set of tag labels that describe particular behaviors taken by devices of the specific first model,
Refer to at least FIG. 2, [0017], and [0019] of Epstein with respect to clustering device signatures (signature data as in [0015] and [0028] of Epstein), where clusters are associated with devices having the same device model. For example, cluster 38(2) in FIG. 2 of Epstein is associated with the device model “ACME TV XT430.”
wherein first a given tag included in the set of tag labels indicates: a particular operating system that devices of the specific first model run;
Refer to at least [0017], [0019], and [0028] of Epstein with respect to an operating system attribute as part of the signature clustering.
wherein other devices of a second specific model do not share at least one of either the first given tag or the second given tag;
Refer to at least [0041] of Epstein with respect to unique identifiers for device signatures; at least [0028] of Epstein with respect to different coordinates in signatures (e.g., a lists of open ports, operating system version, DHCP option list, MAC address, and UPnP settings).
the correlating being further based at least in part on the identified specific first model.
Refer to at least [0013] of Epstein with respect to responding to potential security threats benefitting from the identification of the model of each and every device in the home; at least [0035] of Epstein with respect to threat prioritization based on the identification.
The teachings of Epstein likewise concern detecting security threats in a network and classifying network devices, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Reddy to further implement more specific device identification using device signature clustering as in Epstein for at least the purpose of improving classification accuracy and security enforcement (e.g., [0002] and [0013] of Epstein stating that “[f]or security and other reasons it is very useful to know the type, make and model of each connected device in the home in order to make appropriate decisions based on the device type, make and model”).
Reddy-Epstein does not specify: a second given tag included in the set of tag labels indicates a particular home server location that devices of the specific first model connect to. However, Reddy-Epstein in view of Lin discloses: a second given tag included in the set of tag labels indicates a particular home server location that devices of the specific first model connect to.
Refer to at least FIG. 6, Col. 2, LI. 65-Col. 3, LI. 2, and Col. 11, LI. 25-35, and Col. 12, LI. 19-41 of Lin with respect to logging device behaviors, including contacting an external server (e.g., malware phoning to a home C&C server). Behavior features include geolocation information of the external server (e.g., Col. 8, LI. 25-29 of Lin.
The teachings of Reddy-Epstein and Lin concern machine learning and behavioral modeling, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant's invention to modify the teachings of Reddy-Epstein to further include obtaining beaconing activities as part of behavior features for at least the purpose of better detecting APT attacks and infiltrations (e.g., Col. 2, LI. 4-9 of Lin).
Regarding claim 2, Reddy-Epstein-Lin discloses: The method of claim 1, wherein the personality is built by mathematically modeling a behavior pattern using the event parameters.
Refer to at least [0009] and [0030] of Reddy with respect to models of entity behavior.
Regarding claim 3, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations concerning the raw data, normalization, relationships, and graph).
Regarding claim 4, it is rejected for substantially the same reasons as claims 1 and 3 above.
Regarding claim 5, Reddy-Epstein-Lin discloses: The method of claim 1, wherein the aggregated metadata permutations are aggregated over a data rollup window that varies based on the context of the IoT device.
Refer to at least [0071]-[0072] and [0065]-[0066] of Reddy with respect to timeframes and timestamps associated with a context provided by device and network data.
Regarding claim 11, it is rejected for substantially the same reasons as claim 1 above (e.g., [0091], [0096], and [0058] of Reddy).
Regarding independent claim 12, it is substantially similar to claim 1 above, and is therefore likewise rejected (i.e., see the citations).
Regarding claims 13-16 and 22, they are substantially similar to claims 2-5 and 11 above, and are therefore likewise rejected.
Claim(s) 6-9 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Reddy-Epstein-Lin as applied to claims 1-5, 11-16, and 22 above, and further in view of Sukhomlinov (US 2017/0180399 A1).
Regarding claim 6, Reddy-Epstein-Lin does not specify: further comprising: performing offline modeling using the data samples; and updating the IoT personality models with the offline modeling. However, Reddy-Epstein in view of Sukhomlinov discloses: further comprising: performing offline modeling using the data samples; and updating the IoT personality models with the offline modeling.
Refer to at least [0022], [0032], and [0056] of Sukhomlinov with respect to online or offline model creation and updating.
The teachings of Reddy-Epstein-Lin and Sukhomlinov concern machine learning and behavioral modeling, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Reddy-Epstein-Lin to further include offline modeling because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (e.g., as per the cited portions of Sukhomlinov concerning online and offline creation/updating).
Regarding claim 7, it is rejected for substantially the same reasons as claims 1 and 6 above (i.e., the citations and obviousness rationale).
Regarding claim 8, Reddy-Epstein-Lin-Sukhomlinov discloses: The method of claim 1, comprising: recognizing behavior patterns of the IoT device using either or both learned state-transition learning and deep learning.
Refer to at least [0056] of Sukhomlinov with respect to model training and states.
This claim would have been obvious for substantially the same reasons as claim 6 (i.e., substitution of known-in-the-art machine learning techniques and technologies).
Regarding claim 9, Reddy-Epstein-Lin-Sukhomlinov discloses: The method of claim 1, comprising: recognizing behavior patterns of the IoT device using either or both a neural network graph of past behavior patterns of the IoT device recognized using deep learning and a state transition graph of the past behavior patterns of the IoT device recognized using learned state-transition learning.
Refer to at least [0040]-[0041] and [0056] of Sukhomlinov with respect to neural networks and algorithms.
This claim would have been obvious for substantially the same reasons as claim 6 (i.e., substitution of known-in-the-art machine learning techniques and technologies).
Regarding claims 17-20, they are substantially similar to claims 6-9 above, and are therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
