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 .
Claim Objections
Claims 12, 15 are objected to because of the following reasons:
For claim 12, to improve clarity, Examiner recommends the removal of the letters “a.”, “i.”, “ii.” and “b.”.
For claim 15, the phrase “The system of…” is recommended to be amended to “The network system of…” to improve clarity, consistency and avoid possible antecedent basis issues.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 8, 12-15, 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Papa, US 20160044531.
For claim 1. Papa teaches: A method comprising:
establishing a communication between an AP (Access Point) and a core network component, by establishing a tunnel between an SNRN (S1/N2/N3 routing node) and an AP; (Papa, fig 2, paragraph 61-62, communication between eNodeB (access point) and MME (core network component) is established by establishing S1-Flex connection (tunnel) between concentrator node and eNodeB; concentrator node is an SNRN (S1/N2/N3 routing node) since it routes communication between eNodeB and MME via S1 connections)
and establishing a within-core-communication, via the SNRN to a core network component, (Papa, fig 2, paragraph 61-62, communication between concentrator node and MME is established by establishing S1-Flex connection between concentrator node and MME)
therein communicatively connecting a UE (User Equipment), via the AP and the SNRN, to the core network component. (Papa fig 2, paragraph 61-62, UE connects to MME via eNodeB and concentrator node; paragraph 60 discusses UE communicates with MME and vice versa)
For claim 2. Papa discloses all the limitations of claim 1, and Papa further teaches: wherein the SNRN supports S1/N2/N3 Flex connectivity. (Papa, fig 2, paragraph 61-62, concentrator node supports S1-Flex)
For claim 3. Papa discloses all the limitations of claim 1, and Papa further teaches: wherein the SNRN is implemented at an edge network. (Papa, paragraph 28, concentrator node is positioned between eNodeB and MMEs to solve problem at the edge of the network)
For claim 4. Papa discloses all the limitations of claim 1 and Papa further teaches: further comprises balancing, by the SNRN, a load, associated with communications with core network components, between the AP and one or more other APs. (Papa, paragraph 62, concentrator node prevent MMEs from becoming overloaded by processing and applying policies to messages received from eNodeBs)
For claim 8. Papa discloses all the limitations of claim 1, and Papa further teaches: wherein: the SNRN includes a router that forwards packets to an appropriate node in a DL (Download) direction and a UL (Upload) direction. (Papa, fig 2, paragraph 62, concentrator node forward messages received from eNodeB to MME; implicit that concentrator node also forward messages in the opposite direction since paragraph 60 mentions that MME handles mobility for all UEs attached to eNodeB and that MME try to service all UEs in a timely fashion)
For claim 12. Papa teaches: A network system comprising: a. network device, including i. a processor system having one or more processors and ii. a memory system; b. the memory system storing one or more machine instructions, which, when implemented by the processor system, cause the processor system to (Papa, fig 16, paragraph 142, 145 concentrator node with processor and memory storing instructions executed by processor)
establish multiple secure communications between UE (User Equipment) and a network core by establishing a tunnel between an SNRN (S1/N2/N3 Routing Node) and an AP (Access Point); (Papa, fig 2, paragraph 61-62, multiple communications between UE and MME (core network component) are established by establishing multiple S1-Flex connections (tunnels) between concentrator nodes and eNodeB (access point); concentrator node is an SNRN (S1/N2/N3 routing node) since it routes communication between eNodeB and MME via S1 connections; communications are secure since concentrator nodes act as a firewall)
and establishing within-core-communications, from the SNRN to multiple core network components, (Papa, fig 2, paragraph 61-62, communication between concentrator node and MMEs is established by establishing S1-Flex connections between concentrator node and MMEs)
therein communicatively connecting the UE, via the SNRN, to the multiple core network components. (Papa fig 2, paragraph 61-62, UE connects to MMEs via eNodeB and concentrator nodes; paragraph 60 discusses UE communicates with MME and vice versa)
For claim 13. Papa discloses all the limitations of claim 12, and Papa further teaches: wherein the SNRN supports S1/N2/N3 Flex connectivity. (Papa, fig 2, paragraph 61-62, concentrator node supports S1-Flex)
For claim 14. Papa discloses all the limitations of claim 12, and Papa further teaches: wherein the one or more instructions cause the processor system to implement the SNRN at an edge. (Papa, paragraph 28, concentrator node is positioned between eNodeB and MMEs to solve problem at the edge of the network)
For claim 15. Papa discloses all the limitations of claim 12, and Papa further teaches: the one or more instructions cause the processor system to perform load-balancing, by the SNRN, by balancing a communications load between the AP and one or more other APs. (Papa, paragraph 62, concentrator node prevent MMEs from becoming overloaded by processing and applying policies to messages received from eNodeBs)
For claim 19. Papa discloses all the limitations of claim 12, and Papa further teaches: wherein: the SNRN includes a router that forwards packets to an appropriate node in a DL (Download) direction and a UL (Upload) direction. (Papa, fig 2, paragraph 62, concentrator node forward messages received from eNodeB to MME; implicit that concentrator node also forward messages in the opposite direction since paragraph 60 mentions that MME handles mobility for all UEs attached to eNodeB and that MME try to service all UEs in a timely fashion)
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.
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 5, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Goel, US 20220095150.
For claim 5. Papa discloses all the limitations of claim 1 however Papa doesn’t teach: further comprising: detecting an issue with the core network component, and in response, redirecting a core-communication from the core network component to another core network component, therein preventing an outage of an AP as a result of a single-node failure.
Goel from the same or similar fields of endeavor teaches: detecting an issue with the core network component, and in response, redirecting a core-communication from the core network component to another core network component, therein preventing an outage of an AP as a result of a single-node failure. (Goel, fig 9, paragraph 82, when MME 1 goes down, load balancer reroutes connection request from RAN (access point) intended for MME 1 to MME i; paragraph 55-58, load balancer prevents connection failure between RAN and MME when one of MMEs goes down)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Goel into Papa, since Papa suggests a technique for routing communication from eNodeB (RAN) to MMEs, and Goel suggests the beneficial way of routing communication from RAN intended for a failed MME to another MME instead to provide the same level of service to RAN while not requiring RAN to reconfigure S1 connections (Goel, paragraph 55-58) in the analogous art of communication.
For claim 16. Papa discloses all the limitations of claim 12, however Papa doesn’t teach: the one or more instructions cause the processor system to: detect an issue with the core network component, and in response, redirect a core-communication from the core network component to another core network component, therein preventing an outage of an AP due to a single-node failure.
Goel from the same or similar fields of endeavor teaches: the one or more instructions cause the processor system to: detect an issue with the core network component, and in response, redirect a core-communication from the core network component to another core network component, therein preventing an outage of an AP due to a single-node failure. (Goel, fig 9, paragraph 82, when MME 1 goes down, load balancer reroutes connection request from RAN (access point) intended for MME 1 to MME i; paragraph 55-58, load balancer prevents connection failure between RAN and MME when one of MMEs goes down)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Goel into Papa, since Papa suggests a technique for routing communication from eNodeB (RAN) to MMEs, and Goel suggests the beneficial way of routing communication from RAN intended for a failed MME to another MME instead to provide the same level of service to RAN while not requiring RAN to reconfigure S1 connections (Goel, paragraph 55-58) in the analogous art of communication.
Claims 6, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Goel, US 20220095150 and Eswara, US 20110235505.
For claim 6. Papa and Goel disclose all the limitations of claim 5 however Papa doesn’t teach: further comprising: the other core network component storing a copy of a context of the UE before the detecting of the issue.
Eswara from the same or similar fields of endeavor teaches: the other core network component storing a copy of a context of the UE before the detecting of the issue. (Eswara, paragraph 9, improve S1-Flex architecture by deploying a standby MME to backup a pool of MMEs, the standy MME takes over the responsibility of any MME that has failed; paragraph 21, during normal operation, active MMEs send UEs contexts to standby (backup) MME; normal operation means before failing)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Eswara into Papa and Goel, since Papa suggests a technique for communications between eNodeBs and a pool of MMEs using S1-Flex architecture, and Eswara suggests the beneficial way of improving such S1-Flex architecture by deploying a standby MME to backup the pool of MMEs (by having active MMEs sending information such as UEs contexts to standby MME) so that the standy MME can takes over the responsibility of any MME that has failed with minimal impact to subscribers that were being served by the failed MME (Eswara, paragraph 9) in the analogous art of communication.
For claim 17. Papa and Eswara disclose all the limitations of claim 16, however Papa doesn’t teach: the other core network component storing a context of the UE, prior to detecting the issue.
Eswara from the same or similar fields of endeavor teaches: the other core network component storing a context of the UE, prior to detecting the issue. (Eswara, paragraph 9, improve S1-Flex architecture by deploying a standby MME to backup a pool of MMEs, the standy MME takes over the responsibility of any MME that has failed; paragraph 21, during normal operation, active MMEs send UEs contexts to standby (backup) MME; normal operation means before failing)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Eswara into Papa and Goel, since Papa suggests a technique for communications between eNodeBs and a pool of MMEs using S1-Flex architecture, and Eswara suggests the beneficial way of improving such S1-Flex architecture by deploying a standby MME to backup the pool of MMEs (by having active MMEs sending information such as UEs contexts to standby MME) so that the standy MME can takes over the responsibility of any MME that has failed with minimal impact to subscribers that were being served by the failed MME (Eswara, paragraph 9) in the analogous art of communication.
Claims 7, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Eswara, US 20110235505 and Goel, US 20220095150.
For claim 7. Papa discloses all the limitations of claim 1 however Papa doesn’t teach: further comprising: transferring at least some network operations to components of a public cloud by transferring a UE context from a core network component of a given type residing in a local area network to a core network component of the given type residing in the public cloud.
Eswara from the same or similar fields of endeavor teaches: transferring at least some network operations to components of a public cloud by transferring a UE context from a core network component of a given type residing in a local area network to a core network component of the given type residing in the public cloud. (Eswara, paragraph 9, improve S1-Flex architecture by deploying a standby MME to backup a pool of MMEs, the standy MME takes over the responsibility of any MME that has failed; paragraph 21, during normal operation, active MMEs send UEs contexts to standby (backup) MME; implicit that standby MME is located in the cloud since it’s well-known in the art that MME can be located in the cloud)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Eswara into Papa, since Papa suggests a technique for communications between eNodeBs and a pool of MMEs using S1-Flex architecture, and Eswara suggests the beneficial way of improving such S1-Flex architecture by deploying a standby MME to backup the pool of MMEs (by having active MMEs sending information such as UEs contexts to standby MME) so that the standy MME can takes over the responsibility of any MME that has failed with minimal impact to subscribers that were being served by the failed MME (Eswara, paragraph 9) in the analogous art of communication.
Even though, as discussed above, it’s well-known in the art that MME can be located in the cloud, Examiner understands Applicants might not know such fact, as thus as a show of good faith to compact prosecution, Examiner had provided prior art to teach it.
Goel from the same or similar fields of endeavor teaches: MME can be located in the cloud (Goel, paragraph 44-45, MMEs nodes in the cloud or on premise; paragraph 55-58, load balance MMEs)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Goel into Papa and Eswara, since Eswara suggests a technique for handling MMEs, and Goel suggests the beneficial way of having some of such MMEs located in the cloud since it’s well-known in the art for MMEs to located in the cloud or on premise (Goel, paragraph 44-45) thus doing so would ease implementation and improve compatibility in the analogous art of communication.
For claim 18. Papa discloses all the limitations of claim 12, however Papa doesn’t teach: the one or more instructions cause the processor system to transfer at least some network operations to components of a cloud by transferring a UE context from a core network component of a given type residing in a local area network to a core network component of the given type residing in a public cloud.
Eswara from the same or similar fields of endeavor teaches: the one or more instructions cause the processor system to transfer at least some network operations to components of a cloud by transferring a UE context from a core network component of a given type residing in a local area network to a core network component of the given type residing in a public cloud. (Eswara, paragraph 9, improve S1-Flex architecture by deploying a standby MME to backup a pool of MMEs, the standy MME takes over the responsibility of any MME that has failed; paragraph 21, during normal operation, active MMEs send UEs contexts to standby (backup) MME; implicit that standby MME is located in the cloud since it’s well-known in the art that MME can be located in the cloud)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Eswara into Papa, since Papa suggests a technique for communications between eNodeBs and a pool of MMEs using S1-Flex architecture, and Eswara suggests the beneficial way of improving such S1-Flex architecture by deploying a standby MME to backup the pool of MMEs (by having active MMEs sending information such as UEs contexts to standby MME) so that the standy MME can takes over the responsibility of any MME that has failed with minimal impact to subscribers that were being served by the failed MME (Eswara, paragraph 9) in the analogous art of communication.
Even though, as discussed above, it’s well-known in the art that MME can be located in the cloud, Examiner understands Applicants might not know such fact, as thus as a show of good faith to compact prosecution, Examiner had provided prior art to teach it.
Goel from the same or similar fields of endeavor teaches: MME can be located in the cloud (Goel, paragraph 44-45, MMEs nodes in the cloud or on premise; paragraph 55-58, load balance MMEs)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Goel into Papa and Eswara, since Eswara suggests a technique for handling MMEs, and Goel suggests the beneficial way of having some of such MMEs located in the cloud since it’s well-known in the art for MMEs to located in the cloud or on premise (Goel, paragraph 44-45) thus doing so would ease implementation and improve compatibility in the analogous art of communication.
Claims 9, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Kato, US 20230344780.
For claim 9. Papa discloses all the limitations of claim 1, and Papa further teaches: the router having a main memory; (Papa, fig 16, 142, 145 concentrator node with memory)
Papa doesn’t teach: wherein, the router reads a packet header of a packet, the packet header being read at a kernel level while avoiding bringing the packet into the main memory.
Kato from the same or similar fields of endeavor teaches: wherein, the router reads a packet header of a packet, the packet header being read at a kernel level while avoiding bringing the packet into the main memory. (Kato, paragraph 110, packet processing unit (implemented in a kernel thread) analyzes packet header to determine a destination user thread; while packet header is analyzed, packet is not brought into the main memory since packet processing unit only writes packet to memory after the header analyzing is done)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Kato into Papa, since Papa suggests a technique for receiving communication (packet), and Kata suggests the beneficial way of analyzing header of such packet at a kernel level to reduce delays (Kato, paragraph 24) in the analogous art of communication.
For claim 20. Papa discloses all the limitations of claim 12, and Papa further teaches: the SNRN being a router, (Papa, fig 2, paragraph 62, concentrator node forward (route) messages received from eNodeB to MME)
Papa doesn’t teach: the one or more instructions, when implemented, cause the router to read a packet header at a kernel level while avoiding bringing the packet into the main memory.
Kato from the same or similar fields of endeavor teaches: the one or more instructions, when implemented, cause the router to read a packet header at a kernel level while avoiding bringing the packet into the main memory. (Kato, paragraph 110, packet processing unit (implemented in a kernel thread) analyzes packet header to determine a destination user thread; while packet header is analyzed, packet is not brought into the main memory since packet processing unit only writes packet to memory after the header analyzing is done)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Kato into Papa, since Papa suggests a technique for receiving communication (packet), and Kata suggests the beneficial way of analyzing header of such packet at a kernel level to reduce delays (Kato, paragraph 24) in the analogous art of communication.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Baliarsingh, US 20220330054.
For claim 10. Papa discloses all the limitations of claim 1 however Papa doesn’t teach: further comprising: registering an AMF (Access Mobility Management Function) with an NRF (Network Repository Function).
Baliarsingh from the same or similar fields of endeavor teaches: further comprising: registering an AMF (Access Mobility Management Function) with an NRF (Network Repository Function). (Baliarsingh, paragraph 57, each AMF of plurality of AMFs registers to the NRF)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Baliarsingh into Papa, since Papa suggests a technique for managing MMEs (AMFs), and Baliarsingh suggests the beneficial way of registering such AMFs with an NRF so that the AMFs can be notified of the status of other AMFs by the NRF (Baliarsingh, paragraph 57) in the analogous art of communication.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Papa, US 20160044531 in view of Lee, US 20180324646.
For claim 11. Papa discloses all the limitations of claim 1 however Papa doesn’t teach: further comprising: the SNRN choosing between establishing communications with an (I-UPF (Intermediate-User Plane Function) and with an A-UPF (Anchor UPF).
Lee from the same or similar fields of endeavor teaches: further comprising: the SNRN choosing between establishing communications with an (I-UPF (Intermediate-User Plane Function) and with an A-UPF (Anchor UPF). (Lee, paragraph 21, network entity selects intermediate UPF if anchor UPF does not support the terminal, and establish a session with the intermediate UPF)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Lee into Papa, since Papa suggests a technique for servicing (supporting) UE (terminal), and Lee suggests the beneficial way of selecting intermediate UPF if anchor UPF does not support the terminal, and establish a session with the intermediate UPF so that the terminal can be supported by an UPF (Lee, paragraph 21) in the analogous art of communication.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHOA B HUYNH whose telephone number is (571)270-7185. The examiner can normally be reached Monday - Friday 1:00 PM - 9:35 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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/KHOA HUYNH/Primary Examiner, Art Unit 2462