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/20/2026 has been entered. Claims 12, 14-15, 17, 20, 23, 27-28, and 30-31 are pending.
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.
Claims 12, 14, 17, 23, 27, and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (US 2023/0062452), hereinafter "Kim '452", in view of Kim et al. (US 2022/0191776), hereinafter “Kim ‘776”.
Regarding claims 12, 23, Kim ‘452 teaches:
A method performed by a User Equipment (UE) or a UE, comprising:
at least one processor (see Kim ‘452, par. [0051]: the case where the electronic device 50 is mounted with the edge computing service application may mean that the application installed in the electronic device 50 can be loaded on at least one processor to perform an operation for providing the edge computing service); and
a computer readable storage medium, the computer readable storage medium containing instructions which, when executed by the at least one processor, cause the UE (see Kim ‘452, par. [0052]: The edge enabler client 52 may be installed in the memory (not illustrated in the drawing) of the electronic device 50 mounted with the application for being provided with the edge computing service. Further, the edge enabler client 52 may mean that it is loaded on at least one processor instead of the installed application, and is able to perform at least some of operations that are required for the edge computing service application) to
transmit, to a first network function implementing application data management function in a data network, a first message, which is request, comprising UE information indicating a UE Internet Protocol (IP) address (see Kim ‘452, Fig. 3A, par. [0085]: The edge enabler client (EEC) 52 in the user equipment (UE) 50 may provide supportable CN type information to an edge enabler client server (EES) 100 in a registration procedure at operation 300. Accordingly, at operation 302, the EES 100 may check the supportable CN type information provided from the EEC 52. The EES 100 may perform operation 310 for selecting a wireless communication network interworking node that proceeds with operation 312, operation 314, or operation 316 in accordance with the test result at operation 302, and see par. [0086]: the edge enabler client 52 may include the CN type that is supportable by the UE 50 in a registration request message, and see par. [0090]: the core network type supportable by the UE 50 can be known based on the UE IP address (or source IP address of a packet received from the UE), or a public land mobile network (PLMN) ID being used by the UE 50, or a service set identifier (SSID). The above information can be known through the service provisioning procedure through the edge data network configuration server 30 or the registration procedure between the edge enabler server 100 and the edge enabler client 52 (the corresponding information may be provided by the UE or may be locally configured); in this case, as part of an operation for establishing network communication configuration, the UE transmits a request including a UE IP address);
wherein the first network function is implemented in an Edge Enabler Server (EES) (see Kim ‘452, Fig. 3A, par. [0085]: The edge enabler client (EEC) 52 in the user equipment (UE) 50 may provide supportable CN type information to an edge enabler client server (EES) 100 in a registration procedure at operation 300. Accordingly, at operation 302, the EES 100 may check the supportable CN type information provided from the EEC 52. The EES 100 may perform operation 310 for selecting a wireless communication network interworking node that proceeds with operation 312, operation 314, or operation 316 in accordance with the test result at operation 302), and wherein the static UE ID is an application specific external ID assigned by a third network function in the data network or in a mobile communication network (see Kim ‘452, Fig. 8, pars. [0187-0189]: At operation 802, the ECS 30 may obtain the type information of the UE, for example, the IMEI or the TAC, in interworking with the mobile communication network, for example, the 3GPP network 40, by utilizing the UE ID provided from the EEC 52 of the UE. The interworking method at operation 802 may use one of the following operations. First, the type information of the UE may be stored in, for example, a UE radio capability management function (UCMF) device that is one of network function (NF) devices of the 3GPP network 40. Accordingly, the ECS (30) may transfer the IMEI or the TAC obtained by using the ID of the UE obtained from the UE 50 to the UCMF of the 3GPP network 40 at operation 802a. Then, the UCMF of the 3GPP network 40 may obtain the UE type information of the corresponding UE by using the IMEI or the TAC of the UE 50. Accordingly, the UCMF of the 3GPP network 40 may transfer the IMEI or the TAC of the UE 50 to the ECS 30 together with the UE type information. As another example, the type information of the corresponding UE may be stored in at least one of an access and mobility function (AMF) device of the 3GPP network 40, a policy and charging function device, a unified data management (UDM) device, or a unified data repository (UDR). In this case, the ECS 30 may transfer the IMEI or TAC obtained by using the ID of the UE obtained from the UE 50 to any one of the above-described devices. Then, in the same method as described above, the corresponding network function device may obtain the UE type information of the corresponding UE by using the IMEI or the TAC of the UE 50. Accordingly, the corresponding function device of the 3GPP network 40 may transfer the IMEI or the TAC of the UE 50 to the ECS 30 together with the UE type information; in this case, identification and type information, such as IMEI (i.e. a static ID) may be received from a 3GPP network device (i.e. third network function)).
However, Kim ‘452 does not teach:
wherein the first message is a UE identifier (ID) Application Programming Interface (API) request;
receiving, from the first network function, a second message including a static UE identifier (ID) to be exposed,
Kim ‘776, in the same field of endeavor, teaches:
wherein the first message is a UE identifier Application Programming Interface (API) request (see Kim ‘776, Fig. 5, par. [0183]: the edge enabling layer 113 of the UE 110 may use the information as its own ID for the API request message transmitted to the edge management server 140 or the edge enabling server 210 in the future, and see par. [0188]: the UE 110 may perform a service on-boarding procedure in the edge enabling server 210 to transmit information on an application to be used for the MEC service by the UE in operation 512. According to an embodiment of the disclosure, the UE 110 may use the edge UE ID allocated as its own ID in operation 506 in the messages transmitted to the edge enabling server 210, and see par. [0189]: the edge enabling server 210 may bind the edge UE ID included in the request message transmitted by the UE 110 and the ID address of the UE 110 acquired in an IP packet transmitted by the UE 110 and store the information in the memory 214 in operation 514; in this case, the sections teach transmitting a service request as part of a process for an edge UE ID to be used in further communications (i.e. the message is a UE ID API request));
receiving, from the first network function, a second message including a static UE identifier (ID) to be exposed (see Kim ‘776, Fig. 5, par. [0190]: the edge enabling server 210 may generate a response message corresponding to the request message transmitted by the UE 110 in operation 512 and transmit the response message to the UE 110 in operation 516. According to an embodiment of the disclosure, when the UE 110 makes a request for service discovery, the edge enabling server 210 may transmit information on the edge application server 201 which can be used by the UE 110. According to an embodiment of the disclosure, information on the edge application servers may be configured in a list form, and may include at least one of IDs of applications which can be used by the UE 110, FQDNs for access to the corresponding application servers, IP addresses, or other information for identifying UEs; in this case, the response message including addresses to be used for further communications corresponds to the second message including a static UE ID to be exposed),
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 UE of Kim ‘452 with the UE ID API request and second message of Kim ‘776 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 maintaining security of UE identifiers (see Kim ‘776, par. [0019]).
Regarding claims 14, 27, the combination of Kim ‘452 in view of Kim ‘776 teaches the method or UE. Kim ‘452 further teaches:
further comprising:
transmitting, to a second network function, a third message including the static UE ID, for exposing the static UE ID (see Kim ‘452, Fig. 11, par. [0212]: At operation 1102, the message that is transmitted from the EEC 52 to the ECS 30 may be mapped onto the updated UE information, for example, the changed TAC or IMEI may be mapped onto the existing UE ID or EEC ID to be transmitted. The method for notifying the ECS 30 may utilize the service provisioning procedure. For example, whenever the UE type change is detected, the EEC 52 may request the EES information that coincides with the updated UE type by transmitting the service provisioning request message including the UE type information; in this case, IMEI may be transmitted as part of UE ID to an ECS (i.e. second network function)).
Regarding claims 17, 30, the combination of Kim ‘452 in view of Kim ‘776 teaches the method or UE. Kim ‘452 further teaches:
wherein the first and second messages are sent over an API specific for the first and second messages (see Kim ‘452, par. [0173]: The information that can be obtained through the 3GPP service API mentioned in the disclosure includes all UE related information that can be provided by the 3GPP system. For example, not only the UE location and UE identifier used in the 3GPP system but also information about the network function for servicing the UE, communication service quality (QoS) being provided to the UE, and information about the policy being applied to the UE may be provided to the edge computing service through the corresponding service API).
Claims 15 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Kim ‘452 in view of Kim ‘776, as applied to claims 12, 14, 17, 23, 27, and 30 above, and further in view of Yao et al. (US 2023/0188965), hereinafter “Yao”.
Regarding claims 15, 28, the combination of Kim ‘452 in view of Kim ‘776 teaches the method or UE. Kim ‘452 further teaches:
However, the combination of Kim ‘452 in view of Kim ‘776 does not teach:
wherein the UE IP address is assigned in a Packet Data Unit (PDU) session establishment process.
Yao, in the same field of endeavor, teaches:
wherein the UE IP address is assigned in a Packet Data Unit (PDU) session establishment process (see Yao, Fig. 6, pars. [0170-0171]: S601: A source AF obtains first information. The first information is location information of UE after a user plane path of a PDU session of the UE changes. The location information of the UE may be an IP address of the UE, a data network access identifier (data network access identifier, DNAI) corresponding to the user plane path of the PDU session of the UE, or identification information (for example, a cell ID, a RAN ID, a tracking area identity (tracking area ID, TAI), or geographical location information) of the UE in a network. It may be understood that the DNAI corresponding to the user plane path of the PDU session of the UE is a DNAI corresponding to a data network accessible by the UE. For example, the first information is an IP address that is obtained after the UE re-establishes the PDU session, or is an IP address that is of the UE).
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 IP address of the combination of Kim ‘452 in view of Kim ‘776 with the IP address being assigned in a PDU session establishment process of Yao 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 improving user experience by reducing delay and increasing bandwidth (see Yao, par. [0366]).
Claims 20 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Kim ‘452 in view of Kim ‘776, as applied to claims 12, 14, 17, 23, 27, and 30 above, and further in view of Wu et al. (US 2023/0232228), hereinafter “Wu”.
Regarding claims 20, 31, the combination of Kim ‘452 in view of Kim ‘776 teaches the method or UE. Kim ‘452 further teaches:
However, the combination of Kim ‘452 in view of Kim ‘776 does not teach:
wherein the first and second messages are sent over EDGE-1 reference point between an Edge Enabler Client (EEC) in the UE and the EES.
Wu, in the same field of endeavor, teaches:
wherein the first and second messages are sent over EDGE-1 reference point between an Edge Enabler Client (EEC) in the UE and the EES (see Wu, Fig. 1, par. [0074]: An edge enabler client (EEC) is a peer entity of the EES on the terminal device side. The EEC is configured to register EEC information and AC information with the EES, perform security authentication and authorization, obtain the identifier of the EAS from the EES).
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 communication of messages of the combination of Kim ‘452 in view of Kim ‘776 with the messages being sent over EDGE-1 reference point of Wu 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 reducing signaling overheads (see Wu, par. [0158]).
Response to Arguments
Applicant's arguments filed 04/20/2026 have been fully considered but they are not persuasive.
Applicant argues “Kim ‘452 fails to teach the UE transmitting a first message, which is a UE identifier Application Programming Interface (API) request” (see Applicant’s remarks, page 6).
Examiner respectfully disagrees and points to Kim ‘452 in Fig. 3A, par. [0085]: The edge enabler client (EEC) 52 in the user equipment (UE) 50 may provide supportable CN type information to an edge enabler client server (EES) 100 in a registration procedure at operation 300. Accordingly, at operation 302, the EES 100 may check the supportable CN type information provided from the EEC 52. The EES 100 may perform operation 310 for selecting a wireless communication network interworking node that proceeds with operation 312, operation 314, or operation 316 in accordance with the test result at operation 302, par. [0086]: the edge enabler client 52 may include the CN type that is supportable by the UE 50 in a registration request message, and par. [0090]: the core network type supportable by the UE 50 can be known based on the UE IP address (or source IP address of a packet received from the UE), or a public land mobile network (PLMN) ID being used by the UE 50, or a service set identifier (SSID). The above information can be known through the service provisioning procedure through the edge data network configuration server 30 or the registration procedure between the edge enabler server 100 and the edge enabler client 52 (the corresponding information may be provided by the UE or may be locally configured).
Examiner also points to Kim ‘776 in Fig. 5, par. [0183]: the edge enabling layer 113 of the UE 110 may use the information as its own ID for the API request message transmitted to the edge management server 140 or the edge enabling server 210 in the future, par. [0188]: the UE 110 may perform a service on-boarding procedure in the edge enabling server 210 to transmit information on an application to be used for the MEC service by the UE in operation 512. According to an embodiment of the disclosure, the UE 110 may use the edge UE ID allocated as its own ID in operation 506 in the messages transmitted to the edge enabling server 210, and par. [0189]: the edge enabling server 210 may bind the edge UE ID included in the request message transmitted by the UE 110 and the ID address of the UE 110 acquired in an IP packet transmitted by the UE 110 and store the information in the memory 214 in operation 514.
The sections of Kim ‘452 teach that, as part of an operation for establishing network communication configuration, the UE transmits a request including a UE IP address. The sections of Kim ‘776 teach transmitting a service request as part of a process for an edge UE ID to be used in further communications (i.e. the message is a UE ID API request). Taken in combination, the references teach the limitation under its broadest reasonable interpretation.
Applicant argues “there is no teaching in Kim ‘776 where the UE ID API request is to seek a static UE ID”.
Examiner respectfully disagrees and points to Kim ‘776 in Fig. 5, par. [0183]: the edge enabling layer 113 of the UE 110 may use the information as its own ID for the API request message transmitted to the edge management server 140 or the edge enabling server 210 in the future, par. [0188]: the UE 110 may perform a service discovery procedure in the edge enabling server 210 to receive information on an application by which the UE can use the MEC service. According to another embodiment of the disclosure, the UE 110 may perform a service on-boarding procedure in the edge enabling server 210 to transmit information on an application to be used for the MEC service by the UE in operation 512, and par. [0190]: the edge enabling server 210 may generate a response message corresponding to the request message transmitted by the UE 110 in operation 512 and transmit the response message to the UE 110 in operation 516. According to an embodiment of the disclosure, when the UE 110 makes a request for service discovery, the edge enabling server 210 may transmit information on the edge application server 201 which can be used by the UE 110. According to an embodiment of the disclosure, information on the edge application servers may be configured in a list form, and may include at least one of IDs of applications which can be used by the UE 110, FQDNs for access to the corresponding application servers, IP addresses, or other information for identifying UEs.
These sections teach the UE requesting service discovery through a registration including an API request and correspondingly receiving a response message including addresses to be used for further communications, corresponding to the second message including a static UE ID. Therefore, the registration and API request are used to further receive a static UE ID (i.e. the UE ID API request is to seek a static UE ID).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Guo et al. (US 2022/0303767) teaches a method for user equipment authentication and an authorization procedure for an edge data network.
Kim et al. (US 2022/0053602) teaches methods and an apparatus for providing an edge computing service to a UE in a mobile communication network.
Kunz et al. (US 2023/0388788) teaches apparatuses, methods, and systems for key-based authentication for a mobile edge computing network.
Zong et al. (WO 2022/100197) teaches a method and apparatus for obtaining an edge service by a user equipment (UE).
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