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 .
Information Disclosure Statement
The IDS filed 6/28/2025 has been considered.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 15 recites in part: “a network system for data transfer, the system comprising: an external network comprising at least one first network element and an external network communication element, the external network communication element being designed to monitor the external network; and an internal network comprising at least one second network element and an internal network communication element, the second network element being designed to communicate solely within the internal network, the external network communication element and the internal network communication element being communicatively connected to one another via an IP communication channel…”
The network system, as claimed, lists only first network element, an external network communication element, second network element, and an internal network communication element.
In view of the specification:
[0022] The first network element may, for example, be a browser on a desktop PC that requests a service such as downloading of an HTML page.
[0023] In contrast, the second network element may be the counterpart to the first network element, and offers a service such as providing an HTML page for downloading.
[0056] The second network element and the internal network communication element can be virtual nodes on a shared system.
[0058] The first network element and the external network communication element can be virtual nodes on a shared system.
The elements listed under the network system in claim 15 are not necessarily hardware. Instead, one can reasonably interpret them as software, per se, which is non-statutory.
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.
Claim 4 is 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 recites the limitation "the address and/or the port" in lines 1 and 2 of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Venkat et al. (US 7788407, hereinafter referred to as “Venkat”).
Regarding claim 1, Venkat teaches a computer-implemented method for data transfer in a network system (figure 1) comprising an external network (figure 1: public/global/external network 101) and an internal network (figure 1: private/local/internal network 102), the external network including at least one first network element (figure 1: clients 110-114) and an external network communication element (figure 1: clients communicate through gateway interface), the external network communication element being designed to monitor the external network (figure 1: gateway 150 inspects traffic as part of application layer processing.), the internal network including at least one second network element (figure 1: servers 120-124) and an internal network communication element (figure 1: servers communicate through gateway interface), the second network element being designed to communicate solely within the internal network (figure 1: communication is through gateway, therefore internal network is isolated, which implies that it communicates solely within internal network), the external network communication element and the internal network communication element being communicatively connected to one another via an IP communication channel (figure 1: clients 110-114 and servers 120-124 all have their respective IP addresses, therefore an IP communication channel is implied), the method comprising:
encoding, by the first network element, the data to be sent (col. 13, lines 31-50: references (e.g., original references) are transformed into a format referred to herein as a "translated reference" that allows the internal and external networks to exchange these portions of data via a gateway computer system in a compatible manner, even though the original references before such translation may not be compatible (e.g., resolvable or routable) on the external network.);
transferring the encoded data from the first network element to the external network communication element (col. 10, lines 54-64: the portion of data is a packet transferred on the external network to a gateway computer system. The portion of data is received by the gateway computer system which couples the internal network to the external network and the reference specifying a computer system in the portion of data that is received is a network address of the gateway computer system. The computer system identifier that corresponds to a specific computer system on the internal network is a port reference to a port in the gateway computer system that is mapped to the specific computer system on the internal network.);
decoding the data by the external network communication element and transferring the data from the external network communication element to the internal network communication element via the IP communication channel or transferring the data from the external network communication element to the internal network communication element via the IP communication channel and decoding the data by the internal network communication element (figures 4 and 5: IP address is parsed and translated);
re-encoding the data into an application layer by the internal network communication element (figure 6: as part of gateway’s operation, packet from client 112 is parsed, translated and sent to the server 120);
transferring the re-encoded data from the internal network communication element to the second network element (figure 6: packet from client 112 is parsed, translated and sent to the server 120); and
decoding the data by the second network element (figure 6: packet is translated, and assigned to server 120).
Regarding claim 2, Venkat teaches the computer-implemented method according to claim 1, wherein the data to be sent include a message (col. 16, lines 39-54: the client computer system 112 sends an inbound message (e.g., a packet, not shown in FIG. 1) to the advertised network interface 150-1 of the gateway computer system 150, as specified in the translated reference. The inbound message further specifies the computer system identifier mapped to the original reference (also contained as part of the translated reference). The gateway computer system 150 receives the inbound message and, based on the mapping, can associate a specific server computer system 120 through 124 within the internal network 102 to the request. The gateway 150 then forwards the message (e.g., as another packet) on to the specified server. In this manner, a client request for a specific web page 130 within the web site is handled by the appropriate server 120 through 124, without the identity of that server being released in references in the web page 130 that get served to the external network 101.), the encoding of the data including enveloping of the data in at least one protocol shell (inherent to any application layer communication), the decoding of the data including removal of at least one protocol shell (figures 5 and 6: address is parsed), the re-encoding of the data by the internal network communication element including enveloping of the data in at least one protocol shell (figure 6: packet from client 112 is parsed, translated and sent to the server 120. In order to inspect, validate, and reconstruct application-layer messages, the gateway must remove all protocol layers (i.e., “protocol shells”) down to the application payload, therefore this teaching is implied).
Regarding claim 3, Venkat teaches the computer-implemented method according to claim 2, wherein the decoding of the data includes removal of all protocol shells (col. 13, lines 37-51: The invention allows this to occur even though references such as hostnames and/or network addresses of computer systems within the internal network that are contained within portions of data (e.g., in application data such as web pages, or in data communications protocol information such as packet headers) might not be compatible with the computing system environment on the external network. The invention provides systems and techniques that transform these references (e.g., original references) into a format referred to herein as a "translated reference" that allows the internal and external networks to exchange these portions of data via a gateway computer system in a compatible manner, even though the original references before such translation may not be compatible (e.g., resolvable or routable) on the external network. In order to inspect, validate, and reconstruct application-layer messages, the gateway must remove all protocol layers (i.e., “protocol shells”) down to the application payload, therefore this teaching is implied.
Regarding claim 4, Venkat teaches the computer-implemented method according to claim 2, wherein the address and/or the port of the second network element have/has been dynamically generated (col. 19, lines 32-41: It is to be understood that at some point prior to, or during, the translation of references 184-1 and 186-1, the computer system identifier negotiation protocol processes 220-1 and 220-2 interoperate to dynamically map the hostname SERVER-A and its corresponding IP address "10.0.0.1" to the data communications protocol port 6001 within the network interface 150-1 of the gateway computer system 150, and also dynamically map the IP address "10.0.0.2" (and corresponding hostname SERVER-B) to the data communications protocol port number 6002 within the network interface 150-1.).
Regarding claim 5, Venkat teaches the computer-implemented method according to claim 1, wherein the IP communication channel between the external network communication element and the internal network communication element is a static IP communication channel (col. 16, lines 19-26: the computer system identifier is a specific data communications protocol port associated with the advertised gateway interface 150-1 within the gateway computer system 150. The invention assigns (i.e., maps) internal network hostname and network address pairs to respective data communications protocol ports associated with the advertised gateway interface 150-1, as needed for reference translation. Although static IP is not explicitly recited, static IP channels are known to be default configuration for internal communication between gateway components).
Regarding claim 6, Venkat teaches the computer-implemented method according to claim 1, wherein the data are decoded regardless of whether the port, contained in the data encoded by the first network element, is operated by one of the network communication elements (col. 23, line 66 to col. 24, line 16: (56) When the gateway interface 150-1 within the gateway computer system 150 receives the inbound packet 321, it performs NAPT functionality (or twice NAPT functionality) to determine which internal network server computer system 120 through 124 is to receive the packet contents (i.e., the HTTP GET request, not specifically shown). As explained previously, the ALG reference translators 160 can reference the reference translation data structure 210 (e.g., FIG. 5) to determine mappings between port numbers and computer system identities (hostnames or network addresses). As such, when the packet 321 arrives at the gateway computer system 150, the ALG reference translator 160-1, performing NAPT functionality, retrieves the destination port number "6001" and uses this to look-up an entry (e.g., a row) in the table 210 that contains an identity of an internal network server computer system that is mapped to this port number. In this case, as previously explained (and referring to FIG. 5), the port number 6001 maps to server computer system 120, or hostname "SERVER-A" having network address 10.0.0.1. The gateway performs application-layer parsing whenever data packet arrives regardless of which port number the external client uses).
Regarding claim 7, Venkat teaches the computer-implemented method according to claim 1, wherein the second network element sends a response to the internal network communication element when the second network element does not operate the port that is contained in the data received from the internal network communication element (although not explicitly mentioned, in an application-layer gateway architecture, the internal host receives a reconstructed request from the internal proxy. If the request references a port or service the internal host does not support, the host returns and standard error message such as “service not available” “port not supported,” or “invalid request”), wherein the internal network communication element relays the response to the external network communication element (col. 23, lines 4-10: In twice network address port translation then, source and destination addresses within packet headers traveling in both directions, from the internal network to the external network, and also from the external network to the internal network, are translated and thus masked or hidden using network address port translation technology. In other words, the proxy is bidirectional mediator. Internal responses are forwarded to the external proxy component, which then forwards to the external client. This is a standard request/response flow of an application layer-proxy), and the external network communication element relays the response to the first network element (the external proxy always returns the internal host’s response to the external client. This is fundamental to proxy operation).
Regarding claim 8, Venkat teaches the computer-implemented method according to claim 1, wherein as a response to the transfer of the data by the first network element, the external network communication element sends a protocol-specific response packet to the first network element (col. 17, line 65 to col. 18, line 4: message is received, parsed/processed and a response to send back to the client. It is known in the art that when a request is sent to a proxy, the proxy acknowledges receipt using a protocol-specific response such as HTTP 100 continue, FTP 200 OK, or SMTP 250 OK, to name a few. These protocols have their own specific specifications. Therefore, Venkat implicitly teaches this feature).
Regarding claim 9, Venkat teaches the computer-implemented method according to claim 1, wherein the data include a connection request by the first network element via a defined port (col. 3, line 65 to col. 4, line 8: If a client computer system of the Internet receives a packet containing an address translated in this manner, the client computer system can return data in other packets to the originator of the packet containing the translated address (i.e., can return data to the specific web server computer system) by referencing the source address information within the packet header. Specifically, this source information, as explained above, contains the address of the router on the Internet along with a specific port number mapped, within the router, to the originating computer system (i.e., the web server) within the LAN.), wherein an indirect connection is established between the first network element and the second network element (since communication is mediated by the gateway, it implies that there is an indirect connection), and wherein the external network communication element and the internal network communication element relay data between the first network element and the second network element if the connection request was successful (figure 12: external proxy component receives data from the external client, internal proxy component forwards reconstructed messages to the internal host, the internal host responses being relayed back though the proxy chain. Data relaying occurs only after the proxy accepts the connection request).
Regarding claim 10, Venkat teaches the computer-implemented method according to claim 9, wherein the first network element and/or the second network element receive(s) a loss message concerning the loss of the connection if the connection is terminated or interrupted (this is a common behavior of TCP/IP and application-layers, therefore the teaching is implied).
Regarding claim 11, Venkat teaches the computer-implemented method according to claim 10, wherein the loss message includes a reason for the loss of the connection (when a connection is loss or terminated, standard protocols require the proxy to send an error message. The error message always includes status code, which is the reason for the loss. Therefore, this teaching is implied).
Regarding claim 12, Venkat teaches the computer-implemented method according to claim 1, wherein the second network element and the internal network communication element are virtual nodes on a shared system (figure 15: the gateway computer system 150 execute software components to facilitate communications. Therefore, virtual nodes are implied).
Regarding claim 13, Venkat teaches the computer-implemented method according to claim 12, wherein the second network element and the internal network communication element communicate locally with one another via a virtual Ethernet controller (figure 6: gateway 150 connects and exchanges the internal networks. Applicant-layer gateways routinely use virtual Ethernet controllers so this teaching is implied).
Regarding claim 14, Venkat teaches the computer-implemented method according to claim 1, wherein the first network element and the external network communication element are virtual nodes on a shared system (figure 6: gateway 150 connects and exchanges the external networks. Applicant-layer gateways routinely use virtual nodes so this teaching is implied).
Regarding claim 15, Venkat teaches a network system for data transfer (figure 1), the system comprising: an external network (figure 1: public/global/external network 101) comprising at least one first network element (figure 1: clients 110-114) and an external network communication element (figure 1: 150-1 gateway interface on both internal and external networks), the external network communication element being designed to monitor the external network (figure 1: gateway 150 inspects traffic as part of application layer processing.); and an internal network (figure 1: private/local/internal network 102) comprising at least one second network element (figure 1: servers 120-124) and an internal network communication element (figure 1: 150-1 gateway interface on both internal and external networks), the second network element being designed to communicate solely within the internal network (figure 1: communication is through gateway, therefore internal network is isolated, which implies that it communicates solely within internal network), the external network communication element and the internal network communication element being communicatively connected to one another via an IP communication channel (figure 1: clients 110-114 and servers 120-124 all have their respective IP addresses, therefore an IP communication channel is implied), wherein the external network communication element being further designed to process encoded data that are received from the first network element when a port specified in the encoded data is not operated by the external network communication element (the gateway processes data regardless of port, therefore this teaching is implied), and wherein the network system being further designed to carry out the method according to claim 1 (see rejection of claim 1 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Clark et al., US 20190132315 - network security software cooperatively configured on plural nodes to authenticate and authorize devices, applications, users, and data protocol in network communications by exchanging nonpublic identification codes, application identifiers, and data type identifiers via pre-established communication pathways.
Zhang et al., US 6490289 - Multiple simultaneous network connections from a single PPP connection may be accomplished by utilizing a gateway.
Kaluska et al., US 20110277001 - a gateway device that can execute applications which can communicate with various devices in one or more home networks as well as one or more wide area networks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/ Primary Examiner, Art Unit 2458