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 03/31/2026. Claims 1-4 and 6-21 are pending in this application.
Response to Arguments
Applicant’s arguments filed 03/31/2026 have been fully considered but they are not persuasive. Applicant argues:
a.
Applicant states that “In contrast, the present application is directed to identifying a single user among plurality of users over VPN. Specifically, currently amended claim 1 recites, in part,
‘receiving an xFlow packet generated based on a sampled encapsulation packet from a
plurality of users’ and identify the single user of the VPN by "collating information
regarding an outer header associated with information for identifying a user of a Virtual
Private Network (VPN) among the plurality of users … As none of the cited art is directed to identifying single user of the VPN, the suggested combination of the art fails to teach or suggest such features recited by claim 1 either explicitly or implicitly (Reply, page 10).”
a.
It is unclear to the examiner how “a sampled encapsulation packet” is “from a plurality of users.” Since the Applicant intends to identify a single user among plurality of users over VPN, the examiner would interpret that both the claimed “an xFlow packet” and “a sampled encapsulation packet” refer to a single user, and the single user is one of “a plurality of users” that use VPNs.
It is also unclear to the examiner if the limitation “a user of a VPN among the plurality of users” refers to a user having one to one relationship with a VPN, or a user sharing a VPN with the plurality of users. Based on the applicant’s statement to “identify the single user of the VPN,” it appears that the context of the application refers to the user having one to one relationship with the VPN. This context of the application is supported by the instant specification and the figures of the application:
The instant specification [0022] recites that “Therefore, when each of a plurality of users uses the VPN, it is difficult to specify which user's VPN the flow corresponds to.” Since the application “analyze traffic in units of VPN (para. [0021],” it appears each user has their own corresponding VPN in the context of the application.
The instant specification [0039] recites that “In addition, the network N accommodates a plurality of networks. For example, a network of a plurality of users is connected to the network device 14.” The FIG. 1 which accompanies with this paragraph exemplifies that each user (corresponding to Terminal Device 21 and Terminal Device 22) has their own VPN tunnel.
The VPN information 421 as recited in the instant specification and illustrated in FIG. 4 and FIG. 6 is required information for collation to “specify the user of the VPN from which the xFlow packet is transferred.” FIG. 4 exemplifies that each user information corresponds to a different VPN’s outer information. The instant specification [0078] also explicitly recites that “A VPN user name and a user identifier of the VPN information 421 are an example of information regarding the VPN.”
Based on the above analysis, each user corresponds to their specific VPN in the context of the application,. The amended limitation “a user … among the plurality of users” is interpreted that there are plurality of users in the network (Kurakami exemplifies two user terminals 20 and 21 in the network 1 of FIG. 1), the user is one of the plurality of users, and the user is transmitting traffic using their own VPN. The examination of this amended limitation still focus on to receive a xFlow packet and identify from which user’s VPN the flow comes. The combination of the cited prior arts in the most recent rejection continues to reject this amended limitation. See details in the art rejection section.
Response to Amendment
The claim interpretation under 35 U.S.C. 112(f) is now withdrawn in view of the amendments.
The claim objections to claims 1, 4, 6 and 8-9 are now withdrawn in view of the amendments.
The claim rejections to claims 1-3 and 21 under 35 U.S.C. 112(b) are now withdrawn in view of the amendments.
The claim rejections to claims 4 and 6-20 under 35 U.S.C. 112(b) remain due to the lack of the amendments.
Applicant also argues that the cited art fails to teach or suggest the amended limitation “wherein the outer header included in the xFlow packet is extracted and used to calculate the statistical information and encapsulate the statistical information and the outer header into the xFlow packet” (Reply, page 10). This part of Applicant’s arguments with respect to claims 1-3, 11-13 and 21 have been considered but are moot based on the new grounds of rejection necessitated by Applicant’s amendments. Specifically, the arguments present that Kurakami-Hurren-Kakemizu fails to provide for this part of amended language for claim 1, wherein the rejection below now relies on Kurakami-Hurren-Kakemizu and Warmenhovento teach this subject matter.
The claim rejections to claims 4, 6-10 and 14-20 under 35 U.S.C. 103 remain due to the lack of amendments and/or arguments.
Claim Objections
Claims 3, 4 and 8 are objected to because of the following informalities:
In Claim 3, line 5, remove “by the reception unit.”
In Claim 4, line 8, remove “in the receiving step.”
In Claim 8, line 9, remove “in the receiving step.”
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 4 and 6-20 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 4 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 2. For examination purpose, “an xFlow packet” recited in line 8 will read as “the xFlow packet.”
Claim 8 recites the limitation “an xFlow packet” in line 9. 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 9 will read as “the xFlow packet.”
Claims 11, 14 and 17 recite the limitation “the sampled encapsulation packes” in line 4, line 3 and 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 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), and in further view of US 20190342190 A1 (hereinafter Warmenhoven).
For Claim 1, Kurakami teaches an analysis device (Kurakami exemplifies a flow information analysis apparatus in FIG. 1) comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, causes the device to perform a set of operations (Kurakami, Claim 1 “… A flow information analysis apparatus comprising: a memory; and a processor coupled to the memory and programmed to execute a process …”), the set of operations comprising:
receiving 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 from a plurality of users (Kurakami exemplifies two User Terminals 20 and 21 transmitting packets in the network 1; Examiner notes that “a sampled encapsulation packet” is from a single user in the context of the application as the analysis in Response to Arguments section, “from a plurality of users” is read as “from a user of a plurality of users” for examination; 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 …”; 0093 “… Furthermore, the flow information analysis apparatus 10 may be implemented as a flow information analysis server apparatus that adopts terminal devices used by users as clients and that provides services related to the above described flow information analysis to the clients …”),
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 …
wherein the outer header included in the xFlow packet is extracted (Kurakami, ¶ 0042 “… When the header sample matches the template, a position of each of the fields of the header sample is identified by using the template, information on the tunnel header, such as a transmission/reception IPv6 address of the IPv6 header … is extracted …”) … and encapsulate the statistical information and the outer header into the xFlow packet (Kurakami, FIG. 3; ¶ 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 …”).
Kurakami does not explicitly teach, but Hurren teaches using information regarding an outer header (Hurren teaches an VPN identifier carried in an outer encapsulation header) to identify the VPN context of encapsulated packets (Hurren teaches 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 …”).
Kurakami and Hurren are analogous art because they are related to VPN/tunneling systems.
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 defining a VPN identifier carried in an outer encapsulation header techniques of Hurren with the system of Kurakami to facilitate Kurakami disclosed outer header in the xFlow/flow information packet to include Hurren disclosed VPN identifier.
Kurakami-Hurren does not explicitly teach, but Kakemizu teaches collating information regarding an outer header associated with information for identifying a user of a Virtual Private Network (VPN) among the plurality of users (Kakemizu teaches establishing VPN tunnels per authenticated user, wherein the VPN 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, and different users may be authenticated to user different VPN tunnels) and information regarding an outer header included in the xFlow packet received (As discussed above, Kurakami disclosed outer header in the xFlow/flow information packet could include Hurren disclosed VPN identifier) to specify the user of the VPN from which the xFlow packet is transferred (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 (i.e. Hurren disclosed VPN identifier) included in an xFlow packet with Kakemizu disclosed VPN identifier in outer header information, then use identified Kakemizu stored mappings between the VPN identifier in outer header and the VPN user to identify the VPN user from which the xFlow packet is transferred) (Kakemizu, FIG. 5, 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 …”).
Kurakami, Hurren and Kakemizu are analogous art because they are related to VPN/tunneling systems.
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 stored mappings between the VPN identifier in outer header and the VPN user techniques of Kakemizu with the system of Kurakami-Hurren 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.
Kurakami-Hurren-Kakemizu does not explicitly teach, but Warmenhoven teaches the flow identifying information is used to calculate the statistical information (Warmenhoven teaches process of tagging the elements based on the flow identifying information and using the tagged elements for analytical computation (i.e. calculating the statistical information); Examiner notes that the extracted tunnel/outer header information of Kurakami-Hurren-Kakemizu is provided as the flow identifying information; FIG. 1, FIG. 4; ¶ 0008 “… The present invention is of a system and method for preparing network flows for analysis, by decomposing such flows into a plurality of elements which are then tagged. Tagged elements may optionally comprise a combination of any type of element according to any type of network flow standard, including but not limited to the IPFIX or Netflow standards, or may optionally be derived from such elements, for example optionally with the addition of external (non-flow) information or by performing some type of calculation on the network flow standard element(s) …”; ¶ 0029 “… Flow export optionally occurs according to one or more different protocols, including but not limited to IPFIX and/or NetFlow. The IPFIX protocol is currently known as RFC 7011, and the NetFlow protocol is known as RFC 3954. The flow data is a metadata summary, which the Flow Exporter 2 prepares using one of these flow export protocols. The flow data is preferably organized such that not all of the packet data is needed, for example optionally the flow data may only be derived from the packet headers, or from other packet behavior quantifiable packet characteristics or analysis …”; ¶ 0043 “… However when the new flow data is available in stage 20, then the process continues to stage 21, with preprocessing of the flow data. This preprocessing stage is described in greater detail with regard to Drawing E. The preprocessing stage preferably adds more metadata in the form of flow data columns to the flow data. The preprocessing and tagging is important for the present invention, at least some embodiments, because this relates to a method in which the data being examined may be pre-analyzed or preprocessed in a way so as to reduce the amount of computational resources required, and/or to distribute these computational resources in a way which may be more easy to implement, and at the very least which is more flexible and allows different appliances and/or computational devices or Components within the system to assume different aspects of the processing method, and/or of any type of analysis …”; ¶ 0061 “… The third module (50) uses the columns 'Bytes sent' and 'Bytes received' and then, using the formula (sent/received)xl000000 calculates the traffic ratio and puts that value in the new column 'Traffic ratio', as another example of a simple tagged element …”).
Warmenhoven 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 data processing techniques of Warmenhoven with the system of Kurakami-Hurren-Kakemizu to reduce the amount of computational resources required, and distribute the computational resources for the process to be easier to implement (Warmenhoven ¶ 0043).
For Claim 3, Kurakami-Hurren-Kakemizu-Warmenhoven teaches the analysis device according to claim 1, further comprising: displaying 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 (Kurakami teaches 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 …”).
For Claim 21, Kurakami-Hurren-Kakemizu-Warmenhoven teaches the analysis device according to claim 1, wherein the outer header is extracted from the xFlow packet received 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
Claim 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), in view of US 20190342190 A1 (hereinafter Warmenhoven), and in further view of US 20080031240 A1 (hereinafter Hughes).
For Claim 2, Kurakami-Hurren-Kakemizu-Warmenhoven 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 do not match, the information regarding the outer header included in the xFlow packet is stored and the information indicating that the user of the VPN is unknown in association with each other in a storage unit (Hughes teaches 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-Warmenhoven 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-Warmenhoven to match data in the communications networks to data in a flow (Hughes ¶ 0011).
Claim Rejections - 35 USC § 103
Claims 4, 7-8, 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), and in further view of US 7068640 B2 (hereinafter Kakemizu).
For Claim 4, Kurakami teaches an analysis method (Kurakami exemplifies a flow information analysis apparatus in FIG. 1) comprising:
receiving 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 …”; 0093 “… Furthermore, the flow information analysis apparatus 10 may be implemented as a flow information analysis server apparatus that adopts terminal devices used by users as clients and that provides services related to the above described flow information analysis to the clients …”),
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 teaches an VPN identifier carried in an outer encapsulation header) to identify the VPN context of encapsulated packets (Hurren teaches 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 7, Kurakami-Hurren-Kakemizu teaches the analysis method according to claim 4, further comprising: displaying 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 the user of the VPN and information regarding an outer header included in the xFlow packet received match as a result of the collating (Kurakami teaches 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 4.
For Claim 8, the claim is substantially similar to claim 4 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 7 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.
Claim Rejections - 35 USC § 103
Claims 6 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), and in further view of US 20080031240 A1 (hereinafter Hughes).
For Claim 6, Kurakami-Hurren-Kakemizu does not explicitly teach, but Hughes teaches the analysis method according to claim 4, wherein in a case where storing 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 do not match, 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 (Hughes teaches 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 9, the claim is substantially similar to claim 6 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), in view of US 20190342190 A1 (hereinafter Warmenhoven), and in further view of US 20090316590 A1 (hereinafter Lund).
For Claim 11, Kurakami-Hurren-Kakemizu-Warmenhoven does not explicitly teach, but Lund teaches the analysis device according to claim 1, further comprising: separating the xFlow packet acquired by a conversion device into xFlow packets containing the outer header and inner headers of the sampled encapsulation packet and the xFlow packet containing statistical information (Lund teaches 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-Warmenhoven 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-Warmenhoven 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-Warmenhoven-Lund teaches the analysis device according to claim 11, further comprising: removing the outer header from the xFlow packet containing the outer header and inner header of the sampled packet among the xFlow packet separated (Kurakami teaches 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 …”).
Claim Rejections - 35 USC § 103
Claim 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), in view of US 20190342190 A1 (hereinafter Warmenhoven), in view of US 20090316590 A1 (hereinafter Lund), and in further view of US 20130114612 A1 (hereinafter Singh).
For Claim 13, Kurakami-Hurren-Kakemizu-Warmenhoven-Lund does not explicitly teach, but Singh teaches the analysis device according to claim 11, further comprising: converting 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 teaches 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-Warmenhoven-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-Warmenhoven-Lund to facilitate the high availability, network efficiency, scalability of network flow monitoring (Singh ¶ 0039).
Claim Rejections - 35 USC § 103
Claims 14-15 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), and in further view of US 20090316590 A1 (hereinafter Lund).
For Claim 14, Kurakami-Hurren-Kakemizu does not explicitly teach, but Lund teaches the analysis method according to claim 4, further comprising: separating the xFlow packet acquired into xFlow packets containing the outer header and inner headers of the sampled encapsulation packets and the xFlow packet containing statistical information (Lund teaches 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 15, Kurakami-Hurren-Kakemizu-Lund teaches the analysis method according to claim 14, further comprising: removing the outer header from the xFlow packet containing the outer header and inner header of the sampled packet among the xFlow packet separated (Kurakami teaches 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 17, the claim is substantially similar to claim 14 and therefore is rejected for the same reasoning set forth above.
For Claim 18, the claim is substantially similar to claim 15 and therefore is rejected for the same reasoning set forth above.
Claim Rejections - 35 USC § 103
Claims 16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190230198 A1 (hereinafter Kurakami), in view of US 6788681 B1 (hereinafter Hurren), in view of US 7068640 B2 (hereinafter Kakemizu), in view of US 20090316590 A1 (hereinafter Lund), and in further view of US 20130114612 A1 (hereinafter Singh).
For Claim 16, Kurakami-Hurren-Kakemizu-Lund does not explicitly teach, but Singh teaches the analysis method according to claim 15, further comprising: converting the xFlow packet acquired into an xFlow packet in a format corresponding to the processing content of the output destination (Singh teaches 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 19, the claim is substantially similar to claim 16 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. US 2014/0369238 A1 (Alaettinoglu) teaches that a system and method collects information for VPN traffic from non edge routers that are coupled to edge routers and identifies the path the traffic took and the 5 customer corresponding to the VPN. The system and method also identifies the ingress router coupled to the non edge router from which the traffic was collected. The system and method may assign identifiers to-route targets (Abstract).
ii. US 2010/0226282 A1 (Aitken) teaches that an apparatus is provided in one example embodiment and includes a network element configured to receive a plurality of packets. The network element is configured to couple to a module, the module being configured to generate a data record that is based on information associated with the packets and capable of being interpreted according to a template in which multiple information elements can be positioned to create a hierarchical relationship within structured data. The structured data further includes references to the information elements. The network element further including an export module configured to export the data record to a next destination (Abstract).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights