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 .
Response to Arguments
Applicants’ arguments with respect to claim(s) 1 have been considered but are moot based on the new grounds of rejection necessitated by applicant’s amendments.
Claim Rejections - 35 USC § 102
3. 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.
4. 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)(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.
5. Claim(s) 1, 2, 4-6, 8-14, 29, 34-35, and 37-38 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated US 2024/0396796 A1 by Kahn et al. (hereafter referred to as Kahn).
Regarding claim 1, Kahn teaches a method for handover (see at least ¶ [0063]; handover), comprising:
determining, by a source data collection coordination function (DCCF), based on position information of one or more user equipment (UE), that the one or more UE move out of a serving region of the source DCCF (see at least Fig. 3 and ¶ [0106]; “In more detail, in step 1, the AMF 330 sends a mobility notification to the DCCF-1 120 indicating that a UE is in a new area of interest (AOI). In step 2, the DCCF-1 120 determines that the UE is no longer in the area served by the DCCF-1 120.”);
selecting or discovering, by the source DCCF, a target DCCF corresponding to each of the one or more UE based on position information of the UE through a center DCCF or a coordinating DCCF (see at least ¶ [0106]; “In step 3, the DCCF-1 120 queries the NRF 340 to discover a DCCF that can serve the UE in the UE's new location. In step 4, the DCCF-1 120 determines/selects the DCCF-2 310, which serves the area where the UE now resides.”); and
deciding, by the source DCCF, to transfer or transmit a data, to transfer or transmit a data subscription or data request of each of the one or more UE to the target DCCF corresponding to the UE (see at least ¶ [0107]; “Further, in step 5, the DCCF-1 120 requests a transfer of the DCCF UE context to the DCCF-2 310. Such request may already contain the DCCF UE context, which is to be transferred. Alternatively, the DCCF UE context may be transferred separated from such request, e.g. after the request has been issued to the DCCF-2 310. In addition, such separate transfer of the DCCF UE context may be performed in response to the DCCF-1 120 receiving an acceptance notification, e.g. from the DCCF-2 310, or may be performed after elapse of a predetermined time period from issuing the transfer request. The DCCF-2 310 accepts the transfer request. If a MFAF is not used (MFAF-1 210 is not used) and the DCCF-2 310 provides DCCF-2 Notification Endpoint information comprising a (notification URI) and, optionally, notification correlation Id, in the response to the DCCF-1 120.”).
Regarding claim 2, Kahn teaches the method of claim 1. In addition, Kahn teaches the method further comprising: for each of the one or more UE, sending, by the source DCCF to a network repository function (NRF), a bootstrapping server function (BSF), or unified data management (UDM), a first message for selecting or discovering the target DCCF corresponding to the UE, wherein the first message comprises a first parameter, and the first parameter at least comprises at least one of following:
the position information of the UE, an identifier of the UE, single- network slice selection assistance information (S-NSSAI), a network function (NF) type, a NF set identifier, a network data analysis function (NWDAF) identifier, an analysis identifier, or an NF instance identifier; and receiving, by the source DCCF, a second message from a the NRF, BSF or UDM, wherein the second message comprises a second parameter, and the second parameter at least comprises at least one of following:
an NF identifier, or the NF set identifier (see at least Fig. 3 and ¶ [0063], [0157]; NWDAF).
Regarding claim 4, Kahn teaches the method of claim 1. In addition, Kahn teaches wherein for each of the one or more UE, transferring or transmitting, by the source DCCF, the data subscription or data request of the corresponding UE to the target DCCF corresponding to the UE comprises:
for each of the one or more UE, sending, by the source DCCF, a third message to the target DCCF entity corresponding to the UE, wherein the third message is used for transferring or transmitting a data subscription or data request of the UE from a network consumer, and the third message comprises relevant information of the data subscription or data request of the corresponding UE (see at least ¶ [0107]; “Further, in step 5, the DCCF-1 120 requests a transfer of the DCCF UE context to the DCCF-2 310. Such request may already contain the DCCF UE context, which is to be transferred. Alternatively, the DCCF UE context may be transferred separated from such request, e.g. after the request has been issued to the DCCF-2 310. In addition, such separate transfer of the DCCF UE context may be performed in response to the DCCF-1 120 receiving an acceptance notification, e.g. from the DCCF-2 310, or may be performed after elapse of a predetermined time period from issuing the transfer request. The DCCF-2 310 accepts the transfer request. If a MFAF is not used (MFAF-1 210 is not used) and the DCCF-2 310 provides DCCF-2 Notification Endpoint information comprising a (notification URI) and, optionally, notification correlation Id, in the response to the DCCF-1 120.”).
Regarding claim 5, Kahn teaches the method of claim 1. In addition, Kahn teaches the method further comprising: for each of the one or more UE, receiving, by the source DCCF, a fourth message from a network consumer, wherein the fourth message is used for subscribing or requesting data of the UE, the fourth message comprises a third parameter, and the third parameter at least comprises at least one of following: an identifier of the UE, an S-NSSAI, an NF type, an NF set identifier, an NWDAF identifier, an analysis identifier, or an NF instance identifier; or receiving, by the source DCCF, a fifth message from the network consumer through a center DCCF or coordinating DCCF, wherein the fifth message is used for subscribing or requesting the data of the UE, and the fifth message at least comprises the third parameter (see at least Fig. 3 and ¶ [0063], [0157]; NWDAF).
Regarding claim 6, Kahn teaches the method of claim 5. In addition, Kahn teaches the method further comprising: for each of the one or more UE, sending, by the source DCCF, a sixth message to the network consumer or the center DCCF or coordinating DCCF, wherein the sixth message is used for notifying that the data subscription or data request of the UE is transferred or transmitted successfully, and the sixth message comprises a first subscription identifier related to the source DCCF (see at least ¶ [0110]; “In step 8, if the MFAF is used (i.e. if the MFAF-1 210 is used), the DCCF-1 120 (or alternatively the DCCF-2 310) informs the MFAF-1 210 that the DCCF-2 310 will be coordinating data gathered for the UE. Otherwise (i.e. MFAF is not used), this step is skipped.”).
Regarding claim 8, Kahn teaches the method of claim 5. In addition, Kahn teaches the method further comprising: for each of the one or more UE, deciding or discovering, by the source DCCF, a data source through a NRF, BSF or UDM, and collecting or subscribing the data of the UE from the data source, wherein the data source supports providing the data of the UE (see at least Figs. 3-5).
Regarding claim 9, Kahn teaches the method of claim 8. In addition, Kahn teaches wherein deciding or discovering, by the source DCCF, the data source through the NRF, BSF or UDM comprises:
sending, by the source DCCF, an eighth message for deciding or discovering the data source to the NRF, BSF or UDM, wherein the eighth message comprises the third parameter; and receiving, by the source DCCF, a ninth message from the NRF, BSF or UDM, wherein the ninth message at least comprises a fourth parameter, and the fourth parameter at least comprises at least one of following: an NF identifier, or the NF set identifier (see at least Figs. 3-5).
Regarding claim 10, Kahn teaches the method of claim 8. In addition, Kahn teaches wherein collecting or subscribing the data of the UE from the data source comprises: for each of the one or more UE, sending, by the source DCCF, a tenth message to the data source, wherein the tenth message is used for collecting or subscribing the data of the UE, and the tenth message at least comprises the third parameter (see at least Figs. 3-5 and ¶ [0111]; “In step 9, the Consumer 110 is informed by the DCCF-1 120 (or alternatively by the DCCF-2 310) that the subscription to the DCCF-1 120 is now being handled by the DCCF-2 310.”).
Regarding claim 11, Kahn teaches the method of claim 1. In addition, Kahn teaches the method further comprising: for each of the one or more UE, deciding or subscribing, by the first network function entity, the position information of the UE through a seventh network function entity (see at least Figs. 3-5).
Regarding claim 12, Kahn teaches a method for handover (see at least ¶ [0063]; handover), comprising:
for each of one or more user equipment (UE), receiving, by a target data collection coordination function (DCCF), a data subscription or data request from a source DCCF, a center DCCF or coordinating DCCF or a network consumer, wherein the data subscription or data request is used for transferring or transmitting a data subscription or data request of the UE (see at least Fig. 3 and ¶ [0106]; “In step 3, the DCCF-1 120 queries the NRF 340 to discover a DCCF that can serve the UE in the UE's new location. In step 4, the DCCF-1 120 determines/selects the DCCF-2 310, which serves the area where the UE now resides.”); and
deciding or discovering, by the target DCCF, a data source through a network repository function (NRF), a bootstrapping server function (BSF), or unified data management (UDM), and subscribing or requesting data of the UE from the data source, wherein the data source supports providing the data of the UE (see at least ¶ [0106]; “In step 3, the DCCF-1 120 queries the NRF 340 to discover a DCCF that can serve the UE in the UE's new location. In step 4, the DCCF-1 120 determines/selects the DCCF-2 310, which serves the area where the UE now resides.” and at least ¶ [0107]; “Further, in step 5, the DCCF-1 120 requests a transfer of the DCCF UE context to the DCCF-2 310. Such request may already contain the DCCF UE context, which is to be transferred. Alternatively, the DCCF UE context may be transferred separated from such request, e.g. after the request has been issued to the DCCF-2 310. In addition, such separate transfer of the DCCF UE context may be performed in response to the DCCF-1 120 receiving an acceptance notification, e.g. from the DCCF-2 310, or may be performed after elapse of a predetermined time period from issuing the transfer request. The DCCF-2 310 accepts the transfer request. If a MFAF is not used (MFAF-1 210 is not used) and the DCCF-2 310 provides DCCF-2 Notification Endpoint information comprising a (notification URI) and, optionally, notification correlation Id, in the response to the DCCF-1 120.”).
Regarding claim 13, Kahn teaches the method of claim 12. In addition, Kahn teaches the method further comprising: for each of the one or more UE, sending, by the target DCCF, an eleventh message to the network consumer or the center DCCF or coordinating DCCF, wherein the eleventh message is used for notifying that the data subscription or data request of the UE is transferred or transmitted successfully, and the eleventh message comprises a second subscription identifier related to the target DCCF (see at least ¶ [0110]; “In step 8, if the MFAF is used (i.e. if the MFAF-1 210 is used), the DCCF-1 120 (or alternatively the DCCF-2 310) informs the MFAF-1 210 that the DCCF-2 310 will be coordinating data gathered for the UE. Otherwise (i.e. MFAF is not used), this step is skipped.”).
Regarding claim 14, Kahn teaches the method of claim 12. In addition, Kahn teaches wherein receiving, by the target DCCF, the data subscription or data request from the source DCCF, the center DCCF or coordinating DCCF or the network consumer comprises: for each of the one or more UE, receiving, by the target DCCF, a third message from the source DCCF, wherein the third message is used for transferring or transmitting the data subscription or data request of the UE from a network consumer, and the third message comprises relevant information of the data subscription or data request of the UE; or receiving, by the target DCCF, a fourteenth message from the center DCCF or coordinating DCCF or the network consumer, wherein the fourteenth message is used for transferring or transmitting the data subscription or data request of the UE from the network consumer, and the fourteenth message comprises relevant information of the data subscription or data request of the corresponding UE (see at least Figs. 3-5).
Regarding claim 29, Kahn teaches a source data collection coordination function (DCCF) comprising a memory, a processor, and a computer program that is stored in the memory and is capable of being run on the processor, wherein the processor, when executing the computer program, is configured to: determine, by a source data collection coordination function (DCCF), based on position information of one or more user equipment (UE), that the one or more UE move out of a serving region of the source DCCF (see at least Fig. 3 and ¶ [0106]; “In more detail, in step 1, the AMF 330 sends a mobility notification to the DCCF-1 120 indicating that a UE is in a new area of interest (AOI). In step 2, the DCCF-1 120 determines that the UE is no longer in the area served by the DCCF-1 120.”);
select or discover, by the source DCCF, a target DCCF corresponding to each of the one or more UE based on position information of the UE through a center DCCF or a coordinating DCCF (see at least ¶ [0106]; “In step 3, the DCCF-1 120 queries the NRF 340 to discover a DCCF that can serve the UE in the UE's new location. In step 4, the DCCF-1 120 determines/selects the DCCF-2 310, which serves the area where the UE now resides.”); and
decide, by the source DCCF, to transfer or transmit a data, to transfer or transmit a data subscription or data request of each of the one or more UE to the target DCCF corresponding to the UE (see at least ¶ [0107]; “Further, in step 5, the DCCF-1 120 requests a transfer of the DCCF UE context to the DCCF-2 310. Such request may already contain the DCCF UE context, which is to be transferred. Alternatively, the DCCF UE context may be transferred separated from such request, e.g. after the request has been issued to the DCCF-2 310. In addition, such separate transfer of the DCCF UE context may be performed in response to the DCCF-1 120 receiving an acceptance notification, e.g. from the DCCF-2 310, or may be performed after elapse of a predetermined time period from issuing the transfer request. The DCCF-2 310 accepts the transfer request. If a MFAF is not used (MFAF-1 210 is not used) and the DCCF-2 310 provides DCCF-2 Notification Endpoint information comprising a (notification URI) and, optionally, notification correlation Id, in the response to the DCCF-1 120.”).
Regarding claim 34, Kahn teaches a target data collection coordination function (DCCF) comprising a memory, a processor, and a computer program that is stored in the memory (see at least Fig. 10) and is capable of being run on the processor, wherein the processor executes the computer program to implement the steps of the method of claim 12 (see rejection of claim 12 above).
Regarding claim 35, Kahn teaches the source DCCF of claim 29. In addition, Kahn teaches wherein the processor is further configured to: for each of the one or more UE, send to a network repository function (NRF), a bootstrapping server function (BSF), or unified data management (UDM), a first message for selecting or discovering the target DCCF corresponding to the UE, wherein the first message comprises a first parameter, and the first parameter at least comprises at least one of following: the position information of the UE, an identifier of the UE, single-network slice selection assistance information (S-NSSAI), a network function (NF) type, a NF set identifier, a network data analysis function (NWDAF) identifier, an analysis identifier, or an NF instance identifier; and receive a second message from a NRF, BSF or UDM, wherein the second message comprises a second parameter, and the second parameter at least comprises at least one of following: an NF identifier, or the NF set identifier (see at least Fig. 3 and ¶ [0063], [0157]; NWDAF).
Regarding claim 37, Kahn teaches the source DCCF of claim 29. In addition, Kahn teaches wherein for each of the one or more UE, in order to transfer or transmit the data subscription or data request of the corresponding UE to the target DCCF corresponding to the UE, the processor is configured to: for each of the one or more UE, send a third message to the target DCCF corresponding to the UE, wherein the third message is used for transferring or transmitting a data subscription or data request of the UE from a network consumer, and the third message comprises relevant information of the data subscription or data request of the corresponding UE (see at least ¶ [0107]; “Further, in step 5, the DCCF-1 120 requests a transfer of the DCCF UE context to the DCCF-2 310. Such request may already contain the DCCF UE context, which is to be transferred. Alternatively, the DCCF UE context may be transferred separated from such request, e.g. after the request has been issued to the DCCF-2 310. In addition, such separate transfer of the DCCF UE context may be performed in response to the DCCF-1 120 receiving an acceptance notification, e.g. from the DCCF-2 310, or may be performed after elapse of a predetermined time period from issuing the transfer request. The DCCF-2 310 accepts the transfer request. If a MFAF is not used (MFAF-1 210 is not used) and the DCCF-2 310 provides DCCF-2 Notification Endpoint information comprising a (notification URI) and, optionally, notification correlation Id, in the response to the DCCF-1 120.”).
Regarding claim 38, Kahn teaches the source DCCF of claim 29. In addition, Kahn further teaches wherein the processor is further configured to: for each of the one or more UE, receive a fourth message from a network consumer, wherein the fourth message is used for subscribing or requesting data of the UE, the fourth message comprises a third parameter, and a third parameter at least comprises at least one of following: an identifier of the UE, an S-NSSAI, an NF type, an NF set identifier, an NWDAF identifier, an analysis identifier, or an NF instance identifier; or receive a fifth message from the network consumer through a center DCCF or coordinating DCCF, wherein the fifth message is used for subscribing or requesting the data of the UE, and the fifth message at least comprises the third parameter (see at least Fig. 3 and ¶ [0063], [0157]; NWDAF).
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. 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 non-obviousness.
9. Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kahn as applied to claim 6 above, in view of "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support network data analytics services (Release 17)", 3GPP STANDARD; 3GPP TS 23.288, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE no. V17.2.0 24 September 2021 (2021-09-24), pages 1-196, XP052056721 (provided by applicant, hereafter referred to as 3GPP).
Regarding claim 7, Kahn teaches the method of claim 6.
Kahn does not appear to specifically disclose the method further comprising: for each of the one or more UE, sending, by the source DCCF, a seventh message for unsubscription to a data source, wherein the data source supports providing the data of the UE.
In the same field of endeavor, 3GPP teaches the method further comprising: for each of the one or more UE, sending, by the source DCCF, a seventh message for unsubscription to a data source, wherein the data source supports providing the data of the UE (see in particular step 10 in figure 6.1B.2.2-1 and lines 48 to 50 on pages 44: "Source NWDAF unsubscribes with the data source (s) that are no longer needed for the remaining)
It would have been obvious to one having ordinary skill in the art before the effective filing date to modify Kahn with 3GPP in order to improve the standard.
Conclusion
10. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to NATASHA W COSME whose telephone number is (571)270-7225. The examiner can normally be reached M-F 7:30-4. 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, Ayman Abaza can be reached at 571-270-0422. 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.
/NATASHA W COSME/Primary Examiner, Art Unit 2465
Prosecution Insights