DETAILED ACTION
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 information disclosure statements (IDSs) submitted on 09/04/2024 and 01/22/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings submitted on March 8th, 2024 have been considered and accepted.
This office action is responsive to application filed on March 8th, 2024. In this office action:
Claims 21-40 are pending.
Claims 21-40 are rejected.
Claim Objections
Claims 21, 31, and 40 are objected to because of the following informality:
“... N is an integer greater than o” should read (Examiner’s suggestion) “... N is an integer greater than 0.”
Claim 25-27, 35 are objected to because of the following informality:
“... corresponding candidate destination” should read (Examiner’s suggestion) “... respective candidate destination.”
Claim 35 are objected to because of the following informality:
“...wherein the computing information comprises one or more of current load status information or network quality information of the corresponding candidate destination” should read (Examiner’s suggestion) “... wherein the computing information comprises one or more of current load status information or network quality information of a corresponding candidate destination.”
Appropriate correction(s) is/are required.
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 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.
Claims 21-22 and 30-40 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Thubert et al. (Patent No. US 7,328,237), hereinafter Thubert.
Claim 21. Thubert discloses [a] method, applied to a network device (“load balancing device 106,” See Fig. 1. See also Col. 10 lines 26-50 and Fig. 6), the method comprising:
receiving a first packet sent by a client (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client), wherein the first packet comprises target identification information, the target identification information identifies a target destination (See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), the target destination is selected from N candidate destinations by the network device for the client, and N is an integer greater than o (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
determining the target destination based on the target identification information, and forwarding the first packet to the target destination, to trigger the target destination to process the first packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling (to trigger the target destination to process the first packet)).
Claim 22. Thubert discloses [t]he method according to claim 21,
Thubert further discloses wherein determining the target destination based on the target identification information, and forwarding the first packet to the target destination comprises:
determining, based on a destination information table (“Connection Key Table”) and the target identification information, target routing information corresponding to the target destination, wherein the destination information table comprises a mapping relationship between identification information of the N candidate destinations and corresponding routing information (See Col. 8 lines 25-52 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc ...); and
forwarding the first packet to the target destination based on the target routing information (See Col. 8 lines 25-59 and Fig. 4; if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling).
Claim 30. Thubert discloses [t]he method according to claim 21,
Thubert further discloses wherein the target destination comprises one or more of a multi-access edge computing (MEC) site, a data center, a server, or a service instance (See Col. 8 lines 25-59 and Fig. 4; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster), and the network device comprises one or more of a user-side network gateway or a user ingress router (See Col. 9 lines 29-33; the load balancer may function as a common router in forwarding the packets from the client to their final destination).
Claim 31. Thubert discloses [a] network device (“load balancing device 106,” See Fig. 1. See also Col. 8 lines 1-11) comprising:
one or more memories storing instructions; and one or more processors coupled to the one or more memories and configured to execute the instructions, wherein execution of the instructions causes the network device (See Fig. 6 and Col. 10 lines 26-50) to:
receive a first packet sent by a client (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client), wherein the first packet comprises target identification information, the target identification information identifies a target destination (See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), the target destination is selected from N candidate destinations by the network device for the client, and N is an integer greater than o (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
determine the target destination based on the target identification information, and forwarding the first packet to the target destination, to trigger the target destination to process the first packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling (to trigger the target destination to process the first packet)).
Claim 32 is taught by Thubert as described for claim 22.
Claim 33. Thubert discloses [t]he network device according to claim 32,
Thubert further discloses wherein executing the instructions further causes the network device to:
receive a second packet sent by the client, wherein the second packet comprises a traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet; and select one of the N candidate destinations as the target destination based on the traffic identifier (See Col. 5 lines 35-57; although some of the source-side information described above may be included in subsequent HTTP requests from the client, it may be advantageous to embed selected source-side information into the destination IP address of earlier packets in order to allow the load balancer to select the most appropriate server for responding to subsequent client requests (a second packet sent by the client)).
Claim 34. Thubert discloses [t]he network device according to claim 33,
Thubert further discloses wherein executing the instructions further causes the network device to:
based on the selected target destination, obtain the target identification information, and add the target identification information to the second packet (See Col. 9 lines 12-16; the destination address of the forwarded packet may be modified by the load balancer, for example, when performing network address translation); and
send the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet (See Col. 5 lines 35-57; although some of the source-side information described above may be included in subsequent HTTP requests from the client, it may be advantageous to embed selected source-side information into the destination IP address of earlier packets in order to allow the load balancer to select the most appropriate server for responding to subsequent client requests (second packet)).
Claim 35. Thubert discloses [t]he network device according to claim 33,
Thubert further discloses wherein executing the instructions further causes the network device to:
search a computing routing table corresponding to the N candidate destinations, and obtain computing information of each of the N candidate destinations; and select one of the N candidate destinations as the target destination based on the computing information of each of the N candidate destinations (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table), wherein the computing information comprises one or more of current load status information or network quality information of the corresponding candidate destination (See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information).
Claim 36. Thubert discloses [t]he network device according to claim 35,
Thubert further discloses wherein executing the instructions further causes the network device to: receive a computing route sent by each of the N candidate destinations, wherein each computing route comprises the computing information and the routing information of the corresponding candidate destination; and generate the computing routing table, wherein the computing routing table comprises the computing information and the routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 37. Thubert discloses [t]he network device according to claim 36,
Thubert further discloses wherein executing the instructions further causes the network device to: generate the destination information table based on the identification information and the corresponding routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 38. Thubert discloses [t]he network device according to claim 36,
Thubert further discloses wherein executing the instructions further causes the network device to: generate identification information of each of the N candidate destinations according to a preset algorithm, and generate the destination information table based on the identification information and the corresponding routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 39. Thubert discloses [t]he network device according to claim 31,
Thubert further discloses wherein the target destination comprises one or more of a multi-access edge computing (MEC) site, a data center, a server, or a service instance (See Col. 8 lines 25-59 and Fig. 4; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster), and the network device comprises one or more of a user-side network gateway or a user ingress router (See Col. 9 lines 29-33; the load balancer may function as a common router in forwarding the packets from the client to their final destination).
Claim 40. Thubert discloses [a] client device comprising: one or more memories storing instructions; and one or more processors coupled to the one or more memories and configured to execute the instructions (See Fig. 1 “Client 102”), wherein execution of the instructions causes the client device to:
send a first packet to a network device (“load balancing device 106,” See Fig. 1. See also Col. 8 lines 1-11), wherein the first packet comprises target identification information, the target identification information identifies a target destination (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client ... See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), the target destination is selected from N candidate destinations by the network device for the client, and N is an integer greater than o (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
receive a first response packet sent by the target destination, wherein the first response packet is a response packet for the first packet (See Col. 8 lines 25-59 and Fig. 4; ... the received packet may be forwarded to the identified server for handling. See Col. 9 lines 55-59; servers within a server cluster to respond directly to the clients, if desired, without requiring that the responses be routed through the dispatcher or load balancer on the way back to the clients).
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.
Claims 23-29 are rejected under 35 U.S.C. 103 as being unpatentable over Thubert et al. (Patent No. US 7,328,237), hereinafter Thubert; in view of Kumar et al. (Pub. No. US 2016/0373520), hereinafter Kumar.
Claim 23. Thubert discloses [t]he method according to claim 22,
Thubert disclose the method further comprising: selecting one of the N candidate destinations for the client as the target destination based on the traffic identifier (See Col. 8 lines 12-59 and Fig. 4; the load balancer may also identify additional source-side information which has also been embedded in to other portions of the packet header such as, for example, the flow label field of the packet header ... A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table).
Thubert doesn’t explicitly disclose before receiving the first packet sent by the client, receiving a second packet sent by the client, wherein the second packet comprises a traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet.
However, Kumar discloses before receiving the first packet sent by the client, receiving a second packet sent by the client, wherein the second packet comprises a traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet (See Parag. [0007]; in response to receiving a first request (a second packet), generating a cookie identifying a first server of the computer system for responding to requests (first packet) from a first client and transmitting the cookie to the first client. The method also includes forwarding a second request received from the first client to the first server based on the cookie included in the second request. See Parag. [0035]; load balancer 114 identifies balancer 114 identifies which server 106 stores session data 116 for a particular communication based on a browser cookie stored at the client 104 ... See Also Parag. [0004] [0007]. Examiner’s interpretation: The Examiner reasonably interprets the second packet as a packet sent to establish a session first before sending subsequent requests, where the established session has an identifier).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the load balancer, taught by Thubert, to include before receiving the first packet sent by the client, receiving a second packet sent by the client, wherein the second packet comprises a traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet, as taught by Kumar. This would be convenient for transferring session data between servers (Kumar, Parag. [0017]).
Claim 24. Thubert in view of Kumar discloses [t]he method according to claim 23, further comprising:
Thubert doesn’t explicitly disclose based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet.
However, Kumar discloses:
based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet (See Parag. [0007]; in response to receiving a first request (a second packet), generating a cookie identifying a first server of the computer system for responding to requests from a first client and transmitting the cookie to the first client (response packet). The method also includes forwarding a second request received from the first client to the first server based on the cookie included in the second request ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the load balancer, taught by Thubert, to include based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet, as taught by Kumar. This would be convenient for transferring session data between servers (Kumar, Parag. [0017]).
Claim 25. Thubert in view of Kumar discloses [t]he method according to claim 23,
Thubert further discloses wherein selecting one of the N candidate destinations as the target destination based on the traffic identifier comprises:
searching a computing routing table corresponding to the N candidate destinations, and obtaining computing information of each of the N candidate destinations; and selecting one of the N candidate destinations as the target destination based on the computing information of each of the N candidate destinations (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table), wherein the computing information of each respective candidate destination comprises one or more of current load status information or network quality information of the corresponding candidate destination (See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information).
Claim 26. Thubert in view of Kumar discloses [t]he method according to claim 25,
Thubert discloses the method further comprising: receiving a computing route sent by each of the N candidate destinations, wherein each computing route comprises the computing information and the routing information of the corresponding candidate destination; and generating the computing routing table, wherein the computing routing table comprises the computing information and the routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 27. Thubert in view of Kumar discloses [t]he method according to claim 26,
Thubert further discloses wherein each respective computing information further comprises identification information of the corresponding candidate destination, and the method further comprises: generating the destination information table based on the identification information and the corresponding routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc.).
Claim 28. Thubert in view of Kumar discloses [t]he method according to claim 26, further comprising:
Thubert further discloses generating identification information of each of the N candidate destinations according to a preset algorithm, and generating the destination information table based on the identification information and the corresponding routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc.).
Claim 29. Thubert in view of Kumar discloses [t]he method according to claim 23, further comprising:
Thubert further discloses establishing a temporary session table, wherein the temporary session table comprises a mapping relationship between the traffic identifier of the client and the corresponding target routing information (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s note: The Examiner reasonably interprets the maintained local Connection Key Table by the load balancer as being temporary as the table is modified based on new data (See Col. 8 lines 60-67 and Col. 9 lines 1-15));
receiving a pseudo initial packet sent by the client, wherein the pseudo initial packet comprises the traffic identifier of the client (See Col. 5 lines 35-57; although some of the source-side information described above may be included in subsequent HTTP requests from the client, it may be advantageous to embed selected source-side information into the destination IP address of earlier packets in order to allow the load balancer to select the most appropriate server for responding to subsequent client requests);
determining, based on the traffic identifier in the pseudo initial packet and the temporary session table, the target routing information corresponding to the traffic identifier in the pseudo initial packet; and sending the pseudo initial packet to the target destination based on the target routing information, to trigger the target destination to process the pseudo initial packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zhang et al. (Pub. No. US 2021/0360714) – Related art in the area of an enhanced femtocell with an on-premise network slice controller and private MEC service, (Abstract; A device may include a memory storing instructions and processor configured to execute the instructions to receive a request for a connection from a user equipment (UE) device via cellular wireless signals and detect that the request identifies the connection as a private local data connection associated with a private network. The processor may be further configured to select a private application service network slice, from a plurality of network slices, for the connection, in response to detecting that the request identifies the connection as a private local data connection, and route packets associated with the connection to destination devices in the private network using wireless signals while preventing the packets associated with the connection from leaving the private network via a backhaul connection associated with the device.).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 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, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Abdelbasst Talioua/Examiner, Art Unit 2445