DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 07/17/2024. Claims 1-4 and 6-21 are pending in this application.
Examiner Note
If applicant has any questions or wishes to amend claims, applicant is encouraged to contact the examiner to ensure that any proposed amendments would overcome current rejection(s). The examiner can normally be reached at (408) 918-7596 or Zonghua.Du@uspto.gov, Monday-Friday, 8 AM - 5 PM PST, and examiner is happy assist applicant as needed to provide any help/feedback, thank you.
Priority
This application claims priority of PCT/JP2022002963, filed 01/26/2022. The assignee of record is Nippon Telegraph and Telephone Corp. The listed inventor(s) is/are: Inoue et al.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 07/17/2024 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
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.
Claim limitations in this application that use the word “means” (or “step”) 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 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: “a reception unit configured to receive” and “a collation unit configured to collate” in claim 1, “a display control unit configured to display” in claim 3, “a separating unit configured to separate” in claim 11, “a removal unit configured to remove” in claim 12, “a conversion unit configured to convert” in claim 13. The instant specification discloses that “Furthermore, all or any part of each processing function performed in each device can be realized by a central processing unit (CPU) and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic. Note that the program may be executed not only by a CPU but also by another processor such as a GPU (¶ 0121)” and “FIG. 9 is a diagram illustrating an example of a computer that executes the analysis program. A computer 1000 includes a memory 1010 and a CPU 1020, for example. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected to each other by a bus 1080 (¶ 0125).”
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.
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 Objections
Claims 1, 4, 6 and 8-9 is/are objected to because of the following informalities:
Claims 1, 4 and 8 the limitation “VPN” in line 6, line 6 and line 8 respectively with an acronym without properly defined when it is first introduced. For examination purpose, “VPN” will read as “Virtual Private Network (VPN).”
Claims 6 and 9 recite “the information regarding the outer header included in the xFlow packet and the information indicating that the user of the VPN is unknown in association with each other” in line 4 respectively. It appears to the examiner that the phrase lacks an action word. For examination purpose, “the information regarding the outer header included in the xFlow packet and the information indicating that the user of the VPN is unknown in association with each other” will read as “storing the information regarding the outer header included in the xFlow packet and the information indicating that the user of the VPN is unknown in association with each other.”
Appropriate correction is required.
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 1-4 and 6-21 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 pre-AIA the applicant regards as the invention.
Claim 1 recites the limitation “an xFlow packet” in line 7. It is unclear to the examiner if the limitation refers to the limitation “an xFlow packet” recited in line 2. For examination purpose, “an xFlow packet” recited in line 7 will read as “the xFlow packet.”
Claim 1 recites the limitation “an outer header” in line 6. It is unclear to the examiner if the limitation refers to the limitation “an outer header” recited in line 3. For examination purpose, “an outer header” recited in line 6 will read as “the outer header.”
Claim 4 recites the limitation “an xFlow packet” in line 7. It is unclear to the examiner if the limitation refers to the limitation “an xFlow packet” recited in line 2. For examination purpose, “an xFlow packet” recited in line 7 will read as “the xFlow packet.”
Claim 4 recites the limitation “an outer header” in line 6. It is unclear to the examiner if the limitation refers to the limitation “an outer header” recited in line 3. For examination purpose, “an outer header” recited in line 6 will read as “the outer header.”
Claim 8 recites the limitation “an xFlow packet” in line 8. It is unclear to the examiner if the limitation refers to the limitation “an xFlow packet” recited in line 4. For examination purpose, “an xFlow packet” recited in line 8 will read as “the xFlow packet.”
Claim 8 recites the limitation “an outer header” in line 8. It is unclear to the examiner if the limitation refers to the limitation “an outer header” recited in line 5. For examination purpose, “an outer header” recited in line 8 will read as “the outer header.”
Claims 11, 14 and 17 recite the limitation “the sampled encapsulation packes” in line 3 respectively. There is insufficient antecedent basis for this limitation in the claims. For examination purpose, “the sampled encapsulation packes” will read as “the sampled encapsulation packet.”
The dependent claims of the above rejected claims are rejected due to their dependencies.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-4, 7-8, 10 and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurakami et al. (US 20190230198 A1, published 07/25/2019; hereinafter Kurakami), in view of Hurren et al. (US 6788681 B1, published 09/07/2004; hereinafter Hurren), and in further view of Kakemizu et al. (US 7068640 B2, published 06/27/2006; hereinafter Kakemizu).
For Claim 1, Kurakami teaches an analysis device (Kurakami exemplifies a flow information analysis apparatus in FIG. 1) comprising:
a reception unit (Kurakami exemplifies a receiving unit in the flow information analysis apparatus in FIG. 2 and ¶ 0030) configured to receive an xFlow packet (Kurakami exemplifies flow information 80 (such as sFlow, IPFIX, or Flexible NetFlow) created based on sampled tunnel packets in FIG. 1 and ¶ 0023) generated based on a sampled encapsulation packet (Kurakami, FIG. 1, FIG. 2; ¶ 0020 “… a tunnel packet indicates a packet that is encapsulated based on a tunneling protocol. Further, a user packet indicates a packet that is sent from the user terminal and that is not yet encapsulated, or a packet that is obtained by decapsulating a tunnel packet, i.e., by removing a tunnel header from the tunnel packet …”; ¶ 0021 “… The user terminal 20 transmits an IP packet 70 that is a user packet. Then, the in-house network device 30 encapsulates the IP packet 70 sent from the user terminal 20 by adding a tunnel header using a tunneling protocol, such as PPPoE …”; ¶ 0023 “… The network device 50 transmits and receives encapsulated packets between the network device 40 and the network device 60. Further, the network device 50 takes a sample of the transmitted and received tunnel packet 72, and creates flow information 80, such as sFlow, IPFIX, or Flexible NetFlow. Then, the network device 50 transmits the created flow information 80 to the flow information analysis apparatus 10. The flow information analysis apparatus 10 receives and analyzes the flow information 80 that is transmitted by the network device 50 …”; ¶ 0030 “… The receiving unit 11 receives the flow information 80 that contains a header sample that is a part of the IP packet to which the tunnel header is added …”),
the xFlow packet including information regarding an outer header of the encapsulation packet and statistical information of a flow including the encapsulation packet (Kurakami, FIG. 3; ¶ 0030 “… As illustrated in FIG. 3, the flow information 80 contains an Ether header, an IP header, a UDP header, and a sFLow datagram …”; ¶ 0031 “… As illustrated in FIG. 3, an sFLow datagram 80a contains an sFlow header, a counter sample, a header sample, and a flow sample. The counter sample is, for example, the number of bytes or the number of packets of sampled packets. Further, the header sample is, for example, top 128 bytes of a sampled packet. Furthermore, the flow sample is, for example, extended information, such as creation source AS information or a URL, on a sampled packet …”; ¶ 0032 “… Moreover, as illustrated in FIG. 3, a header sample 80b contains an Ether header, an IP header, a UDP header, an L2TP header, a PPP header, and a payload of a tunnel packet. Here, when the header sample 80b corresponds to top 128 bytes of a sampled packet … a payload 80c of the tunnel packet contains an IP header, a TCP header, and a part of a payload of an internal user packet …”); and …
Kurakami does not explicitly teach, but Hurren teaches using information regarding an outer header (Hurren discloses an VPN identifier carried in an outer encapsulation header) to identify the VPN context of encapsulated packets (Hurren disclose encapsulating VPN packets with an VPN identifier carried in an outer encapsulation header, which is read and processed by network elements to identify the VPN context of the packet; col. 3, ll. 5-37 “… wherein the determining comprises: determining an identifier uniquely identifying a virtual private network (VPN) comprising at least the first and second LANs; accessing a routing table stored at the first network interface; where possible, retrieving, from the routing table a unique address of the second network interface responsive to a destination address stored in the received LAN data frames and the determined identifier, the unique address comprising an EP address; and if the routing table does not contain the unique address for the destination information, retrieving a multicast address, the multicast address representative of all LANs forming part of the VPN and comprises an IP multicast address; and wherein the encapsulating comprises encapsulating the conventional LAN data frames with the determined identifier and one of the unique address of the second network interface and the multicast address …”).
Kakemizu further teaches establishing VPN tunnels per authenticated user, wherein tunnel identifiers and outer header information are mapped to VPN user identity information maintained by authentication and authorization systems, and the traffic associated with a given tunnel can be attributed to a user of a VPN (Kakemizu, FIG. 14, FIG. 15; col. 4, ll. 40-61 “… The authentication server (AAAH) of the present invention has a VPN database for storing the service quality desired by the user, the security information between the security gateways, and a correspondence table between the VPN information by a user unit consisting of the IP addresses of the communication destination hosts (CN) for setting a VPN and the security gateway (VPNGW) for accommodating the communication destination host, an AAAVPN control section for specifying a VPN setting path based on a security gateway (FA) address of the access network 2 to which the mobile terminal set in the authentication request message has been connected, a security gateway address (HA) of the home network 3 of the mobile terminal, and a security gateway (PCN: Proxy CN) address for accommodating the communication destination host (CN) set in the user correspondence VPN information and the communication destination host extracted from the correspondence table, and an AAA protocol processing section for setting the service quality and the security information between the security gateways as a service profile, to the authentication response message to the access network and the position-registration message to the home network …”; col. 10, l. 60 – col. 11, l. 16 “… FIG. 15 shows an example of the IP Sec. information table 333. The IP Sec. information table consists of IP Sec. information, ESP information, and tunnel information. The IP Sec. information is a collection of IP Sec. information instances, and is specified by a set of a transmission originating address and a destination address. Each IP Sec. information instance consists of a transmission originating address/net mask, a destination address/net mask, an actual destination address as an actual transfer destination of a packet, a tunnel information identifier to be applied to this packet, and an ESP information identifier to be applied to this packet. The ESP information is a collection of ESP information instances. This ESP information consists of an ESP identifier for uniquely identifying ESP information … The tunnel information is a collection of tunnel information instances. The tunnel information consists of a tunnel identifier for uniquely identifying tunnel information, an encapsulation method, a direction, and a transmission originating address and a destination address that become an entrance and an exit of a tunnel …”).
As discussed above, Kurakami teaches that xFlow/flow information packet includes outer header information derived from the sampled encapsulated packets. Therefore, before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to collate outer header information included in an xFlow packet with stored mappings between the VPN identifier in outer header and the VPN user, as taught in Hurren in view of Kakemizu, in order to specify the VPN user from which the xFlow packet is transferred, because xFlow/NetFlow systems are expressly designed to export header information for correlation and analysis, and applying the VPN user mappings to the flow records yields a predictable result.
Further on, Kurakami, Hurren and Kakemizu are analogous art because they are related to VPN/tunneling systems.
For Claim 3, Kurakami-Hurren-Kakemizu teaches the analysis device according to claim 1, further comprising: a display control unit configured to display the statistical information included in the xFlow packet on a screen of a terminal device in a case where information regarding an outer header associated with information for identifying a user of a VPN and information regarding an outer header included in the xFlow packet received by the reception unit match as a result of the collating by the collation unit (Kurakami discloses displaying an analysis result including the statistical information based on the packet header information; FIG. 2; ¶ 0072 “… the aggregation unit 17 aggregates pieces of information recorded in the recording unit 16. The aggregation unit 17 may aggregate the number of packets in which a predetermined destination address is set, on the basis of information on the header of the internal user packet, for example. Moreover, the display unit 18 displays an analysis result on a predetermined terminal or the like. The display unit 18 may display the information on the header of the internal packet recorded in the recording unit 16 without any change, or may display an aggregation result obtained by the aggregation unit 17 by using a table or a graph …”). See motivation to combine for claim 1.
For Claim 4, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above.
For Claim 7, the claim is substantially similar to claim 3 and therefore is rejected for the same reasoning set forth above.
For Claim 8, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Kurakami-Hurren-Kakemizu teaches a computer-readable non-transitory recording medium storing computer-executable program instructions that when executed by a processor cause a computer to execute an analysis method (Kurakami, Claim 6 “… A non-transitory computer-readable recording medium having stored a program for flow information analysis that causes a computer to execute a process …”).
For Claim 10, the claim is substantially similar to claim 3 and therefore is rejected for the same reasoning set forth above.
For Claim 20, Kurakami-Hurren-Kakemizu teaches the analysis method according to claim 8, further comprising: matching the information on the outer header associated with the information identifying a VPN user with the information on the outer header included in the xFlow packet received and transfer the xFlow packet (Kurakami teaches that xFlow/flow information packet includes outer header information derived from the sampled encapsulated packets and is compared to match the tunneling protocol templates (Kurakami, FIG. 1, FIG. 2, ¶ 0020 - ¶ 0032); Hurren in view of Kakemizu teaches stored mappings between the VPN identifier in outer header and the VPN user (Hurren, col. 3, ll. 5-37 and Kakemizu col. 4, ll. 40-61, col. 10, l. 60 – col. 11, l. 16); Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to compare and match outer header information included in an xFlow/flow information packet with stored mappings between the VPN identifier in outer header and the VPN user, because xFlow/NetFlow systems are expressly designed to export header information from correlation and analysis, and applying the VPN user mappings to the flow records yields a predictable result; Kurakami further teaches transfer the analyzed xFlow/flow information packet to a display unit (Kurakami, FIG. 2, ¶ 0072)). Also see recitation and motivation to combine for claim 1.
For Claim 21, Kurakami-Hurren-Kakemizu teaches the analysis device according to claim 1, wherein a matching unit extracts the outer header from the xFlow packet received by a receiving unit and containing the outer header and statistical information about the outer header (Kurakami; FIG. 2, FIG. 3; ¶ 0030 “… As illustrated in FIG. 3, the flow information 80 contains an Ether header, an IP header, a UDP header, and a sFLow datagram …”; ¶ 0031 “… As illustrated in FIG. 3, an sFLow datagram 80a contains an sFlow header, a counter sample, a header sample, and a flow sample. The counter sample is, for example, the number of bytes or the number of packets of sampled packets. Further, the header sample is, for example, top 128 bytes of a sampled packet. Furthermore, the flow sample is, for example, extended information, such as creation source AS information or a URL, on a sampled packet …”; ¶ 0033 “… the flow information 80 contains information on the header of the user packet. Therefore, if it is possible to identify the position of the header of the user packet in the flow information 80 and extract the header, it is possible to perform analysis by applying a known IP packet analysis method …”; ¶ 0035 “… The first analysis unit 12 identifies a user packet in the flow information 80, i.e., a position of a header of an IP packet, by using a template. The first analysis unit 12 determines whether the header sample 80b of the flow information 80 matches any of templates that are based on tunneling protocols, and when determining that the header sample matches any of the templates, extracts information on a header of the IP packet from the header sample 80b on the basis of the matched template …”).
Claim Rejections - 35 USC § 103
Claims 2, 6 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurakami et al. (US 20190230198 A1, published 07/25/2019; hereinafter Kurakami), in view of Hurren et al. (US 6788681 B1, published 09/07/2004; hereinafter Hurren), in view of Kakemizu et al. (US 7068640 B2, published 06/27/2006; hereinafter Kakemizu), and in further view of Hughes et al. (US 20080031240 A1, published 02/07/2008; hereinafter Hughes).
For Claim 2, Kurakami-Hurren-Kakemizu does not explicitly teach, but Hughes teaches the analysis device according to claim 1, wherein in a case where the information regarding the outer header with which the information for identifying the user of the VPN is associated and the information regarding the outer header included in the xFlow packet received by the reception unit do not match, the collation unit stores the information regarding the outer header included in the xFlow packet and the information indicating that the user of the VPN is unknown in association with each other in a storage unit (Hughes discloses storing packet data per flow and determining if incoming packet data matches stored flow data, if not matched, handling accordingly; ¶ 0008 “… The invention addresses the above problems by providing data matching by using flow based packet data storage. A system for processing packets includes a communications interface and a processor. The communications interface receives a packet between a source and a destination. The processor identifies a flow between the source and the destination based on the packet. The processor determines whether some of packet data of the packet matches to storage data in storage using hashes. If the packet data does not match the storage data, the processor then stores the packet data in a block of memory in the storage based on the flow. …”).
Hughes and Kurakami-Hurren-Kakemizu are analogous art because they are both related to processing flow data over communications networks.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the flow packet data matching techniques of Hughes with the system of Kurakami-Hurren-Kakemizu to match data in the communications networks to data in a flow (Hughes ¶ 0011).
For Claim 6, the claim is substantially similar to claim 2 and therefore is rejected for the same reasoning set forth above.
For Claim 9, the claim is substantially similar to claim 2 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 11-12, 14-15 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurakami et al. (US 20190230198 A1, published 07/25/2019; hereinafter Kurakami), in view of Hurren et al. (US 6788681 B1, published 09/07/2004; hereinafter Hurren), in view of Kakemizu et al. (US 7068640 B2, published 06/27/2006; hereinafter Kakemizu), and in further view of Lund et al. (US 20090316590 A1, published 12/24/2009; hereinafter Lund).
For Claim 11, Kurakami-Hurren-Kakemizu does not explicitly teach, but Lund teaches the analysis device according to claim 1, further comprising: a separating unit configured to separate the xFlow packet acquired by a conversion device into xFlow packets containing the outer header and inner headers of the sampled encapsulation packes and the xFlow packet containing statistical information (Lund discloses analyzing the sampled packets based on the selected characteristics, e.g. conceptually similar to separating different types of data (header information vs statistics) from the sampled packets; FIG. 6; ¶ 0007 “… The preferred embodiments can determine whether to sample a packet from network traffic based on content of the packet and add a field to the packet in response to the packet being sampled. The field includes information concerning the content of the packet. The added field can be based on a number of bytes in the packet, to identify the packet as being from a flow that has not been sampled, and/or to identify a type of sampling that was used to sample the packet. An analysis of the sampled packet can be achieved by summing the information from the field with corresponding fields of other packets that have been sampled …”; ¶ 0036 “… FIG. 6 is a flow chart showing a preferred embodiment of the analysis performed by the analysis unit. Once the analysis unit receives the sampled packet from the sampling unit, the analysis unit determines whether the packet contains information associated with selected characteristic, such as an IP address, a port number, a number bytes, a sampling type, IP protocol, and the like (step 600) … If the packet contains information associated with the selected characteristic (e.g., a destination address that matches the selected destination address) (step 600), the analysis unit can perform further analysis on the content of the packets (step 604) …”).
Lund and Kurakami-Hurren-Kakemizu are analogous art because they are both related to sampling network packets.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the network packets analyzing techniques of Lund with the system of Kurakami-Hurren-Kakemizu to “provide a sufficient number of packets of interest to perform an accurate analysis of the network traffic represented by the sampled packets” (Lund ¶ 0005).
For Claim 12, Kurakami-Hurren-Kakemizu-Lund teaches the analysis device according to claim 11, further comprising: a removal unit configured to remove the outer header from the xFlow packet containing the outer header and inner header of the sampled packet among the xFlow packet separated by the separation unit (Kurakami discloses extracting information on a header of an IP packet/inner header from the sampled flow information/xFlow packet, therefore removing the outer header from the sampled flow information/xFlow packet; FIG. 2, FIG. 3; ¶ 0033 “… the flow information 80 contains information on the header of the user packet. Therefore, if it is possible to identify the position of the header of the user packet in the flow information 80 and extract the header, it is possible to perform analysis by applying a known IP packet analysis method …”; ¶ 0035 “… The first analysis unit 12 identifies a user packet in the flow information 80, i.e., a position of a header of an IP packet, by using a template. The first analysis unit 12 determines whether the header sample 80b of the flow information 80 matches any of templates that are based on tunneling protocols, and when determining that the header sample matches any of the templates, extracts information on a header of the IP packet from the header sample 80b on the basis of the matched template …”).
For Claim 14, the claim is substantially similar to claim 11 and therefore is rejected for the same reasoning set forth above.
For Claim 15, the claim is substantially similar to claim 12 and therefore is rejected for the same reasoning set forth above.
For Claim 17, the claim is substantially similar to claim 11 and therefore is rejected for the same reasoning set forth above.
For Claim 18, the claim is substantially similar to claim 12 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 13, 16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurakami et al. (US 20190230198 A1, published 07/25/2019; hereinafter Kurakami), in view of Hurren et al. (US 6788681 B1, published 09/07/2004; hereinafter Hurren), in view of Kakemizu et al. (US 7068640 B2, published 06/27/2006; hereinafter Kakemizu), in view of Lund et al. (US 20090316590 A1, published 12/24/2009; hereinafter Lund), and in further view of Singh et al. (US 20130114612 A1, published 05/09/2013; hereinafter Singh).
For Claim 13, Kurakami-Hurren-Kakemizu-Lund does not explicitly teach, but Singh teaches the analysis device according to claim 11, further comprising: a conversion unit configured to convert the xFlow packet acquired by the conversion device into an xFlow packet in a format corresponding to the processing content of the output destination (Singh discloses that a network appliance formats the collected network flow information as a network flow record for exporting to a network flow data collector/output destination; ¶ 0009 “… A network appliance that is part of a distributed virtual switch collects network flow information for network flows passing through the network appliance. The network flow information is encapsulated into packets as a network flow record for transport. Network flow exporter type information is added to the network flow records to indicate that the packets are from a distributed exporter. A device identifier is exported to uniquely identify the network appliance. The packets are exported to a network flow data collector …”).
Singh and Kurakami-Hurren-Kakemizu-Lund are analogous art because they are both related to sampling network packets.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the formatting network flow record techniques of Singh with the system of Kurakami-Hurren-Kakemizu-Lund to facilitate the high availability, network efficiency, scalability of network flow monitoring (Singh ¶ 0039).
For Claim 16, the claim is substantially similar to claim 13 and therefore is rejected for the same reasoning set forth above.
For Claim 19, the claim is substantially similar to claim 13 and therefore is rejected for the same reasoning set forth above.
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. Tan et al. (US 9942200 B1) discloses that a user is provisioned for a Web service by supplying a user name and password. A digital certificate and VPN identifier are generated and downloaded to the user's computer. The VPN identifier and user identifier are stored into a database. The user accesses the Web service and establishes a VPN using the certificate and VPN identifier. A user identifier, user name or user password is not required. A gateway computer uses the VPN identifier to access the database previously established during the provisioning session to retrieve the user identifier. Retrieval of the user identifier validates that the computing device is authorized to use the Web service. The gateway computer stores the client IP address and a mapping to the user identifier into a database (Tan, Abstract).
ii. Ye et al. (US 20090154373 A1) discloses that a customer edge to customer edge traffic matrix is generated to provide crucial information for network capacity planning, network monitoring, and/or billing. The traffic matrix can be generated by correlating Net flow Data Export (“NDE') with other information from network devices. For example, a Netflow collector (“NFC) server collects NDE from an ingress provideredge router. The NDE captures a VPN label, an input interface ID, and an Internet protocol (“IP) address associated with a top label. An ingress customer edge router Supplying a flow of data to the ingress provider edge router is identified by querying the ingress provider router, an IP Solution Center (“ISC), and/or a user maintained configuration file. The top label IP address points out an egress provider router that directs the flow to an egress customer edge router. The VPN label is used to query the egress provider router to identify the egress customer router. Because the ingress and egress customer edge routers are identified per flow, a traffic matrix can be generated (Ye, ¶ 0017).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/JOHN A FOLLANSBEE/Supervisory Patent Examiner, Art Unit 2444