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 .
This Office Action is a response to communications dated 03/21/2024. Claims 1-20 are pending in the application.
Claim Objections
Claim 11 is objected to because of the following informalities: As per claim 11, line 5, “model data a service identifier” should be changed to --model data and a service identifier--. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/937,706 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because of the below rationales.
Instant Application Claim 1 Claims
‘392 Application Claim 2 Claims
A communication method, comprising:
A method of:
transmitting, by a terminal device, a first message to a network device; wherein the first message is configured to request downloading at least one type of model data;
wherein the first message comprises at least one of a model identifier corresponding to the at least one type of model data and a service identifier corresponding to the at least one type of model data.
transmitting a first message to a second device, wherein the first message is used to request downloading application model data ,
wherein the first message comprises at least one of model identifier information corresponding to at least one application model model data size indication information corresponding to at least one application model
Rationales:
From the above claim comparison, one can see that claim 2 of the ‘522 application anticipates all recitations of claim 1 of the instant application. Alternatively, claim 1 of the instant application claims variously and essentially similar limitations as those recited in claim 2 of the ‘522 application. There are differences between the claims depicted in the strike-through words and the bolded words. The differences are deemed obvious for the following rationales. Pertaining the difference depicted in the strike-through words, it appears to be broadening claim by omitting limitations. Nevertheless, it has been held that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184(CCPA). Also note Ex Parte Rainu, 168 USPQ 375 (Bd. App. 1969); omission of a reference whose function is not needed would be an obvious variation. Moreover, and pertaining the difference depicted in the bolded words, it appears to be using different wording but meaning is the same or similar. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims appear to be using different wording but meaning is the same or similar, and it would be obvious to one of ordinary skilled in the art to modify the claim limitations to incorporate certain variation of the elements in using different wording but meaning is the same or similar. A motivation for doing so would be to seek a well-rounded protection for a disclose invention.
The dependent claims 2-10 are included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Specifically, the claims are deemed obvious over dependent claims 2-9 of '522 application for the same rationale as applied to their parent claim as above discussed.
Instant Application Claim 11 Claims
‘522 Application Claim 11 Claims
A communication method, comprising:
A method of:
receiving, by a network device, a first message transmitted by a terminal device;
wherein the first message is configured to request downloading at least one type of model data;
wherein the first message comprises at least one of a model identifier corresponding to the at least one type of model data a service identifier corresponding to the at least one type of model data.
receiving a first message from a first device,
wherein the first message is used to request downloading application model data wherein the second device is further configured to: transmit the first device, a control message comprising the application model data, wherein the control message comprises at least one of model identifier information corresponding to a first application model ; a sequence number of the application model data in the first application model.
Rationales:
From the above claim comparison, one can see that claim 11 of the ‘522 application anticipates all recitations of claim 11 of the instant application. Alternatively, claim 11 of the instant application claims variously and essentially similar limitations as those recited in claim 11 of the ‘522 application. There are differences between the claims depicted in the strike-through words and the bolded words. The differences are deemed obvious for the following rationales. Pertaining the difference depicted in the strike-through words, it appears to be broadening claim by omitting limitations. Nevertheless, it has been held that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184(CCPA). Also note Ex Parte Rainu, 168 USPQ 375 (Bd. App. 1969); omission of a reference whose function is not needed would be an obvious variation. Moreover, and pertaining the difference depicted in the bolded words, it appears to be using different wording but meaning is the same or similar. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims appear to be using different wording but meaning is the same or similar, and it would be obvious to one of ordinary skilled in the art to modify the claim limitations to incorporate certain variation of the elements in using different wording but meaning is the same or similar. A motivation for doing so would be to seek a well-rounded protection for a disclose invention.
The dependent claims 12-17 are included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Specifically, the claims are deemed obvious over dependent claims 12-17 of '522 application for the same rationale as applied to their parent claim as above discussed.
Instant Application Claim 18 Claims`
‘522 Application Claim 19 Claims
A terminal device, comprising a memory and a processor; wherein the memory is configured to store a program, the processor is configured to call the program stored in the memory to perform:
A communication method, comprising:
transmitting a first message to a network device;
wherein the first message is configured to request downloading at least one type of model data;
wherein the first message comprises at least one of a model identifier corresponding to the at least one type of model data and a service identifier corresponding to the at least one type of model data.
transmitting, by a first device, a first message to a second device,
wherein the first message is used to request downloading application model data ,
wherein the first message comprises at least one of model identifier information corresponding to at least one application model model identifier information corresponding to at least one application model
Rationales:
From the above claim comparison, one can see that claim 19 of the ‘522 application anticipates all recitations of claim 18 of the instant application. Alternatively, claim 18 of the instant application claims variously and essentially similar limitations as those recited in claim 19 of the ‘522 application. There are differences between the claims depicted in the strike-through words and the bolded words. The differences are deemed obvious for the following rationales. Pertaining the difference depicted in the strike-through words, it appears to be broadening claim by omitting limitations. Nevertheless, it has been held that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson, 136 USPQ 184(CCPA). Also note Ex Parte Rainu, 168 USPQ 375 (Bd. App. 1969); omission of a reference whose function is not needed would be an obvious variation. Moreover, and pertaining the difference depicted in the bolded words, it appears to be using different wording but meaning is the same or similar. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims appear to be using different wording but meaning is the same or similar, and it would be obvious to one of ordinary skilled in the art to modify the claim limitations to incorporate certain variation of the elements in using different wording but meaning is the same or similar. A motivation for doing so would be to seek a well-rounded protection for a disclose invention.
The dependent claims 19-20 are included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Specifically, the claims are deemed obvious over dependent claims 19-20 of '522 application for the same rationale as applied to their parent claim as above discussed.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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)(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-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Li et al. (US 2024/0205781) (hereinafter “Li”).
Regarding claim 1, in accordance with Li reference entirety, Li teaches a communication method, comprising:
transmitting, by a terminal device (UE), a first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) to a network device (the network); wherein the first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) is configured to request downloading at least one type of model data (para [0102]: "To allow the network to control the ML training and inference at the UE side, consider two-levels of information which need to be exchanged between the network and the UE: 1) whether require model downloading from the network, and 2) network-oversighted UE's model training/inference configuration." In addition, para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." Furthermore; para [0105]: "In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request."); wherein the first message comprises at least one of a model identifier (Model ID) corresponding to the at least one type of model data and a service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)").
Regarding claim 2, in addition to features recited in base claim 1 (see rationales discussed above), Li also teaches generating, by the terminal device (the UE), the first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) according to first configuration information stored in a non-access stratum (NAS) and/or an assess stratum (AS) (see para [0293] and thereinafter, it is discussed NAS messages); wherein the first configuration information (ML configurations) comprises a model identifier (Model ID) corresponding to at least one type of model data for the terminal device (the UE), in response to the first message carrying the model identifier (Model ID) corresponding to the at least one type of model data; the first configuration information (ML configurations) comprises a service identifier (Service ID) corresponding to the at least one type of model data for the terminal device, in response to the first message carrying the service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)").
Regarding claim 3, in addition to features recited in base claim 1 (see rationales discussed above), Li also teaches before the transmitting, by a terminal device, a first message to a network device, further comprising: transmitting, by the terminal device, a second message to the network device; wherein the second message is configured to register model data expected by the terminal device with the network device (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself.").
Regarding claim 4, in addition to features recited in base claim 3 (see rationales discussed above), Li also teaches wherein the model data expected by the terminal device comprises the at least one type of model data; the transmitting, by a terminal device, a first message to a network device, comprise: transmitting, by the terminal device, the first message to the network device, in response to the at least one type of model data being successfully registered (para [0147]: Moreover, UE should also send a request or an indicator informing the network whether model downloading/transferring is required or not. This indicator can be sent together with service registration/interest indication message." Moreover; para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." The teaching of “the network is responsible for model transfer, updated after the UE sent the corresponding service registration message is equated to the claimed “the model data being successfully registered.”).
Regarding claim 5, in addition to features recited in base claim 3 (see rationales discussed above), Li also teaches wherein the second message (ML configurations) comprises at least one of: a model identifier (Model ID) corresponding to the at least one type of model data; a service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); indication information, configured to indicate the terminal device perform model data registering with the network device; first constraint information, configured to indicate a download area expected by the terminal device when the terminal device downloads corresponding model data (para [0105]: “In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request. In the present disclosure, ML related information exchanging may be expanded to have a wider scope, where the network can configure UE training and inference, where model downloading from the network is not a constraint." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); and second constraint information, configured to constrain a download time expected by the terminal device when the terminal device downloads corresponding model data .
Regarding claim 6, in addition to features recited in base claim 5 (see rationales discussed above), Li also teaches wherein the first constraint information comprises at least one of: a tracking area (TA) identifier corresponding to the download area expected by the terminal device; a radio access network area code (RANAC) identifier corresponding to the download area expected by the terminal device; a cell identifier corresponding to the download area expected by the terminal device; and a geographic coordinate range (wider scope) corresponding to the download area expected by the terminal device (para [0105]: “In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request. In the present disclosure, ML related information exchanging may be expanded to have a wider scope, where the network can configure UE training and inference, where model downloading from the network is not a constraint." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations).
Regarding claim 7, in addition to features recited in base claim 3 (see rationales discussed above), Li also teaches receiving, by the terminal device, a response message of the second message transmitted by the network device; wherein the response message is configured to indicate whether the model data expected by the terminal device is successfully registered (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." The teaching of “the network is responsible for model transfer, updated after the UE sent the corresponding service registration message is equated to the claimed “the terminal device is successfully registered.”).
Regarding claim 8, in addition to features recited in base claim 7 (see rationales discussed above), Li also teaches wherein the response message comprises at least one of: a model identifier (Model ID) corresponding to at least one type of successfully-registered model data in the model data expected by the terminal device (para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); download area restriction information corresponding to the at least one type of successfully-registered model data; wherein the download area restriction information is configured to restrict an area at which the terminal device is located when the terminal device downloads model data; download time restriction information corresponding to the at least one type of successfully-registered model data; wherein the download time restriction information is configured to restrict a time when the terminal device downloads model data; a model identifier corresponding to at least one type of unsuccessfully-registered model data in the model data expected by the terminal device; registration area restriction information corresponding to the at least one type of unsuccessfully-registered model data; wherein the registration area restriction information is configured to restrict an area at which the terminal device is located when the terminal device registers corresponding model data; registration time restriction information corresponding to the at least one type of unsuccessfully-registered model data; wherein the registration time area restriction information is configured to restrict a time when the terminal device registers corresponding model data; a failure reason corresponding to the at least one type of unsuccessfully-registered model data; and model data usage restriction information, configured to indicate whether at least two types of successfully-registered model data are capable of being used simultaneously.
Regarding claim 9, in addition to features recited in base claim 3 (see rationales discussed above), Li also teaches wherein the second message comprises a model identifier (Model ID) corresponding to to-be-registered model data expected by the terminal device, and/or a service identifier (Service ID) corresponding to the to-be-registered model data expected by the terminal device (para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations).
Regarding claim 10, in addition to features recited in base claim 9 (see rationales discussed above), Li also teaches generating, by the terminal device, the second message according to second configuration information stored in a non-assess stratum (NAS) and/or an assess stratum (AS) (see para [0293] and thereinafter, it is discussed NAS messages); wherein the second configuration information comprises a model identifier corresponding to at least one type of model data for the terminal device, and/or the second configuration information comprises a service identifier corresponding to the at least one type of model data for the terminal device (para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations)
Regarding claim 11, in accordance with Li reference entirety, Li teaches a
communication method, comprising:
receiving, by a network device (the network), a first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) transmitted by a network device (the UE); wherein the first message is configured to request downloading at least one type of model data (para [0102]: "To allow the network to control the ML training and inference at the UE side, consider two-levels of information which need to be exchanged between the network and the UE: 1) whether require model downloading from the network, and 2) network-oversighted UE's model training/inference configuration." In addition, para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." Furthermore; para [0105]: "In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request."); wherein the first message comprises at least one of a model identifier (Model ID) corresponding to the at least one type of model data and a service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)").
Regarding claim 12, in addition to features recited in base claim 11 (see rationales discussed above), Li also teaches before the receiving, by a network device (the network), a first message transmitted by a terminal device (the UE), further comprising: receiving, by the network device, a second message transmitted by the terminal device; wherein the second message is configured to register model data expected by the terminal device with the network device (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself.").
Regarding claim 13, in addition to features recited in base claim 12 (see rationales discussed above), Li also teaches wherein the model data expected by the terminal device comprises the at least one type of model data; the receiving, by a network device, a first message transmitted by a terminal device, comprise: receiving, by the network device, the first message transmitted by the terminal device, in response to the at least one type of model data being successfully registered (para [0147]: Moreover, UE should also send a request or an indicator informing the network whether model downloading/transferring is required or not. This indicator can be sent together with service registration/interest indication message." Moreover; para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." The teaching of “the network is responsible for model transfer, updated after the UE sent the corresponding service registration message is equated to the claimed “the model data being successfully registered.”).
Regarding claim 14, in addition to features recited in base claim 12 (see rationales discussed above), Li also teaches wherein the second message (ML configurations) comprises at least one of: a model identifier (Model ID) corresponding to the at least one type of model data; a service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); indication information, configured to indicate the terminal device perform model data registering with the network device; first constraint information, configured to indicate a download area expected by the terminal device when the terminal device downloads corresponding model data (para [0105]: “In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request. In the present disclosure, ML related information exchanging may be expanded to have a wider scope, where the network can configure UE training and inference, where model downloading from the network is not a constraint." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); and second constraint information, configured to constrain a download time expected by the terminal device when the terminal device downloads corresponding model data.
Regarding claim 15, in addition to features recited in base claim 14 (see rationales discussed above), Li also teaches wherein the first constraint information comprises at least one of: a tracking area (TA) identifier corresponding to the download area expected by the terminal device; a radio access network area code (RANAC) identifier corresponding to the download area expected by the terminal device; a cell identifier corresponding to the download area expected by the terminal device; and a geographic coordinate range (wider scope) corresponding to the download area expected by the terminal device (para [0105]: “In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request. In the present disclosure, ML related information exchanging may be expanded to have a wider scope, where the network can configure UE training and inference, where model downloading from the network is not a constraint." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations).
Regarding claim 16, in addition to features recited in base claim 12 (see rationales discussed above), Li also teaches transmitting, by the network device, a response message of the second message to the terminal device; wherein the response message is configured to indicate whether the model data expected by the terminal device is successfully registered (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." The teaching of “the network is responsible for model transfer, updated after the UE sent the corresponding service registration message is equated to the claimed “the terminal device is successfully registered.”).
Regarding claim 17, in addition to features recited in base claim 16 (see rationales discussed above), Li also teaches wherein the response message comprises at least one of: a model identifier (Model ID) corresponding to at least one type of successfully-registered model data in the model data expected by the terminal device (para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)." It is also noted that the claim is drafted in an alternative format not requiring all of the recitations but one of the recitations); download area restriction information corresponding to the at least one type of successfully-registered model data; wherein the download area restriction information is configured to restrict an area at which the terminal device is located when the terminal device downloads model data; download time restriction information corresponding to the at least one type of successfully-registered model data; wherein the download time restriction information is configured to restrict a time when the terminal device downloads model data; a model identifier corresponding to at least one type of unsuccessfully-registered model data in the model data expected by the terminal device; registration area restriction information corresponding to the at least one type of unsuccessfully-registered model data; wherein the registration area restriction information is configured to restrict an area at which the terminal device is located when the terminal device registers corresponding model data; registration time restriction information corresponding to the at least one type of unsuccessfully-registered model data; wherein the registration time area restriction information is configured to restrict a time when the terminal device registers corresponding model data; a failure reason corresponding to the at least one type of unsuccessfully-registered model data; and model data usage restriction information, configured to indicate whether at least two types of successfully-registered model data are capable of being used simultaneously.
Regarding claim 18, in accordance with Li reference entirety, Li discloses a terminal device (Figure 16; UE 1602 or FIG. 17), comprising a memory (Figure 17; MEMORY/STORAGE DEVICES 1720) and a processor (Figure 17; PROCESSORS 1710); wherein the memory (Figure 17; MEMORY/STORAGE DEVICES 1720) is configured to store a program (Figure 17; INSTRUCTIONS 1750), the processor (Figure 17; PROCESSORS 1710) is configured to call the program (Figure 17; INSTRUCTIONS 1750) stored in the memory (Figure 17; MEMORY/STORAGE DEVICES 1720) to perform: transmitting, by a terminal device (UE), a first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) to a network device (the network); wherein the first message (broadcast information/MachineLearningSupportField/MLCapabilityIndication/ModelTrainingConfiguration) is configured to request downloading at least one type of model data (para [0102]: "To allow the network to control the ML training and inference at the UE side, consider two-levels of information which need to be exchanged between the network and the UE: 1) whether require model downloading from the network, and 2) network-oversighted UE's model training/inference configuration." In addition, para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." Furthermore; para [0105]: "In some embodiments, the AI/ML model can always be downloaded to the UE according to the UE ML capability and request."); wherein the first message comprises at least one of a model identifier (Model ID) corresponding to the at least one type of model data and a service identifier (Service ID) corresponding to the at least one type of model data (para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc)").
Regarding claim 18, in addition to features recited in base claim 18 (see rationales discussed above), Li also discloses establishing a session management context (broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication); wherein the session management context (broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication) is configured to manage a download process, a modification process, or a deletion process of the at least one type of model data (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself.").
Regarding claim 20, in addition to features recited in base claim 18 (see rationales discussed above), Li also discloses receiving a download configuration transmitted by the network device; wherein the download configuration is configured to configure the terminal device to download the at least one type of model data (para [0103]: "In some embodiments, to exchange the first level of information (e.g. request to download model from the network or not), the UE can learn the machine learning capability and network supported models/services enabled by AI/ML through the broadcast information (e.g. MachineLearningSupport field) via MLCapabilitylndication. For those services where the network can offer the AI/ML models, UE can decide whether to register or request a ML model from the network based on the received information, and send the corresponding service registration/interest indication message back to the network as model downloading request. In this scenario, the network is responsible for model transfer, update, etc. However, it is also possible that the UE will not request model from the network, this can either because the UE does not have the ML capability, or because the UE holds the ML model itself." Moreover; para [0107]: "Moreover, two sets of ML configurations are described to be send over air interface via RRC signaling." And para [0108]: "Set 1: UE training configuration (ModelTrainingConfiguration)." And para [0109]: "Model ID." And para [0110]: " Service ID (e.g. CSI feedback, positioning, beam management, etc).").
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yuan et al. (US 12,038,976).
Shen et al. (US 2022/0342713).
Croxford et al. (US 2021/0304514).
Lee et al. (US 2022/0108214).
Ishii et al. (US 2022/0413926).
Onno et al. (US 2024/0187959).
Samdanis et al. (WO 2021/023388).
3GPP TR 22.874 V18.0.1, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on traffic characteristics and performance requirements for AI/ML model transfer in 5GS (Release 18), 111 pages, June 2021.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK DUONG whose telephone number is (571)272-3164. The examiner can normally be reached 7:00AM-3:30PM.
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, MICHAEL THIER can be reached at 571-272-2832. 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.
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
/FRANK DUONG/Primary Examiner, Art Unit 2474 February 19, 2026