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 .
This office action is responsive to application filed on March 19th, 2025. In this office action:
Claims 1-22 are pending
Claims 1-22 are rejected
Drawings
The drawings submitted on March 19th, 2025 have been considered and accepted.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on May 14th, 2025, September 18th, 2025, October 24th, 2025, and June 4th, 2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the Examiner.
Claim Objections
Claims 1-4, 8-14, 18-20 are objected to because of the following informalities:
“the IoT application events” should read (Examiner’s suggestion) “the set of IoT application events.”
Claims 1, 7, 11, 17 are objected to because of the following informalities:
“the predicted activities” should read (Examiner’s suggestion) “the predicted set of activities.”
Claims 5 and 15 are objected to because of the following informality:
“characterizing the application-specific activities” should read (Examiner’s suggestion) “characterizing the one or more application-specific activities.”
Claim 11 is objected to because of the following informality:
“identify, from a predetermined set of different set of different types of activities ...” should read (Examiner’s suggestion) “identify, from a predetermined set of different types of activities ...”
Appropriate correction(s) is/are required.
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 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:
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;
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
the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the words “engine.” Such claim limitations are: Claim 11 recites a “payload learning engine” configured to perform automated payload learning ... and an “IoT application reporting engine” configured to determine whether at least one of the IoT application events falls outside the predicted activities and generate an alert.
According to Applicant’s specification, Parag. [0019], As used in this paper, an engine includes one or more processors or a portion thereof. A portion of one or more processors can include some portion of hardware less than all of the hardware comprising any given one or more processors ...
Therefore, the Examiner interprets the “payload learning engine” and the “IoT application reporting engine” as hardware processors.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations 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 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 them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using webscreens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-4, 7-14, and 17-22 are rejected on the ground of the nonstatutory double patenting as being unpatentable over claims 1-18 of Patent No. US 12,294,482. Although the claims at issue are not identical, they are not patentably distinct from each other as illustrated in the table below. The subject matter claimed in the instant application is fully disclosed in the referenced patent since the referenced patent and the instant application are claiming common subject matter, as shown in Table below.
Regarding Claim 1
This application 19/084,500
Patent US 12,294,482
1. A method comprising:
receiving a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application;
identifying, from a predetermined set of different types of activities, one or more application-specific activities using the IoT application events;
generating activity parameters at least in part by performing automated payload learning of the IoT application;
predicting a set of activities of the IoT application in accordance with the activity parameters at least in part by using domain knowledge;
determining whether at least one of the IoT application events falls outside the predicted activities;
generating an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted activities.
1. A method, comprising:
receiving a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application executing on an IoT device;
identifying, from a predetermined set of different types of activities, one or more application-specific activities;
extracting one or more attributes from a plurality of payloads of IoT messages associated with the IoT application executing on the IoT device as a set of activity parameters and using extracted information to perform automated payload learning, wherein the extracting includes filtering out one or more confidential values;
predicting a set of activities of the IoT application in accordance with the set of activity parameters at least in part by using domain knowledge;
determining whether at least one of the IoT application events falls outside the predicted set of activities; and
generating an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted set of activities.
Regarding Claim 2
This application 19/084,500
Patent US 12,294,482
2. The method of claim 1, wherein the IoT application events are detected via passive monitoring.
2. The method of claim 1, wherein the IoT application events are detected via passive monitoring.
Regarding Claim 3
This application 19/084,500
Patent US 12,294,482
3. The method of claim 1, wherein the IoT application events are detected using deep packet inspection (DPI).
3. The method of claim 1, wherein the IoT application events are detected using deep packet inspection (DPI).
Regarding Claim 4
This application 19/084,500
Patent US 12,294,482
4. The method of claim 1, wherein the IoT application events are detected using subscription-based inspection.
4. The method of claim 1, wherein the IoT application events are detected using subscription-based inspection.
Regarding Claim 7
This application 19/084,500
Patent US 12,294,482
7. The method of claim 1, wherein using the domain knowledge to predict activities includes identifying a repeating pattern.
5. The method of claim 1, wherein using the domain knowledge to predict the set of activities includes identifying a repeating pattern.
Regarding Claim 8
This application 19/084,500
Patent US 12,294,482
8. The method of claim 1, wherein using the domain knowledge to predict activities includes utilizing tags or labels injected into activity fields of the IoT application events.
6. The method of claim 1, wherein using the domain knowledge to predict the set of activities includes utilizing tags or labels injected into activity fields of the IoT application events.
Regarding Claim 9
This application 19/084,500
Patent US 12,294,482
9. The method of claim 1, wherein an IoT application event of the IoT application events comprises a raw event.
7. The method of claim 1, wherein an IoT application event of the IoT application events comprises a raw event.
Regarding Claim 10
This application 19/084,500
Patent US 12,294,482
10. The method of claim 1, wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events.
8. The method of claim 1, wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events.
Regarding Claim 11
This application 19/084,500
Patent US 12,294,482
11. A system comprising:
a processor configured to:
receive a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application;
identify, from a predetermined set of different set of different types of activities, one or more application-specific activities using the IoT application events;
predict a set of activities of the IoT application in accordance with activity parameters at least in part by using domain knowledge;
a payload learning engine configured to perform automated payload learning of the IoT application to generate the activity parameters;
an IoT application reporting engine configured to:
determine whether at least one of the IoT application events falls outside the predicted activities;
generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the engine configured to:
determine whether at least one of the IoT application events falls outside the predicted activities; generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted activities; and
a memory coupled to the processor and configured to provide the processor with instructions
9. A system, comprising:
a processor configured to:
receive a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application executing on an IoT device;
identify, from a predetermined set of different types of activities, one or more application-specific activities;
...
predict a set of activities of the IoT application in accordance with the set of activity parameters at least in part by using domain knowledge;
extract one or more attributes from a plurality of payloads of IoT messages associated with the IoT application executing on the IoT device as a set of activity parameters and use extracted information to perform automated payload learning, wherein the extracting includes filtering out one or more confidential values;
determine whether at least one of the IoT application events falls outside the predicted set of activities; and
generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted set of activities; and
a memory coupled to the processor and configured to provide the processor with instructions.
Regarding Claim 12
This application 19/084,500
Patent US 12,294,482
12. The system of claim 11, wherein the IoT application events are detected via passive monitoring.
10. The system of claim 9, wherein the IoT application events are detected via passive monitoring.
Regarding Claim 13
This application 19/084,500
Patent US 12,294,482
13. The system of claim 11, wherein the IoT application events are detected using deep packet inspection (DPI).
11. The system of claim 9, wherein the IoT application events are detected using deep packet inspection (DPI).
Regarding Claim 14
This application 19/084,500
Patent US 12,294,482
14. The system of claim 11, wherein the IoT application events are detected using subscription-based inspection.
12. The system of claim 9, wherein the IoT application events are detected using subscription-based inspection.
Regarding Claim 17
This application 19/084,500
Patent US 12,294,482
17. The system of claim 11, wherein using the domain knowledge to predict activities includes identifying a repeating pattern.
13. The system of claim 9, wherein using the domain knowledge to predict the set of activities includes identifying a repeating pattern.
Regarding Claim 18
This application 19/084,500
Patent US 12,294,482
18. The system of claim 11, wherein using the domain knowledge to predict activities includes utilizing tags or labels injected into activity fields of the IoT application events.
14. The system of claim 9, wherein using the domain knowledge to predict the set of activities includes utilizing tags or labels injected into activity fields of the IoT application events.
Regarding Claim 19
This application 19/084,500
Patent US 12,294,482
19. The system of claim 11, wherein an IoT application event of the IoT application events comprises a raw event.
15. The system of claim 9, wherein an IoT application event of the IoT application events comprises a raw event.
Regarding Claim 20
This application 19/084,500
Patent US 12,294,482
20. The system of claim 11, wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events.
16. The system of claim 9, wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events.
Regarding Claim 21
This application 19/084,500
Patent US 12,294,482
21. The method of claim 1, wherein the detected set of IoT application events serve as a signature of the IoT application.
17. The method of claim 1, wherein the detected set of IoT application events serve as a signature of the IoT application.
Regarding Claim 22
This application 19/084,500
Patent US 12,294,482
22. The system of claim 11, wherein the detected set of IoT application events serve as a signature of the IoT application.
18. The system of claim 9, wherein the detected set of IoT application events serve as a signature of the IoT application.
For claim 5 of the instant application, corresponding Patent US 12,294,482 does not teach: characterizing the application-specific activities as a streaming activity performed at least in part with an IoT device or a management activity performed at least in part with the IoT device.
However, Cheng et al. (Pub. No. US 2016/0301707), hereinafter Cheng, discloses characterizing the application-specific activities as a streaming activity performed at least in part with an IoT device or a management activity performed at least in part with the IoT device (See Parag. [0046]; An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events (management activity performed at least in part with the IoT device) ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify corresponding Patent US 12,294,482 to incorporate the teaching of Cheng. This would be convenient for managing IoT devices to prevent attacks against IoT devices (Cheng, Parag. [0003]).
For claim 6 of the instant application, corresponding Patent US 12,294,482 does not teach: using the activity parameters to learn behavior of the IoT application.
However, Cheng et al. (Pub. No. US 2016/0301707), hereinafter Cheng, discloses using the activity parameters to learn behavior of the IoT application (See Parag. [0139]; An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the historical records. Depending upon implementation-specific or other considerations, the IoT devices can be clustered before they are profiled into device profiles. Further depending upon implementation-specific or other considerations, determined vulnerabilities of IoT devices can be included in device profiles of the IoT devices. In generating device profiles of the IoT devices, baseline behavior of the IoT device can be determined from the historical records and included as part of the device profiles. See also Parag. [0041] [0046] [0140] and Fig. 13).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify corresponding Patent US 12,294,482 to incorporate the teaching of Cheng. This would be convenient for managing IoT devices to prevent attacks against IoT devices (Cheng, Parag. [0003]).
Claim 15 is taught by Cheng as described for claim 5.
Claim 16 is taught by Cheng as described for claim 6.
Claim Rejections - 35 USC § 112
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 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.
Claim 11 recites the phrase “the IoT application events falls outside the engine” in "generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the engine configured to ..." It’s unclear what the claimed determined the at least one of the IoT application events “falls outside the engine” means. In addition, it’s unclear what “the engine” is referring to.
Claims 12-20 and 22 are rejected under 35 U.S.C. 112(b) as they depend on the rejected claim 11.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 11 recite in part process steps which, under the broadest reasonable interpretation, are a series of mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of pencil and paper. If a claim, under its broadest reasonable interpretation, covers a mental process or a mathematical concept but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. The claim recites in part:
receiving a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application {data gathering}. The “receiving” is reasonably interpreted by the Examiner as gathering/collecting data. The claim does not provide any details on how the data is received or any details on the gathered data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “receiving” encompasses gathering data.
identifying, from a predetermined set of different types of activities, one or more application-specific activities using the IoT application events. The “identifying” is reasonably interpreted by the Examiner as making a judgment based on the gathered data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “identifying” encompasses observing the gathered information and making a judgement.
generating activity parameters at least in part by performing automated payload learning of the IoT application. The “generating” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “generating” encompasses observing and making a judgement. Additionally, it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
predicting a set of activities of the IoT application in accordance with the activity parameters at least in part by using domain knowledge. The “predicting” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “predicting” encompasses observing and making a judgement. Additionally, it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
determining whether at least one of the IoT application events falls outside the predicted activities. The “determining” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “determining” encompasses observing and making a judgement.
generating an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted activities {reporting} (Human activity).
Therefore, claims 1 and 11 recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claims only recite one additional element - when executed by a processor to receiving a detected set of Internet of Things (IoT) application events, identifying one or more application-specific activities using the IoT application events, generating activity parameters, predicting a set of activities of the IoT application, determining whether at least one of the IoT application events falls outside the predicted activities, and generating an alert. The processor is recited at a high-level of generality (i.e., as a generic computer to receiving a detected set of Internet of Things (IoT) application events, identifying one or more application-specific activities using the IoT application events, generating activity parameters, predicting a set of activities of the IoT application, determining whether at least one of the IoT application events falls outside the predicted activities, and generating an alert), such that it amounts no more than mere instructions to apply the exception using a generic computer component. As described in MPEP 2106.0S(g), limitations that amount to merely adding insignificant extra-solution activity to a judicial exception cannot integrate a judicial exception into a practical application. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claims 1 and 11 are directed to a judicial exception.
Claims 1 and 11 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements of the processor to receiving a detected set of Internet of Things (IoT) application events, identifying one or more application-specific activities using the IoT application events, generating activity parameters, predicting a set of activities of the IoT application, determining whether at least one of the IoT application events falls outside the predicted activities, and generating an alert to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Claims 1 and 11 are not patent eligible.
Claim 2 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 2 depends on claim 1, and it further recites “wherein the IoT application events are detected via passive monitoring.” The claim further limiting detecting the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 2 is not patent eligible.
Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 3 depends on claim 1, and it further recites “wherein the IoT application events are detected using deep packet inspection (DPI).” The claim further limiting the detecting the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 3 is not patent eligible. Additionally, it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 4 depends on claim 1, and it further recites “wherein the IoT application events are detected using subscription-based inspection.” The claim further limiting detecting the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 4 is not patent eligible.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 5 depends on claim 1, and it further recites “characterizing the application-specific activities as a streaming activity performed at least in part with an IoT device or a management activity performed at least in part with the IoT device.” The “characterizing” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “characterizing” encompasses observing and making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 5 is not patent eligible.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 6 depends on claim 1, and it further recites “using the activity parameters to learn behavior of the IoT application.” The “learn” is reasonably interpreted by the Examiner as making a judgment using activity parameters. Under its broadest reasonable interpretation when read in light of the specification, the claimed “learn” encompasses observing and making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 6 is not patent eligible.
Claim 7 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 7 depends on claim 1, and it further recites “wherein using the domain knowledge to predict activities includes identifying a repeating pattern.” The “predict” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “predict” encompasses observing and making a judgement. Therefore, claim 7 is not patent eligible. Additionally, it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 8 depends on claim 1, and it further recites “wherein using the domain knowledge to predict activities includes utilizing tags or labels injected into activity fields of the IoT application events.” The “predict” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “predict” encompasses observing and making a judgement. Therefore, claim 8 is not patent eligible. Additionally, it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 9 depends on claim 1, and it further recites “wherein an IoT application event of the IoT application events comprises a raw event.” The claim further limiting an IoT application event of the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 9 is not patent eligible.
Claim 10 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 10 depends on claim 1, and it further recites “wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events.” The claim further limiting the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 10 is not patent eligible.
Claim 12 is rejected under 35 U.S.C. 101 as described for claim 2.
Claim 13 is rejected under 35 U.S.C. 101 as described for claim 3.
Claim 14 is rejected under 35 U.S.C. 101 as described for claim 4.
Claim 15 is rejected under 35 U.S.C. 101 as described for claim 5.
Claim 16 is rejected under 35 U.S.C. 101 as described for claim 6.
Claim 17 is rejected under 35 U.S.C. 101 as described for claim 7.
Claim 18 is rejected under 35 U.S.C. 101 as described for claim 8.
Claim 19 is rejected under 35 U.S.C. 101 as described for claim 9.
Claim 20 is rejected under 35 U.S.C. 101 as described for claim 10.
Claim 21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 21 depends on claim 1, and it further recites “wherein the detected set of IoT application events serve as a signature of the IoT application.” The claim further limiting the IoT application events, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 21 is not patent eligible.
Claim 22 is rejected under 35 U.S.C. 101 as described for claim 21.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 5-13, and 15-22 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Cheng et al. (Pub. No. US 2016/0301707), hereinafter Cheng.
Claim 1. Cheng discloses [a] method comprising:
receiving a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application (See Parag. [0046]; the packet analysis based IoT device management system 106 functions to maintain event logs for IoT devices. An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ...);
identifying, from a predetermined set of different types of activities, one or more application-specific activities using the IoT application events (See Parag. [0046]; An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ... See Parag. [0136-0137]; data packets transmitted to and from IoT devices are obtained ... the data packets are sniffed to identify transaction data ... See also Fig. 13);
generating activity parameters at least in part by performing automated payload learning of the IoT application (See Parag. [0137-0139]; deep packet inspection can be used to identify transaction data from payloads of the data packets. Further depending upon implementation-specific or other considerations, specific data packets to perform deep packet inspection on can be selected based on at least one of a source of data packets, a destination of data packets, a data packet type of data packets, and data within data packets. For example, all data packets from a particular source can have deep packet inspection performed on them ... historical records of the IoT devices can be created/updated ... device profiles of the IoT devices are created/updated based on the historical records ... See Parag. [0041]; the packet analysis based IoT device management system 106 profiles IoT devices for use in managing or facilitating management of the devices. A profile, as used in this paper, includes operational parameters of IoT devices ... See also Fig. 13);
predicting a set of activities of the IoT application in accordance with the activity parameters at least in part by using domain knowledge (See Parag. [0139]; An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the historical records. Depending upon implementation-specific or other considerations, the IoT devices can be clustered before they are profiled into device profiles. Further depending upon implementation-specific or other considerations, determined vulnerabilities of IoT devices can be included in device profiles of the IoT devices. In generating device profiles of the IoT devices, baseline behavior of the IoT device can be determined from the historical records and included as part of the device profiles. See also Parag. [0041] [0060] [0140] and Fig. 13);
determining whether at least one of the IoT application events falls outside the predicted activities (See Parag. [0140-0141]; abnormal behavior at the IoT devices is detected using the historical records and the device profiles of the IoT devices. An applicable engine for detecting abnormal behavior, such as the anomaly detection engines described in this paper, can detect abnormal behavior at the IoT devices using the historical records and the device profiles of the IoT devices. For example, current operating of the IoT devices, indicated by the historical record which can be continuously updated in real-time, can be compared to baseline behavior of the IoT devices, indicated by the device profiles of the IoT devices, to determine if the IoT devices are exhibiting abnormal behavior ... the device profiles of the IoT devices are updated to indicate the abnormal behavior if it is detected at the IoT devices ... See Parag. [0108]; An anomaly is when an IoT device behaves differently from a modeled baseline behavior of an IoT device ... See also Fig. 13); and
generating an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted activities (See Parag. [0111]; the anomaly detection engine 612 can instruct an applicable engine for controlling data flow at an IoT device, such as the data flow management engines described in this paper, to regulate or stop flow of data to and from an IoT device in response to a detected anomaly at an IoT device).
Claim 2. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein the IoT application events are detected via passive monitoring (See Parag. [0006]; an event log is generated for the IoT device from the transaction data, the event log, at least in part, used to generate a historical record for the IoT device ... Examiner’s interpretation: Analyzing historical data is a form of passive monitoring).
Claim 3. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein the IoT application events are detected using deep packet inspection (DPI) (See Parag. [0046]; the packet analysis based IoT device management system 106 can maintain an event log using deep packet inspection).
Claim 5. Cheng discloses [t]he method of claim 1,
Cheng discloses the method further comprising characterizing the application-specific activities as a streaming activity performed at least in part with an IoT device or a management activity performed at least in part with the IoT device (See Parag. [0046]; An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events (management activity performed at least in part with the IoT device) ...).
Claim 6. Cheng discloses [t]he method of claim 1,
Cheng discloses the method further comprising using the activity parameters to learn behavior of the IoT application (See Parag. [0139]; An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the historical records. Depending upon implementation-specific or other considerations, the IoT devices can be clustered before they are profiled into device profiles. Further depending upon implementation-specific or other considerations, determined vulnerabilities of IoT devices can be included in device profiles of the IoT devices. In generating device profiles of the IoT devices, baseline behavior of the IoT device can be determined from the historical records and included as part of the device profiles. See also Parag. [0041] [0046] [0140] and Fig. 13).
Claim 7. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein using the domain knowledge to predict activities includes identifying a repeating pattern (See Parag. [0060]; the access log management engine 208 can compare events determined from transaction data identified through deep packet inspection with a pattern of events, indicated by an event log, to determine how a user is interacting with an IoT device and subsequently update an access log to indicate how the user is interacting with the IoT device. In another example, the access log management engine 208 can compare events determined from transaction data identified through deep packet inspection with a pattern of events associated with different users, indicated by an event log, to determine an identification of a user interacting with an IoT device. See also Parag. [0046] [0094]).
Claim 8. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein using the domain knowledge to predict activities includes utilizing tags or labels injected into activity fields of the IoT application events (See Parag. [0139]; device profiles of the IoT devices are created/updated based on the historical records. An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the historical records. Depending upon implementation-specific or other considerations, the IoT devices can be clustered before they are profiled into device profiles. Further depending upon implementation-specific or other considerations, determined vulnerabilities of IoT devices can be included in device profiles of the IoT devices. In generating device profiles of the IoT devices, baseline behavior of the IoT device can be determined from the historical records and included as part of the device profiles. See also Parag. [0041] [0140] and Fig. 13).
Claim 9. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein an IoT application event of the IoT application events comprises a raw event (See Parag. [0046]; Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events. For example, an event log can include a pattern of events corresponding to a specific way in which an IoT device is being interacted with or otherwise functioning. See also Parag. 13).
Claim 10. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein the IoT application events comprise one or more of network sessions, portions of network sessions, message transport events, and message log events (See Parag. [0046]; the packet analysis based IoT device management system 106 functions to maintain event logs for IoT devices. An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ...).
Claim 11. Cheng discloses [a] system comprising:
a processor (See Parag. [0029]) configured to:
receive a detected set of Internet of Things (IoT) application events, wherein the IoT application events are associated with activities of an IoT application (See Parag. [0046]; the packet analysis based IoT device management system 106 functions to maintain event logs for IoT devices. An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ...);
identify, from a predetermined set of different set of different types of activities, one or more application-specific activities using the IoT application events (See Parag. [0046]; An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ... See Parag. [0136-0137]; data packets transmitted to and from IoT devices are obtained ... the data packets are sniffed to identify transaction data ... See also Fig. 13);
predict a set of activities of the IoT application in accordance with activity parameters at least in part by using domain knowledge (See Parag. [0139]; An applicable engine for profiling the IoT devices, such as the IoT device profiling engines described in this paper, can function to create/update device profiles of the IoT devices based on the historical records. Depending upon implementation-specific or other considerations, the IoT devices can be clustered before they are profiled into device profiles. Further depending upon implementation-specific or other considerations, determined vulnerabilities of IoT devices can be included in device profiles of the IoT devices. In generating device profiles of the IoT devices, baseline behavior of the IoT device can be determined from the historical records and included as part of the device profiles. See also Parag. [0041] [0140] and Fig. 13);
a payload learning engine configured to perform automated payload learning of the IoT application to generate the activity parameters (See Parag. [0137-0139]; deep packet inspection can be used to identify transaction data from payloads of the data packets. Further depending upon implementation-specific or other considerations, specific data packets to perform deep packet inspection on can be selected based on at least one of a source of data packets, a destination of data packets, a data packet type of data packets, and data within data packets. For example, all data packets from a particular source can have deep packet inspection performed on them ... historical records of the IoT devices can be created/updated ... device profiles of the IoT devices are created/updated based on the historical records ... See Parag. [0041]; the packet analysis based IoT device management system 106 profiles IoT devices for use in managing or facilitating management of the devices. A profile, as used in this paper, includes operational parameters of IoT devices ... See also Fig. 13);
an IoT application reporting engine configured to:
determine whether at least one of the IoT application events falls outside the predicted activities (See Parag. [0140-0141]; abnormal behavior at the IoT devices is detected using the historical records and the device profiles of the IoT devices. An applicable engine for detecting abnormal behavior, such as the anomaly detection engines described in this paper, can detect abnormal behavior at the IoT devices using the historical records and the device profiles of the IoT devices. For example, current operating of the IoT devices, indicated by the historical record which can be continuously updated in real-time, can be compared to baseline behavior of the IoT devices, indicated by the device profiles of the IoT devices, to determine if the IoT devices are exhibiting abnormal behavior ... the device profiles of the IoT devices are updated to indicate the abnormal behavior if it is detected at the IoT devices ... See Parag. [0108]; An anomaly is when an IoT device behaves differently from a modeled baseline behavior of an IoT device ... See also Fig. 13);
generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the engine configured to:
determine whether at least one of the IoT application events falls outside the predicted activities; generate an alert associated with the at least one of the IoT application events when it is determined the at least one of the IoT application events falls outside the predicted activities (See Parag. [0111]; the anomaly detection engine 612 can instruct an applicable engine for controlling data flow at an IoT device, such as the data flow management engines described in this paper, to regulate or stop flow of data to and from an IoT device in response to a detected anomaly at an IoT device); and
a memory coupled to the processor and configured to provide the processor with instructions (See Parag. [0029]).
Claim 12 is taught by Cheng as described for claim 2.
Claim 13 is taught by Cheng as described for claim 3.
Claim 15 is taught by Cheng as described for claim 5.
Claim 16 is taught by Cheng as described for claim 6.
Claim 17 is taught by Cheng as described for claim 7.
Claim 18 is taught by Cheng as described for claim 8.
Claim 19 is taught by Cheng as described for claim 9.
Claim 20 is taught by Cheng as described for claim 10.
Claim 21. Cheng discloses [t]he method of claim 1,
Cheng further discloses wherein the detected set of IoT application events serve as a signature of the IoT application (See Parag. [0046]; the packet analysis based IoT device management system 106 functions to maintain event logs for IoT devices. An event log includes events associated with IoT devices. Events can include applicable parameters related to operation of an IoT device, such as what data is sent to and from the IoT device, destinations and origins of data sent to and from the IoT device, identifications of the IoT device, geographic information relating to the IoT device, and interaction types corresponding to patterns of events ...).
Claim 22 is taught by Cheng as described for claim 21.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4 and 14 is rejected under 35 U.S.C. 103 as being unpatentable over Cheng et al. (Pub. No. US 2016/0301707), hereinafter Cheng; in view of Livanos et al. (Pub. No. US 2019/0166016), hereinafter Livanos.
Claim 4. Cheng discloses [t]he method of claim 1,
Cheng doesn’t explicitly disclose wherein the IoT application events are detected using subscription-based inspection.
However, Livanos wherein the IoT application events are detected using subscription-based inspection (See Parag. [0018]; an event subscription request from an application server (AS) may be received at a network exposure function (NEF) entity. The event subscription request may include a list of one or more subscribed events for a UE, which may include a UE attach event and/or a UE detach event. Other events may be available for subscription, such as a delayed data delivery event. For the event subscription, a context which indicates the one or more subscribed events may be created. See Parag. [0021]; UEs may be Internet of Things (IoT) devices).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the detection of IoT application events, taught by Cheng, to include using subscription-based inspection, as taught by Livanos. This would be convenient for reducing data buffering in mobile networks for data to be delivered to user equipment (UE), and more particularly to subscription-based event notification techniques for reducing such data buffering in the mobile networks (Livanos, Parag. [0001]).
Claim 14 is taught by Cheng in view of Livanos as described for claim 4.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Lim (Pub. No. US 2013/0086261) – Related art in the area of a policy language system for managing information, (Abstract; Activity data is analyzed or evaluated to detect behavioral patterns and anomalies. When a particular pattern or anomaly is detected, a system may send a notification or perform a particular task. This activity data may be collected in an information management system, which may be policy based. Notification may be by way e-mail, report, pop-up message, or system message. Some tasks to perform upon detection may include implementing a policy in the information management system, disallowing a user from connecting to the system, and restricting a user from being allowed to perform certain actions. To detect a pattern, activity data may be compared to a previously defined or generated activity profile).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights