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 .
Response to Arguments
1. Applicant's arguments have been fully considered but they are not persuasive. Applicant argues that the prior art does not teach “an ordered list of port number of network components.”
Examiner respectfully disagrees.
Examiner notes that a “port number” is merely a naming convention, similar to “a device number.” The substance of the number would only have deeper meaning if the claims are particular dependent upon these port numbers. However, Examiner respectfully considers them not to be, and rather considers them as being a redundant definition of a routing path.
Examiner therefore considers both Opera and Nellen as describing such “an ordered list of port number of network components,” (In Opera, x+, y+, z+, w+, x−, y−, n− and w−; and in Nellen, security module 542A, security module 542C, and security module 542D) despite the absence reference to a port or port number, because a port number is merely a naming convention, and so it is reasonable to interprets the port name as the node name. (for example, any port on security module 542A can comprise the “port number” of “port security module 542A,” as Examiner interprets a port number as merely a naming convention).
Additionally, Examiner considers this to be a reasonable interpretation as (1) computer network descriptions are well-understood as being minimalist representations of the network. This means that a node, which in principle could have multiple points, is instead understood as being a singular point. This removes the distinction between a node and a port as port is merely a communication endpoint, and under the common convention of interpreting network diagrams any node or component would be interpreted similarly as a communication endpoint, unless otherwise specified, and therein the name/number of the node would be the port number.
(2) Furthermore, Examiner notes that the claims do not directly invoke the usage of the port numbers, rather the claims only involve the holistic element of “an ordered list of port number of network components in the routing path.” As such, broad interpretations of port number satisfy the claims as the claims never require any particular usage of a port number aside from the holistic application.
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, 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.
2. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Oprea et al. (US 20160344618 A1) in view of Nellen (US 20190141015 A1).
Claim 1 Oprea teaches a system for restricting traffic in a computer network, the system comprising:
a system to extract a routing path of a packet, (FIG. 12, ¶0056, extracting the header from a packet to analyze the routing paths, i.e. extracting the routing paths) wherein the routing path comprises an ordered list of port number of network components in the routing path. (FIG. 16, ¶0058, wherein the routing path comprises an order list of nodes, i.e. network components in the routing path; Examiner notes that a port number are interpreted as a naming convention, FIG. 17, ¶0059, wherein the port number comprises output port “k” in question; ports 1 to 8 i.e. the output port discussed above: x+, y+, z+, w+, x−, y−, n− and w−)
However, Oprea does not explicitly teach a memory; and
a processor to:
determine whether to allow or block the packet based on the ordered list of port numbers of network components in the routing path.
From a related technology, Nellen teaches a memory; (¶0043, memory) and
a processor (¶0043, processor) to:
determine whether to allow or block the packet based on the ordered list of port number of network components in the routing path. (FIG. 5A, ¶0181, after selection of the routing path the firewall blocking or permitting the routing path; Examiner notes that port numbers interpreted as a naming convention; FIG. 5A, ¶0181, wherein the order list of port numbers that the routing path comprises may be for example security module 542A, security module 542C, and security module 542D)
It would be obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the teachings of Oprea to evaluate the packets firewall permissions as taught by Nellen in order to more effectively utilize network resources.
Claim 2 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the routing path defines the physical path of the packet. (Oprea, ¶0228, wherein the network paths are physical)
Claim 3 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the routing path comprises an ordered list of port numbers of network components in the routing path. (Oprea, FIG. 12, ¶0056, extracting the routing path wherein a routing path is an order path of network components and their port numbers)
Claim 4 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the packet is an incoming packet, (Oprea, FIG. 12, ¶0056, wherein a packet is received, i.e. incoming to the receiver) and wherein the routing path is a return path defining a path for a response packet. (Oprea, FIG. 12, ¶0056, wherein the routing path comprises the return path of the response packets)
Claim 5 Oprea in view of Nellen teaches Claim 4, and further teaches wherein the return path is updated by network components along an ongoing path of the packet. (Oprea, ¶0066, wherein the topology computing the paths is updated by network components)
Claim 6 Oprea in view of Nellen teaches Claim 1, and further teaches, wherein the packet is an incoming packet, (Oprea, FIG. 12, ¶0056, wherein a packet is received, i.e. incoming to the receiver) wherein an ongoing path of the packet is determined by a source node sending the packet, wherein a return path of the packet is updated by network components along the ongoing path, (Oprea, ¶0066, wherein the topology computing the paths is updated by network components) and wherein the processor is configured to extract the routing path of the packet from the packet data by extracting the return path of the packet. (Oprea, FIG. 12, ¶0056, extracting the header from a packet to analyze the routing paths, i.e. extracting the routing paths)
Claim 7 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the packet is an outgoing packet, (Oprea, FIG. 12, ¶0056, wherein a packet is received, i.e. outgoing from the transmitter) wherein an ongoing path of the packet is determined by a source node sending the packet, (Oprea, ¶0012, wherein the source routing is determined by the source node) and wherein the processor is configured to extract the routing path of the packet from the packet data by extracting the ongoing path of the packet. (Oprea, FIG. 12, ¶0056, extracting the header from a packet to analyze the routing paths, i.e. extracting the routing paths)
Claim 8 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the processor is configured to determine whether to allow or block the packet based on the routing path by allowing packets with certain routing paths and blocking packets with other routing paths. (Nellen, FIG. 5A, ¶0181, determining whether to allow or block packets, i.e. allowed packets, or disallowed paths, i.e. blocked packets)
It would be obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the teachings of Oprea to evaluate the packets firewall permissions as taught by Nellen in order to more effectively utilize network resources.
Claim 9 Oprea and Nellen teaches Claim 1, and further teaches wherein the processor is configured to determine whether to allow or block the packet based on the routing path by:
applying at least one rule on the routing path; allowing the packets that conform to the at least one rule; and blocking the packets that do not conform to the at least one rule. (Nellen, FIG. 5A, ¶0181, determining whether to allow or block packets, i.e. allowed packets, or disallowed paths, i.e. blocked packets)
It would be obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the teachings of Oprea to evaluate the packets firewall permissions as taught by Nellen in order to more effectively utilize network resources.
Claim 10 Oprea in view of Nellen teaches Claim 1, and further teaches wherein the computer network is an InfiniBand computer network. (Oprea, ¶0055, wherein the packets are Infiniband packets, i.e. the network is an Infiniband computer network)
Claim 11 Oprea and Nellen teaches a method for restricting traffic in a computer network, the method comprising:
extracting a routing path of a packet (FIG. 12, ¶0056, extracting the header from a packet to analyze the routing paths, i.e. extracting the routing paths) wherein the routing path comprises an ordered list of port number of network components in the routing path. (FIG. 16, ¶0058, wherein the routing path comprises an order list of nodes, i.e. network components in the routing path; Examiner notes that a port number are interpreted as a naming convention, FIG. 17, ¶0059, wherein the port number comprises output port “k” in question; ports 1 to 8 i.e. the output port discussed above: x+, y+, z+, w+, x−, y−, n− and w−)
However, Oprea does not explicitly teach determining whether to allow or block the packet based on the routing path.
From a related technology, Nellen teaches determining whether to allow or block the packet based on the ordered list of port number of network components in the routing path. (FIG. 5A, ¶0181, after selection of the routing path the firewall blocking or permitting the routing path; Examiner notes that port numbers interpreted as a naming convention; FIG. 5A, ¶0181, wherein the order list of port numbers that the routing path comprises may be for example security module 542A, security module 542C, and security module 542D)
It would be obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the teachings of Oprea to evaluate the packets firewall permissions as taught by Nellen in order to more effectively utilize network resources.
Claims 12-19 are taught by Oprea and Nellen as described for Claims 2-9.
Claim 20 Quevedo teaches a method for implementing an authorization mechanism in a computer network, the method comprising:
determining a routing path of a packet (FIG. 12, ¶0056, extracting the header from a packet to analyze the routing paths, i.e. extracting the routing paths) wherein the routing path comprises an ordered list of port number of network components in the routing path. (FIG. 16, ¶0058, wherein the routing path comprises an order list of nodes, i.e. network components in the routing path; Examiner notes that a port number are interpreted as a naming convention, FIG. 17, ¶0059, wherein the port number comprises output port “k” in question; ports 1 to 8 i.e. the output port discussed above: x+, y+, z+, w+, x−, y−, n− and w−)
However, Oprea does not explicitly teach allowing the packet based on the routing path.
From a related technology, Nellen teaches allowing the packet based on the ordered list of port number of network components in the routing path. (FIG. 5A, ¶0181, after selection of the routing path the firewall blocking or permitting the routing path; Examiner notes that port numbers interpreted as a naming convention; FIG. 5A, ¶0181, wherein the order list of port numbers that the routing path comprises may be for example security module 542A, security module 542C, and security module 542D)
It would be obvious to one of ordinary skill in the art before the filing date of the claimed invention to modify the teachings of Oprea to evaluate the packets firewall permissions as taught by Nellen in order to more effectively utilize network resources.
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 CHRISTOPHER PALACA CADORNA whose telephone number is (571)270-0584. The examiner can normally be reached M-F 10:00-7:00.
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 at (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.
/CHRISTOPHER P CADORNA/Examiner, Art Unit 2444
/JOHN A FOLLANSBEE/Supervisory Patent Examiner, Art Unit 2444
Prosecution Insights