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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/22/2026 has been entered. Applicant’s submission overcomes prior claim objections to claim 15. Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 8, and 15 each recite the limitation “receiving by the first MME, a Transport Network Layer (TNL) discovery message, from the source base station, including an eNB ID of the target base station”. There is a background description of performing a TNL Discovery Procedure in the Applicant’s specification in pars. [0027] and [0035], but there is no indication of the first MME receiving a TNL discovery message from the source base station, including an eNB ID of the target base station, as claimed. Dependent claims 2-7 are rejected due to their dependency on independent claim 1. Dependent claims 9-14 are rejected due to their dependency on independent claim 8. Dependent claims 16-20 are rejected due to their dependency on independent claim 15.
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.
Claims 1-20 are 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.
Claims 1, 8, and 15 each recite the limitation “sending in response, by the first MME, an S10 base station configuration transfer message”. The use of the term “in response” renders the claims indefinite, as it is not immediately clear in response to what the first MME sends an S10 base station configuration transfer message. For the purposes of examination, the limitation is interpreted as sending, in response to receiving the TNL discovery message, by the first MME, an S10 base station configuration transfer message. Dependent claims 2-7 are rejected due to their dependency on independent claim 1. Dependent claims 9-14 are rejected due to their dependency on independent claim 8. Dependent claims 16-20 are rejected due to their dependency on independent claim 15.
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 (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 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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3, 5-6, 8, 10, 12-13, 15, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Rune et al. (WO 2009/120127), hereinafter “Rune”, in view of Hu et al. (US 2021/0212169), hereinafter “Hu”.
Regarding claims 1, 8, 15, Rune teaches:
A method for performing a user equipment (UE) handover from a source base station, coupled to a first mobility management entity (MME), to a target base station, coupled to a second MME (see Rune, Fig. 3, page 7, lines 10-12: Multiple eNBs controlling cells 19 are grouped into tracking areas (TAs) 38a - 38e each belonging to at least one MME Pool area 39a - 39c), or a non-transitory computer-readable medium containing instructions which, when executed on a processor at a first mobility management entity (MME) in a mobile network, cause the first MME to perform operations for a user equipment (UE) handover from a source base station, coupled to the first MME, to a target base station, coupled to a second MME (see Rune, Fig. 3, page 7, lines 10-12: Multiple eNBs controlling cells 19 are grouped into tracking areas (TAs) 38a - 38e each belonging to at least one MME Pool area 39a - 39c, and see page 19, lines 1-3: The MME 10 (which is a communication network node) is communicating with the RBS 15 via the interface 17 and optionally comprises a communication unit 94 configured to initially transmit handover messages over said first communication network interface 17), or a first mobility management entity (MME) for a user equipment (UE) handover from a source base station, coupled to the first MME, to a target base station, coupled to a second MME (see Rune, Fig. 3, page 7, lines 10-12: Multiple eNBs controlling cells 19 are grouped into tracking areas (TAs) 38a - 38e each belonging to at least one MME Pool area 39a - 39c, and see page 19, lines 1-3: The MME 10 (which is a communication network node) is communicating with the RBS 15 via the interface 17 and optionally comprises a communication unit 94 configured to initially transmit handover messages over said first communication network interface 17), comprising:
receiving by the first MME, a Transport Network Layer (TNL) discovery message, from the source base station, including an eNB ID of the target base station (see Rune, Figs. 4 and 5, page 11, lines 11-13: a handover decision is taken by the source eNB (step 500) and a HANDOVER REQUIRED message is sent to the source MME, shown with arrow 501, and see page 10, lines 21-23: a handover decision is taken by the source eNB (step 400) and a HANDOVER REQUIRED message is sent to the MME, shown with arrow 401 , including the CGI of the target cell; in this case, the source MME corresponds to a first MME, the handover required message corresponds to a TNL discovery message, and the CGI of the target cell corresponds to an ID of the target base station),
sending, in response, by the first MME, an S10 base station configuration transfer message, including the eNB ID of the target base station, on one or more S10 interfaces respectively connecting the first MME to one or more other MMEs including the second MME (see Rune, Fig. 5, page 11, lines 13-14: The source MME sends a FORWARD RELOCATION REQUEST message to the target MME, shown with arrow 502, and see page 12, lines 1-7: In the messages of the handover procedure in the direction from the source eNB to the target eNB (i.e. the HANDOVER REQUIRED, FORWARD RELOCATION REQUEST and HANDOVER REQUEST messages) the CGI (and its included parts) of the target/detected cell is included and is used as the basis for routing the messages to the correct target MME and target eNB and to indicate the concerned cell (i.e. the target cell) in the target eNB, and see page 13, lines 10-11: In an inter-MME pool scenario the serving MME forwards, in a new type of message, the information to the target MME over S10; in this case, the CGI of the target cell corresponds to an ID of the target base station); and
receiving, by the first MME, a message from the second MME including a transport layer address of the target base station (see Rune, Fig. 5, page 11, lines 27-32: The target MME looks up the target eNB IP address (step 509), or more accurately, a pointer to an SCTP socket and, forwards the CELL INFO REQUEST message, arrow 510 to the target eNB. The target eNB sends the requested cell information in a CELL INFO RESPONSE message back to the target MME, shown as arrow 511. The target MME sends the CELL INFO RESPONSE message to the source MME, arrow 512; in this case, the target eNB IP address corresponds to a transport layer address of the target base station),
However, Rune does not teach:
a memory; and
a processor, coupled to the memory, and configured to:
wherein an X2 connection is established between the source base station coupled to the first MME and the target base station coupled to the second MME based on receiving the transport layer address of the target base station by the first MME.
Hu, in the same field of endeavor, teaches:
a memory (see Hu, Fig. 6, par. [0139]: in FIG. 6, the core network device 70 may include a communications component 701, one or more processors 702, and a memory 703); and
a processor, coupled to the memory (see Hu, Fig. 6, par. [0139]: in FIG. 6, the core network device 70 may include a communications component 701, one or more processors 702, and a memory 703), and configured to:
wherein an X2 connection is established between the source base station coupled to the first MME and the target base station coupled to the second MME based on receiving the transport layer address of the target base station by the first MME (see Hu, Fig. 4, par. [0112]: Step S404: The second network device sends a second message to the core network device, where the second message includes the X2 TNL configuration information of the third network device; and the core network device receives the second message, and see par. [0097]: the X2 TNL configuration information may include a plurality of pieces of address information, for example, an X2 transport layer address, an Internet protocol (IP) secure transport layer address, a GPRS tunneling protocol transport layer address, and an indirect X2 transport layer address, and see par. [0115]: Step S405: The core network device sends the second message to the first network device, and the first network device receives the second message, and see par. [0119]: after receiving the second message, the first network device may further establish an X2 connection to the third network device. To be specific, after step S303 or step S405, the method may further include: establishing, by the first network device, the X2 connection to the third network device, and see par. [0114]: If the first network device is connected to the first core network device, the second network device is connected to the second core network device, and the first core network device and the second core network device are not a same core network device, the sending, by the second network device, a second message to the core network device is specifically: sending, by the second network device, a second message to the second core network device, and sending, by the second core network device, a second message to the first core network device; in this case, an X2 connection is established based on the core network device (i.e. MME) receiving TNL configuration information, including a transport layer address, of the third network device (i.e. of the target base station). The network devices (i.e. base stations) are connected to different core network devices (i.e. coupled to different MMEs)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or non-transitory computer-readable medium or first MME of Rune with the memory, processor, and X2 connection establishment of Hu with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of obtaining configuration information between network devices not connected to the same core network devices (see Hu, pars. [0073-0074]).
Regarding claims 3, 10, the combination of Rune in view of Hu teaches the method or non-transitory computer-readable medium. Rune further teaches:
wherein the first and second MMEs are Long Term Evolution (LTE) MMEs, and the target base station is an LTE eNodeB (see Rune, Fig. 3, page 7, lines 1-12: Figure 3 shows another view of the LTE communication network architecture comprising the EPC 10 an IP transport network 32 and the RAN 33. In the EPC 10, MMEs A - H are divided into MME Pools 31a - 31 c. The MME is e.g. responsible for idle mode UE tracking and paging procedure including retransmissions. In figure 3, the first MME Pool 31a comprises three MMEs A, B and C, the second MME Pool 31 b comprises two MMEs D and E and, the third MME Pool 31 c comprises three MMEs F, G and H. All MMEs A - H are controlled by a EPC operation and maintenance node 36. The MMEs are communicating over the S10 interface with each other. Each MME Pool 31a - 31c serves an MME Pool area 39a - 39c in the RAN 33. Multiple eNBs controlling cells 19 are grouped into tracking areas (TAs) 38a - 38e each belonging to at least one MME Pool area 39a - 39c).
Regarding claims 5, 12, 18, the combination of Rune in view of Hu teaches the method or non-transitory computer-readable medium or first MME. Rune further teaches:
wherein the transport layer address of the target base station is an Internet Protocol (IP) address (see Rune, page 13, line 28-page 14, line 2: After the message exchange the eNBs determine whether a neighbour relation should be established and what it should be used for and whether an X2 interface should be established. If the detecting eNB determines that an X2 interface should be established, it initiates the X2 establishment by directly (without going via an MME) contacting the detected eNB, using the IP address of the detected eNB received during the preceding information exchange. The detected eNB may reject the X2 establishment if desired. If the detecting eNB does not determine that an X2 interface is needed, the detected eNB may still choose to initiate the X2 establishment, which then may be accepted or rejected by the detecting eNB).
Regarding claims 6, 13, 19, the combination of Rune in view of Hu teaches the method or non-transitory computer-readable medium or first MME. Rune further teaches:
wherein the processor is further configured to cause a serving gateway (SGW) to complete a bearer context update for the UE reflecting that the UE has moved to the target base station (see Rune, Fig. 5, page 11, lines 16-24: The target MME has a CREATE BEARER REQUEST/RESPONSE communication with the target S-GW and then sends a HANDOVER REQUEST message to the target eNB, shown with arrow 504. The target eNB sends a HANDOVER REQUEST ACK message back to the target MME, shown with arrow 505. The target MME has a CREATE BEARER REQUEST/RESPONSE communication with the target S-GW and then sends a FORWARD RELOCATION RESPONSE to the source MME, shown with arrow 506. The source MME has a CREATE BEARER REQUEST/RESPONSE communication with the source S-GW. Then the rest of the handover procedure is performed; in this case, the bearer request and response corresponds to a bearer context update which is performed as part of the handover procedure indicating that the UE has moved to the target base station).
Claims 2, 4, 9, 11, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Rune in view of Hu, as applied to claims 1, 3, 5-6, 8, 10, 12-13, 15, and 18-19 above, and further in view of Das et al. (US 11,228,560), hereinafter “Das”, and further in view of Teyeb et al. (US 2014/0092866), hereinafter “Teyeb”.
Regarding claims 2, 9, 16, the combination of Rune in view of Hu teaches the method or non-transitory computer-readable medium or first MME.
However, the combination of Rune in view of Hu does not teach:
wherein: after the source base station sends an X2 interface handover request, including a Globally Unique MME Identifier (GUMMEI) information element (IE), to the target base station, the target base station sends a path switch request including the GUMMEI IE to the second MME; and
based on the GUMMEI IE, the second MME sends a context request message, including a first MME UE S1 Application Protocol (S1AP) identifier IE on the S10 interface to the first MME.
Das, in the same field of endeavor, teaches:
wherein: after the source base station sends an X2 interface handover request to the target base station (see Das, Fig. 12A, col. 21, lines 44-47: At (3) the source eNodeB function sends an X2 HO REQUEST message to the Target eNodeB function with Security and RAB (Radio Access Bearer) information of the UE 11014), the target base station sends a path switch request to the second MME (see Das, Fig. 12A, col. 22, lines 8-9: At (10) the Target eNodeB function sends an S1 Path Switch Request to a target MMF at the target AP 11008); and
based on the GUMMEI IE, the second MME sends a context request message, including a first MME UE S1 Application Protocol (S1AP) identifier IE on the S10 interface to the first MME (see Das, Fig. 12A, col. 22, lines 11-20: At (11a) Source MMF identification is performed where the Target MMF identifies the source MMF based on Globally Unique MME Identity (GUMMEI) to AP mapping. Specifically, the Target eNodeB uses the “source MME GUMMEI” in the S1 path switch request. The Target MMF needs to resolve the source AP MMF IP address from the GUMMEI to access it to perform UE context transfer. In order to do that, the Target AP MMF looks up the source MMF IP in the cloud ID and profile database service 11002, using the source GUMMEI as the key, and see col. 22, lines 26-29: Upon resolving the source AP MMF IP address, at (11b) the Target MMF sends a UE Context Request to the source MMF along with the source MMF allocated MME-UE-S1APID).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or non-transitory computer-readable medium or first MME of the combination of Rune in view of Hu with the X2 interface handover request, path switch request, and context request message of Das with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of performing handover where corresponding changes to devices in the network are achieved reliably (see Das, col. 20, line 61-col. 21, line 6).
However, the combination of Rune in view of Hu, and further in view of Das, does not teach:
wherein the X2 interface handover request includes a Globally Unique MME Identifier (GUMMEI) information element (IE),
wherein the path switch request includes the GUMMEI IE
Teyeb, in the same field of endeavor, teaches:
wherein the X2 interface handover request includes a Globally Unique MME Identifier (GUMMEI) information element (IE) (see Teyeb, Fig. 15, par. [0149]: the source eNB prepares the target eNB using the HANDOVER REQUEST message over X2, as shown in FIG. 15. The contents of this message are shown in Table 1, and see Table 1: GUMMEI),
wherein the path switch request includes the GUMMEI IE (see Teyeb, Fig. 15, par. [0155]: An example of how the PATH SWITCH REQUEST message IEs may be enhanced is shown in Table 1a, and see Table 1a: GUMMEI)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the X2 interface handover request and path switch request of the combination of Rune in view of Hu, and further in view of Das, with the requests including a GUMMEI IE of Teyeb with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of keeping all user equipment bearers ongoing (see Teyeb, par. [0007]).
Regarding claims 4, 11, 17, the combination of Rune in view of Hu, and further in view of Das, and further in view of Teyeb, teaches the method or non-transitory computer-readable medium or first MME.
The combination of Rune in view of Hu does not teach, but Das teaches:
wherein the processor is further configured to validate, by the first MME, the first MME UE S1AP ID and sending a context response message in which context details of the UE are published to the second MME (see Das, Fig. 12A, col. 22, lines 26-31: Upon resolving the source AP MMF IP address, at (11b) the Target MMF sends a UE Context Request to the source MMF along with the source MMF allocated MME-UE-S1APID. At (12) the Source MMF fetches UE context based on MME-UE-S1AP ID and sends it to the target MMF along with UE IP and MAC address).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or non-transitory computer-readable medium or first MME of the combination of Rune in view of Hu with the context response message of Das with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of performing handover where corresponding changes to devices in the network are achieved reliably (see Das, col. 20, line 61-col. 21, line 6).
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rune in view of Hu, as applied to claims 1, 3, 5-6, 8, 10, 12-13, 15, and 18-19 above, and further in view of Das.
Regarding claims 7, 14, 20, the combination of Rune in view of Hu teaches the method or non-transitory computer-readable medium or first MME.
However, the combination of Rune in view of Hu does not teach:
wherein the source base station performs data forwarding during a handover execution phase.
Das, in the same field of endeavor, teaches:
wherein the source base station performs data forwarding during a handover execution phase (see Das, Fig. 12A, col. 21, line 58-col. 22, line 7: At (6) the Source eNodeB function sends an SN (Sequence Number) STATUS TRANSFER message with Uplink and downlink data information to the target eNodeB function. For the uplink, at (7a) the UE 11014 sends uplink data to the target eNodeB function. At (7b) the target eNodeB function sends uplink data to the source OPF at the source AP 11006. At (7b) the Source OPF forwards uplink packets to a source OVS at the source AP 11006. For the downlink, at (8) the source OVS sends downlink data to the source OPF. At (8a) the source OPF sends the downlink data to the source eNodeB function. At (8b) the Source eNodeB function forwards the downlink data on X2 interface to the target eNodeB function. At (8c) the Target eNodeB function sends downlink data to the UE 11014. Then, at (9) the UE 11014 establishes radio connection with the target eNodeB function and sends RRC Reconfiguration complete to the target eNodeB function).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or non-transitory computer-readable medium or first MME of the combination of Rune in view of Hu with the data forwarding of Das with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of performing handover where corresponding changes to devices in the network are achieved reliably (see Das, col. 20, line 61-col. 21, line 6).
Response to Arguments
Applicant’s arguments with respect to claims 1, 8, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ostrup (US 2012/0252436) teaches a method in a Mobility Management Entity (10,11) for handling a setup of an S1 Application Protocol signaling connection between a first radio base station and the Mobility Management Entity (10,11) in a Long Term Evolution radio communications network.
Jung et al. (CN 103796261) teaches an optimizing method and device of one adjacent cell relation configuration, which is used for executing efficiency increase of inter-MME switching.
Xu et al. (CN 101600238) teaches a method and apparatus for optimizing neighbor cell relationship configuration.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CALEB J BALLOWE whose telephone number is (571)270-0410. The examiner can normally be reached MON-FRI 7:30-5.
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, Nishant B. Divecha can be reached at (571) 270-3125. 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.
/C.J.B./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights