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 .
Detailed Action
Claims 1-19 have been submitted for examination.
Claim 20 has been newly added.
Claims 1-20 have been rejected.
Double Patenting
The non-statutory 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 non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); 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 non-statutory double patenting ground provided the conflicting 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.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-20 are provisionally rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1-19 of co pending Application No. 18/779.911 in view of Dolisy (8,601,113).
All teachings of the claims are identical, with the only difference being the instant application specifying that the data flow is data log and the merged record is a merged data record.
Dolisy explicitly teaches that the data flow is data log and the merged record is a merged data record (entire document).
It would have been obvious to one of ordinary skill in the art at the time of invention to combine the data log and the merged data record with the data flow and merged record of Dolisy.
One of ordinary skill in the art would have been motivated to make the combination because Dolisy discloses “ A flow record is defined as a small unit of measure of unidirectional network usage by a stream of IP packets that share common source and destination parameters during a time interval”. In other words it is a data log.
This is a provisional obviousness-type double patenting rejection.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 102(a)1 as being anticipated by Kishikawa United States Patent Application 2022/ 0337494 hereinafter 494.
In regard to claims 1 10 11
discloses
(Currently amended) A method for generating and storing an aggregated data log comprising: accessing a plurality of data log records in a data log repository; detecting a plurality of data log records in the data log repository, wherein each data log record includes a plurality of data fields; detecting a first data log record of the plurality of data log records having a first data field value in common with a second data log record; detecting in the first data log record a second data field having a second value;
PNG
media_image1.png
177
285
media_image1.png
Greyscale
(Step 301 compares the field contents)
detecting in the second data log record the second data field having a third value;
Examiner states that once the flows in the context of S301 above are not identical it means that a difference is present.
generating a merged data record based on including: the first data field value, the second value and the third value; The first column of Figure 5 is the merged data version
PNG
media_image2.png
130
246
media_image2.png
Greyscale
generating an aggregated data log based on the merged data record, wherein the aggregated data log includes a plurality of merged data records; and storing the aggregated data log in an aggregated data log repository. Figure 10
PNG
media_image3.png
656
946
media_image3.png
Greyscale
Consideration for the mapping:
PNG
media_image4.png
458
920
media_image4.png
Greyscale
Examiner considers for the purpose of claim language mapping the log record as being collection point source IP address Destination IP address Source port Destination port Transport protocol Number of messages. All of Figure 5 is the data log repository. The data field is where 300a 300d is at, and the same is for 192.168.1.1 192.168.1.2. This mapping is for explication only and not limitation or any interpretation.
In regard to claims 2 12
494 discloses
(Original) The method of claim 1, further comprising: matching a data record value of the first data log record to a corresponding data record value of another data log record to detect a common data field value.
PNG
media_image5.png
88
770
media_image5.png
Greyscale
Both collection point 300a and 300d have the same Source IP
In regard to claims 3 13
494 discloses
3. (Original) The method of claim 1, further comprising: generating a merged data record in response to detecting at least one common data record value between a plurality of data log records from the data log repository.
PNG
media_image5.png
88
770
media_image5.png
Greyscale
Both collection point 300a and 300d have been merged
In regard to claims 4 14
494 discloses
4. (Original) The method of claim 1, further comprising: generating an aggregated data log that includes common data record values from the merged data records.
PNG
media_image6.png
189
790
media_image6.png
Greyscale
In regard to claims 5 15
494 discloses
5. (Original) The method of claim 1, wherein the first data field includes any one of: an account identifier, a host header, a date, an authorization string, and any combination thereof.
PNG
media_image7.png
344
814
media_image7.png
Greyscale
In regard to claims 6 16
494 discloses
6. (Original) The method of claim 1, further comprising: detecting a data log record that is based on any one of: a data record, an event, a message, a request, an action in a virtual private cloud environment, and any combination thereof. (Paragraph 94)
In regard to claims 7 17
494 discloses
7. (Original) The method of claim 1, further comprising: generating the aggregated data log based on a plurality of merged data records, wherein a first merged data record is generated from a first data log and a second merged data record is generated from a second data log. (Paragraph 159)
In regard to claims 8 18
494 discloses
8. (Original) The method of claim 1, further comprising: determining that a first data field value is common in response to detecting at least a partial match between a value of the first data log record and a value of the second data log record. (Paragraph 171-172)
In regard to claims 9 19
494 discloses
9. (Original) The method of claim 1, further comprising: filtering out a portion of records of the plurality of data records based on a value of a data field; and generating the aggregated data log based on the merged data record without the filtered portion of records.
PNG
media_image8.png
613
974
media_image8.png
Greyscale
Number of previous messages is filtered to 100 30 500
In regard to claim 20
494 discloses
The method of claim 1, wherein the second value is different from the third value, (Figure 9) and the data log repository includes data log records from a single data source (Figure 4; Ethernet Switch).
Response to Applicant Argument and remarks
Applicants’ argument and remarks have been fully considered and are not persuasive.
In regard the main argument which states; “
PNG
media_image9.png
521
859
media_image9.png
Greyscale
”
Examiner respectfully disagrees.
Kishikawa hereinafter Ki never defined aggregation as loss of data in favor of decreased granularity.
Applicants explains Ki aggregation using the help.tableau.com is irrelevant because the Ki reference never referred to help.tableau.com to explain what is the Ki aggregation, instead it precisely goes after how the aggregation works in Figure 9.
PNG
media_image10.png
655
597
media_image10.png
Greyscale
Examiner will explain Figure 9 with an example following the Logic of the steps S301 S302 S303.
For the explication there is at least 2 collections point A and B
Collection point A Collection point B
1 1
2 2
3 4
4 4
According to the logic 1 and 1 are the same, and aggregate is 1.
According to the logic 2 and 2 are the same, and aggregate is 1 2.
According to the logic 3 and 4 are different, and aggregate is 1 2.
According to the logic 4 and 4 are the same, and aggregate is 1 2 4.
It is clear from this explication that 2 and 4 are different values, whereas the merged data is 1 2 4.
It is also clear following the logic of Figure 9 the second value and the third value have to be different for the aggregation to happen. Thus, the claim language and the limitations are met clearly, and the argument advanced is not correct. 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 extension fee 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.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMINE RIAD whose telephone number is (571)272-8185.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bonzo Bryce can be reached 571-272-3655. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Amine Riad/
Primary Examiner