Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Requirement to Restriction/Election
Applicant has elected Grp 1 consisting of claims 1-10 & 19-20 and has withdrawn claims 11-18 in response to requirement to restriction/election issued by Examiner. Examiner, hence, has only examined elected claims 1-10 & 19-20 on merit basis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
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.
Claims 1-6 & 19 are rejected under 35 USC 103 as being unpatentable over Varsanyi (WO2022026466A1) in view of Juma (US 20210111907 A1) and Rose (US 20040260652 A1)
Regarding claim 1, Varsanvi discloses a device, comprising: a processor; a
memory communicatively coupled to the processor; and a traffic analysis logic, configured to: receive an enhanced NetFlow packet comprising a certificate, [abstract: …. In an embodiment, transport sessions are assembled from raw packets captured in network traffic. Data is extracted from two or more encapsulation layers of each transport session. In particular, each encapsulation layer may be classified into a protocol, and data may be extracted from the encapsulation layer based on the protocol. For example, cryptographic metadata may be extracted from a cryptographic encapsulation layer. The extracted data is incorporated into a data model of the network, which comprises tallies of traffic within the network, grouped according to a plurality of dimensions. Analytic model(s) may be applied to the data model to, for example, generate a data web of the network that represents structured data stores and data flows to and/or from the data stores within the network. [141] In an embodiment, an analytic model 360 may be applied to data model 350 in subprocess 370 to detect the use of unacceptable cryptographic parameters. Examples of cryptographic parameters include, without limitation, cipher algorithm, key size, TLS versions, extensions (e.g., Key Usage), key exchange method, key exchange bits, hash algorithm, alerts, sesson resumption, and the like. Unacceptable cryptographic parameters may be those that violate a security posture or security policy of the organization using network 200, even though such parameters may be acceptable to the end points of connections. Detection of unacceptable cryptographic parameters, organized in terms of traffic volume and end points, enables the identification of obsolete or misconfigured servers and/or clients. This analysis may be used to detect and remediate vulnerable servers and/or clients. For example, victims of the Heartbleed security bug may be discovered in real time. [142] In an embodiment, an analytic model 360 may be applied to data model 350 in subprocess 370 to detect expired or soon-to-expire certificates. Such certificates cause various forms of security and operational issues. The analysis may report information about servers and/or traffic in terms of how much time remains before expiration of the certificates in their respective certificate chains. This enables the detection of expiring certificates before the situation becomes critical (e.g., before a loss of service occurs). This also enables the detection and reporting of applications that have already lost service due to an expired certificate (e.g., caused by handshake failures).[154] Identify the usage of expired certificates in encrypted communication sessions (e.g., to identify or otherwise report on servers or other locations within network 200 that are utilizing expired certificates). [174] Collect information to enhance Netflow data (e.g., with extensions for databases, encryption, etc.).]
Although, Varsanyi teaches enhanced netflow data as illustrated above, he does not teach explicitly, however, Juma teaches:
receive a packet comprising a certificate, associated with an Initial Data Packet (IDP); associated with an Initial Data Packet (IDP); [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session (contains initial data packet (IDP)) and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 (initial data packet (IDP)) is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5. [0025] Still referring to FIG. 6, when client hello message 612 is received by server 604 on Sep. 3, 2019 at 10:00:00, upon detecting that existing digital certificate 614 issued to myserver.com is expiring within the pre-selected time period of 30 days (the existing digital certificate has an expiration time of Sep. 19, 2019 at 10:00:00), server 604 generates and sends a CSR message 616 and receives a CA-signed digital certificate message 618 from the configured, trusted CA 610. The new digital certificate supplied by CA 610 will have a time of expiration approximately six months in the future, on Mar. 19, 2020, and the TLS handshake will be completed with the new digital certificate with messaging similar to that shown in FIG. 5 for the expired digital certificate case. Server 604 thus extends its valid certificate state and is prevented from entering the invalid certificate state at the expiration date of its existing digital certificate.]
determine an expiration date based on the certificate; evaluate an expiration status of the certificate based on the expiration date; [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session (contains IDP) and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 (initial data packet (IDP)) is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5. [0025] Still referring to FIG. 6, when client hello message 612 (initial data packet (IDP)) is received by server 604 on Sep. 3, 2019 at 10:00:00, upon detecting that existing digital certificate 614 issued to myserver.com is expiring within the pre-selected time period of 30 days (the existing digital certificate has an expiration time of Sep. 19, 2019 at 10:00:00), server 604 generates and sends a CSR message 616 and receives a CA-signed digital certificate message 618 from the configured, trusted CA 610. The new digital certificate supplied by CA 610 will have a time of expiration approximately six months in the future, on Mar. 19, 2020, and the TLS handshake will be completed with the new digital certificate with messaging similar to that shown in FIG. 5 for the expired digital certificate case. Server 604 thus extends its valid certificate state and is prevented from entering the invalid certificate state at the expiration date of its existing digital certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Although, Varsanyi and Juma teaches data stream associated with IDP as illustrated above, they do not teach explicitly, however, Rose teaches-forward, based on the expiration status, a data stream to a proxy. [0053] In one preferred embodiment, the certification process enables the Resource Usage Verification Module, which operates on or in conjunction with each computing device, to uniquely identify the computing device with which it is associated. The certification process is initiated by a Certificate Request Module, which initiates a request, from a user's computing device, when a new certificate is required on the user's PC. A new certificate may be required for new users, when a pre-determined amount of value has accrued, when a previous certificate has expired, or if a user damages or removes an existing certificate. The Certificate Request Module takes, as input, a request for a certificate and returns a certificate request packet to be transmitted to a Certificate Authority Module (a proxy).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Juma with the disclosure of Rose. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques for managing available resources and increase trust worthiness. (abstract, para 0003-0005 & 0009-0013, Rose)
Regarding claim 2, although, Varsanyi and Rose teach enhanced netflow data, they dot teach explicitly, however Juma teaches wherein the expiration status of the certificate is evaluated as expired if the expiration date has elapsed. [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 (initial data packet (IDP)) is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5. [0025] Still referring to FIG. 6, when client hello message 612 is received by server 604 on Sep. 3, 2019 at 10:00:00, upon detecting that existing digital certificate 614 issued to myserver.com is expiring within the pre-selected time period of 30 days (the existing digital certificate has an expiration time of Sep. 19, 2019 at 10:00:00), server 604 generates and sends a CSR message 616 and receives a CA-signed digital certificate message 618 from the configured, trusted CA 610. The new digital certificate supplied by CA 610 will have a time of expiration approximately six months in the future, on Mar. 19, 2020, and the TLS handshake will be completed with the new digital certificate with messaging similar to that shown in FIG. 5 for the expired digital certificate case. Server 604 thus extends its valid certificate state and is prevented from entering the invalid certificate state at the expiration date of its existing digital certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Rose with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Regarding claim 3, although, Varsanyi and Rose teach enhanced netflow data, they dot teach explicitly, however Juma teaches wherein the data stream is forwarded to the proxy if the expiration status of the certificate is evaluated as expired. [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 (initial data packet (IDP)) is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5. [0025] Still referring to FIG. 6, when client hello message 612 is received by server 604 on Sep. 3, 2019 at 10:00:00, upon detecting that existing digital certificate 614 issued to myserver.com is expiring within the pre-selected time period of 30 days (the existing digital certificate has an expiration time of Sep. 19, 2019 at 10:00:00), server 604 generates and sends a CSR message 616 and receives a CA-signed digital certificate message 618 from the configured, trusted CA 610. The new digital certificate supplied by CA 610 will have a time of expiration approximately six months in the future, on Mar. 19, 2020, and the TLS handshake will be completed with the new digital certificate with messaging similar to that shown in FIG. 5 for the expired digital certificate case. Server 604 thus extends its valid certificate state and is prevented from entering the invalid certificate state at the expiration date of its existing digital certificate.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Rose with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Regarding claim 4, although, Varsanyi and Rose teach enhanced netflow data, they dot teach explicitly, however Juma teaches wherein the proxy issues a proxy certificate for the data stream. [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Rose with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Regarding claim 5, although, Varsanyi and Rose teach enhanced netflow data, they dot teach explicitly, however Juma teaches wherein the certificate corresponds to a server or a client device. [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Rose with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Regarding claim 6, although, Varsanyi and Rose teach enhanced netflow data, they dot teach explicitly, however Juma teaches wherein the certificate is indicative of a certificate issuer. [0021] FIG. 4 is an entity flow diagram showing an example of the initiation of a TLS session and action upon detection of an expired digital certificate. System 400 includes client 402, server 404, configured key manager 406, configured key store 408, and trusted certificate authority 410. Server 404 references configured key manager 406, which in turn references configured key store 408. The server resides at myserver.com and is configured to use the pre-selected CA 410 using a certificate-authority: reference tag. The configured key manager 406 is configured to use configured key store 408 using a key-store: reference tag. When client hello message 412 is received by server 404 on Jun. 19, 2019 at 10:00:00, upon detecting that existing digital certificate 414 issued for myserver.com is expired because it has an expiration time of Jun. 15, 2019 at 08:00:00, server 404 generates and sends a CSR message 416 and receives a CA-signed digital certificate message 418 from the configured, trusted CA. The new digital certificate supplied by CA 410 will have a time of expiration approximately six months in the future, as will be discussed below with respect to FIG. 5.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi and Rose with the disclosure of Juma. The motivation or suggestion would have been to implement a system that will provide efficient techniques for handling risks associated with a received certificate whose validity has already expired. (abstract, para 0002-0003 & 0008-0009, Juma)
Regarding claim 19, this claim is interpreted to be similar to claim 1 and rejected for the same reasons as set forth for the claim 1.
Claim 7 is rejected under 35 USC 103 as being unpatentable over Varsanyi (WO2022026466A1) in view of Juma (US 20210111907 A1) and Rose (US 20040260652 A1) and Tang (US 20210194909 A1)
Regarding claim 7, although, Varsanyi, Juma and Rose IDP, they do not teach explicitly, however, Tang teaches wherein the traffic analysis logic is further configured to store at least one of: the IDP, the certificate, the expiration status, or the expiration date in a table in the memory. [0381] (1) a distributed file system 84a or HDFS for storing various files as the original data, specifically including: network traffic (PCAP file); various related files, including various HTML files, pictures and PKI certificates extracted from network traffic; and various web pages, pictures, certificates, binary files, etc. obtained by the crawler from the Internet;]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi, Juma, Rose with the disclosure of Tang. The motivation or suggestion would have been to implement a system that will provide efficient techniques for a certificate or file, querying whether the certificate or file is related to a known malicious behavior through threat intelligence sources (abstract, para 0368, Tang)
Claims 8-9 & 20 are rejected under 35 USC 103 as being unpatentable over Varsanyi (WO2022026466A1) in view of Juma (US 20210111907 A1) and Rose (US 20040260652 A1), Tang (US 20210194909 A1) and FU (US 20110126001 A1)
Regarding claim 8, although, Varsanyi, Juma , Rose and Tang teach expired certificate, they do not teach explicitly, however, FU teaches wherein the table further stores a grace period associated with the certificate. [0028] The certificate system 120 includes a CA database. The CA database may be implemented, for example, using various types of database technologies. In one embodiment, as depicted in FIGS. 1 and 2, the certificate system 120 implements the CA database using a Lightweight Directory Access Protocol (LDAP) directory server 127 that manages LDAP entries 146 stored in the LDAP repository 140. The LDAP directory server 127 may be one or more machines including one or more server computers, gateways or other computing systems. LDAP is a set of open protocols used to access centrally stored information over a network. LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information and can enable access to the information from any machine on the LDAP enabled network. In other embodiments, the LDAP entry 146 may contain along with the original certificate, the certificate profile used to enroll the original certificate, its public key, the subject DN, the original certificate request, the original certificate's extension, etc., for example. The certificate profile includes a set of rules concerning the issuing of a certificate by the certificate manager 125, for example, the kind of content that is required to submit the request, the way the request is processed and approved (authenticated and authorized), the information that is included in the certificate content, and how long the certificate is valid. In other embodiments, the LDAP entry 146 may contain, along with the original certificate, an original enrollment profile used to enroll the original certificate, its public key, the subject DN, the enrollment request for the original certificate, the original certificate's extension, for example. The original certificate request entry may also contain the original validity period of the certificate and the grace period for renewing the certificate. The grace period is the time before and after the expiration date when renewal is allowed. In one embodiment, if a certificate is outside of the grace period, the certificate cannot be automatically renewed by the automatic renewal module 130. In other embodiments of automatic renewal, the certificate manager 125 can automatically renew certificates that are outside of the grace period. Alternatively, the CA database may be stored on other types of data storage devices that store records of digital certificates in the CA database.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi, Juma, Rose and Tang with the disclosure of Fu. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques for authenticating a unknown user or device based on their certificate (abstract, para 0002-0007, Fu)
Regarding claim 9, although, Varsanyi, Juma, Rose and Tang teach expired certificate and forward the data stream to proxy, they do not teach explicitly, however, FU teaches retrieve the grace period associated with the certificate; and forward the data stream if the grace period has elapsed. [0028] The certificate system 120 includes a CA database. The CA database may be implemented, for example, using various types of database technologies. In one embodiment, as depicted in FIGS. 1 and 2, the certificate system 120 implements the CA database using a Lightweight Directory Access Protocol (LDAP) directory server 127 that manages LDAP entries 146 stored in the LDAP repository 140. The LDAP directory server 127 may be one or more machines including one or more server computers, gateways or other computing systems. LDAP is a set of open protocols used to access centrally stored information over a network. LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information and can enable access to the information from any machine on the LDAP enabled network. In other embodiments, the LDAP entry 146 may contain along with the original certificate, the certificate profile used to enroll the original certificate, its public key, the subject DN, the original certificate request, the original certificate's extension, etc., for example. The certificate profile includes a set of rules concerning the issuing of a certificate by the certificate manager 125, for example, the kind of content that is required to submit the request, the way the request is processed and approved (authenticated and authorized), the information that is included in the certificate content, and how long the certificate is valid. In other embodiments, the LDAP entry 146 may contain, along with the original certificate, an original enrollment profile used to enroll the original certificate, its public key, the subject DN, the enrollment request for the original certificate, the original certificate's extension, for example. The original certificate request entry may also contain the original validity period of the certificate and the grace period for renewing the certificate. The grace period is the time before and after the expiration date when renewal is allowed. In one embodiment, if a certificate is outside of the grace period, the certificate cannot be automatically renewed by the automatic renewal module 130. In other embodiments of automatic renewal, the certificate manager 125 can automatically renew certificates that are outside of the grace period. Alternatively, the CA database may be stored on other types of data storage devices that store records of digital certificates in the CA database.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi, Juma, Rose and Tang with the disclosure of Fu. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques for authenticating a unknown user or device based on their certificate (abstract, para 0002-0007, Fu)
Regarding claim 20, this claim is interpreted to be similar to claim 9 and rejected for the same reasons as set forth for the claim 9.
Claim 10 is rejected under 35 USC 103 as being unpatentable over Varsanyi (WO2022026466A1) in view of Juma (US 20210111907 A1) and Rose (US 20040260652 A1) and Friedman (US 20130117847 A1)
Regarding claim 10, although, Varsanyi, Juma and Rose tach enhanced Netflow data, they do not teach explicitly, however, FU teaches wherein the enhanced NetFlow packet is in a NetFlow template or an Internet Protocol Flow Information Export (IPFIX) template. [0017] The present invention relates to a system and method capable of receiving arbitrary structured data, e.g., network or machine-generated metadata, in a variety of data formats (hereafter network metadata), efficiently processing the network metadata and forwarding the received network metadata and/or network metadata derived from the original network metadata in a variety of data formats. Network metadata could be generated by a variety of network devices such as routers, switches, firewalls, intrusion detection systems (IDS), intrusion protection systems (IPS), network address translation (NAT) entities and many others. The network metadata information is generated in a number of formats including but not limited to NetFlow and its variants, (e.g., jFlow, cflowd, sFlow, IPFIX), SNMP, SMTP, syslog, etc. The method and system described herein is able to output network metadata information in a number of formats including but not limited to NetFlow and its versions, (jFlow, cflowd, sFlow, IPFIX,) SNMP, SMTP, syslog, OpenFlow, etc. In addition, embodiments of the invention are able to output selected types of network metadata information at a rate sufficient to allow real-time or near-real-time network services to be provided. As a result, the system is capable of providing meaningful services in deployments with N (N.gtoreq.1) producers of the network metadata and M (M.gtoreq.1) consumers of the original or derived network metadata. It may be appreciated that a particular embodiment of this invention aligns with a definition of IPFIX Mediator as reflected in RFC 598]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings Varsanyi, Juma,and Rose with the disclosure of Friedman. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques for converting collected metadata to different types of formatted data (abstract, para 0003-0008, Friedman)
Examiner’s Note: The prior art made of record and not relied upon is considered pertinent to applicant's disclosure are followings:
1.Sole (US 11134058 B1) discloses network traffic inspection is. An application executing on a client device as an operating system that uses a virtual private network (VPN) stack of the operating system intercepts a first IP packet. The application determines that a policy should be applied to the intercepted first IP packet. The policy is applied to the intercepted first IP packet.
2. Song (US 20070162742 A1)-Song’s invention is directed to a method for applying a certificate suitable for a portable telephone belonging to a user, wherein the portable telephone comprises a telephone number. The method comprises steps of generating a user key pair in the portable telephone, wherein the key pair comprises a user public key information and then transmitting an applying packet from the portable telephone to a certificate authority through a switching center by using a short message service, wherein the applying packet comprises at least the user public key information. The user is verified according to the telephone number received by the certificate authority from the switching center. A certificate packet is generated by the certificate authority, wherein the certificate packet comprises at least a serial number and a certificate authority signature. The certificate packet is transmitted to the portable telephone according to the telephone number by using the short message service.
3. Tang Kan Yi (CN 114117429 B- English translation and original is attached)) describes invention that relates to the technical field of network traffic management, and claims a method and a device for detecting network traffic. The method comprises: the gateway obtains the network flow to be detected corresponding to the appointed port on the server; the gateway classifies the flow data to be detected according to the pre-set rule to obtain the flow data corresponding to each flow type, the pre-set rule is the classification rule set aiming at the flow type; the gateway performs the abnormal detection to the flow data of each flow type to obtain the flow data to be distributed; the gateway distributes the traffic data to be distributed to the service node associated with the corresponding traffic type; The service node performs abnormal detection on the received traffic data from the gateway when its micro-service is started. Through the invention, the gateway and each service node can directly perform independent abnormal detection to the flow data without other modes, which saves the detection time of the malicious flow and improves the detection efficiency of the malicious flow.
4. Hazlewood (US 20090327708 A1) teaches a method, system, and computer usable program product for certificate distribution using a secure handshake are provided in the illustrative embodiments. A client sends an indication in a request, the request being a part of a secure data communication with a server. The indication indicates an ability of the client to accept a certificate as a part of a response from the server. The server retrieves a new certificate. The server sends as a result of the indication, a new certificate in the response corresponding to the request. The client receives as a result of the indication, the new certificate in a response that corresponds to the request. The client separates the new certificate from the response and uses the new certificate in the secure data communication with the server. The server uses the new certificate in the secure data communication with the client.5. xx (US 20120202495 A 1,), this disclosure relates to system and method for providing road information in advance.
Special Note: Although few prior are mentioned above, in fact, all the prior arts made of record and listed on the PTO-892 and not relied upon are considered pertinent to applicant’s disclosure.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHER KHAN whose telephone number is (571)272-8574. The examiner can normally be reached on Monday-Friday-8:00am - 5:00pm (EST).If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on 571-272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHER A KHAN/ Primary Examiner, Art Unit 2497