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 .
Response to Arguments
Applicant's arguments filed December 11, 2025 have been fully considered but they are not persuasive. Regarding claim 1, Applicant indicates that the claim recites “among other features, transmitting list information in which network IDs, a priority of the IDs, and identification information are associated with one another”, and that the claim also recites the "identification information being used when one network ID is selected from among a plurality of network IDs having the same priority." Applicant asserts that Starsinic does not teach the claimed “identification information.” In particular, Applicant asserts that “Starsinic generally describes a network-side ordering of PLMN IDs based on UE identity, but the resulting list as transmitted contains only PLMNIDs (and optionally priorities), not the underlying identification data” and that “[a]ccordingly, Starsinic does not teach identification information associated with a plurality of network IDs and a priority of the network IDs transmitted in list information.” Examiner respectfully disagrees that Starsinic fails to disclose this feature of claim 1. Examiner notes that the claim merely recites “identification information” with no indication of the nature of the “identification information” or to what entity the “identification information” is intended to identify. For example, the language of claim 1 does not recite that the “identification information” is related to identification of “the terminal device” of claim 1. Accordingly, under a broadest reasonable interpretation of claim 1 the “identification information” may refer to any type of identification information. Starsinic [¶0087] discloses that “in response to the UE providing such an indication, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions” and that “different lists may be maintained in which the order of the PLMNs is based on the UE identity…”. Examiner respectfully submits that since the network of Starsinic transmits the list information to the UE, the list information inherently includes an association of “identification information” of the UE with the plurality of network IDs, and priority of the network ID.
Applicant further asserts that Starsinic also does not teach the claimed "the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs." In particular, Applicant asserts that “paragraph [0168] of Starsinic, cited in the Office Action as disclosing this element, merely states that the UE applies an internal rule - for example, ‘based on an identity of the UE’ - to determine its selection order.” Applicant further asserts that “[i]n Starsinic, the UE derives an order after receiving a list devoid of identification information; hence Starsinic omits the claimed feature of the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority.” Examiner respectfully disagrees. Starsinic [0168] describes that the UE may determine the order in which it attempts to register with the PLMN based on an identity of the UE as well as the priority of the PLMN. Accordingly, Examiner submits that Starsinic discloses the limitation of “the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs” recited in claim 1.
Applicant indicates that claim 1 also recites "a plurality of network IDs indicating a network available to a terminal device when a disaster occurs." Applicant asserts that “[i]n contrast, Starsinic's lists relate to networks ordinarily forbidden but conditionally released in disaster scenarios (see [0086]).” Examiner respectfully disagrees. Examiner respectfully submits that “networks ordinarily forbidden but conditionally released in disaster scenarios” as disclosed by Starsinic are equivalent to the claimed "plurality of network IDs indicating a network available to a terminal device when a disaster occurs."
Claim Rejections - 35 USC § 102
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 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-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Starsinic et al. (US 2024/0007878 A1)(hereinafter “Starsinic”).
Regarding claim 1, Starsinic discloses a communication apparatus (FIG. 3D: gNode-B 180a) comprising:
at least one memory storing instructions, and at least one processor configured to execute the instructions to (FIG. 3G, [¶0316]-[ ¶0318]: computing system 90 may be controlled by computer readable instructions, and includes a processor 91 and random access memory 82; [¶0322]: the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and/or implement the systems, methods and processes described herein.);
transmit list information in which a plurality of network IDs indicating a network available to a terminal device when a disaster occurs, a priority of the network ID, and identification information are associated with one another ([¶0086]: in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions. Different lists may be maintained in which the order of the PLMNs is based on the UE identity; [¶0093]: the information may include information about what priority level UEs the PLMN is willing to serve in the event of a disaster; [¶0105]: the message may include PLMN IDs that may be used during the disaster situation and a set of cell priorities that include cells of the PLMNs that can serve the UE during the disaster; [¶0242]: the message may further include multiple UE identifiers (e.g., UE ID or IMSI)), the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs ([¶0168]: the UE uses a rule to prioritize the PLMNs to decrease the likelihood that a high percentage of the disaster roaming UEs will all attempt to select the same PLMN; for example the rule may be based on an identity of the UE.).
Regarding claim 2, Starsinic discloses all features of claim 1 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to transmit the list information to the terminal device via a base station (Fig. 3B, [¶0267]: a RAN 103 includes Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with WRTUs 102a, 102b, and 102c.).
Regarding claim 3, Starsinic discloses all features of claim 2 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to transmit the list information to the terminal device in registration processing related to the terminal device ([¶0199]: the UE sends a Registration Request to the AMF of the disaster PLMN to indicate that the UE is registering for disaster roaming).
Regarding claim 4, Starsinic discloses all features of claim 1 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to receive the list information from another apparatus ([¶0132]: an access and mobility management function (AMF) may send NAS notification messages (e.g., UE Configuration Updated) to UE(s) that may include the Disaster Information).
Regarding claim 5, Starsinic discloses all features of claim 4 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to receive the list information from a management apparatus configured to manage subscriber information of the terminal device in registration processing related to the terminal device ([¶0132]: an access and mobility management function (AMF) (“a management apparatus”) may send NAS notification messages (e.g., UE Configuration Updated) to UE(s) that may include the Disaster Information).
Regarding claim 6, Starsinic discloses all features of claim 1 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to manage the list information ([¶0086]: in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions. Different lists may be maintained in which the order of the PLMNs is based on the UE identity).
Regarding claim 7, Starsinic discloses all features of claim 1 as outlined above.
wherein the identification information includes at least one of information for identifying the terminal device and information for identifying a user using the terminal device ([¶0242]: the message may further include multiple UE identifiers (e.g., UE ID or IMSI)).
Regarding claim 8, Starsinic discloses all features of claim 1 as outlined above.
Starsinic also discloses wherein the list information associates a setting value specified based on the identification information with the network ID ([¶0168]: the list of PLMNs may be ordered in a standardized manner (e.g., based on the several (e.g., 5) LSBs of the PLMN ID) and the UE may determine the order in which it attempts to register with each PLMN based on the several (e.g., 5) LSBs of an identity of the UE. In a different example, the PLMN may be listed in an order (e.g., 1-4) and the UE may determine which PLMN it attempts to Register with first by performing a modulo operation. The modulo operation may be at least a portion of the UE's identity (e.g., a select number of bits from the UE's IMSI) modulo the number of detected Forbidden PLMNs (e.g., 4 detected Forbidden PLMNs). In another example, the detected PLMNs may be listed in priority order (e.g., 1-4) and the UE may determine its own priority by generating a random number (e.g., 1, 2, 3, or 4).).
Regarding claim 9, Starsinic discloses all features of claim 8 as outlined above.
Starsinic also discloses wherein the list information equalizes the number of the setting values associated with the network ID among the plurality of network IDs ([¶0168]: the list of PLMNs may be ordered in a standardized manner (e.g., based on the several (e.g., 5) LSBs of the PLMN ID) and the UE may determine the order in which it attempts to register with each PLMN based on the several (e.g., 5) LSBs of an identity of the UE. In a different example, the PLMN may be listed in an order (e.g., 1-4) and the UE may determine which PLMN it attempts to Register with first by performing a modulo operation. The modulo operation may be at least a portion of the UE's identity (e.g., a select number of bits from the UE's IMSI) modulo the number of detected Forbidden PLMNs (e.g., 4 detected Forbidden PLMNs). In another example, the detected PLMNs may be listed in priority order (e.g., 1-4) and the UE may determine its own priority by generating a random number (e.g., 1, 2, 3, or 4).).
Regarding claim 10, Starsinic discloses all features of claim 8 as outlined above.
Starsinic also discloses wherein the list information makes the number of the setting values associated with the network ID unequal among the plurality of network IDs (¶0153]: when in automatic PLMN selection mode, the UE may determine that the Allowable PLMNs are in disaster mode. Once the UE makes this determination, it may begin a Manual Disaster PLMN Selection procedure. ¶0154]: in the Manual Disaster PLMN Selection procedure, a GUI may indicate to the PLMNs are most likely to serve the UE, for example, based on the current location of the UE. [¶0154]: the GUI may allow the user to select a PLMN from the list to attempt to connect to in disaster mode. Accordingly, Starsinic discloses configuring an unequal amount of setting values among the network IDs).
Regarding claim 11, Starsinic discloses a terminal device (FIG. 3F, [¶0306]: WTRU 102) comprising:
at least one memory storing instructions (FIG. 3F, [¶0306]: non-removable memory 130), and
at least one processor configured to execute the instructions to (FIG. 3F, [¶0306]: processor 118; [¶0322]: the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and/or implement the systems, methods and processes described herein.);
receive list information in which a plurality of network IDs accessible by a terminal device when a disaster occurs, a priority of the network ID, and identification information are associated with one another ([¶0086]: in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions. Different lists may be maintained in which the order of the PLMNs is based on the UE identity; [¶0093]: the information may include information about what priority level UEs the PLMN is willing to serve in the event of a disaster; [¶0105]: the message may include PLMN IDs that may be used during the disaster situation and a set of cell priorities that include cells of the PLMNs that can serve the UE during the disaster; [¶0242]: the message may further include multiple UE identifiers (e.g., UE ID or IMSI)), the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs ([¶0168]: the UE uses a rule to prioritize the PLMNs to decrease the likelihood that a high percentage of the disaster roaming UEs will all attempt to select the same PLMN; for example the rule may be based on an identity of the UE.); and
transmit a message requesting registration to a network indicated by a network ID selected based on the priority and the identification information when a disaster occurs (FIG. 1B, [¶0073]-[¶0074]: the UE begins a Disaster PLMN Selection procedure to select a PLMN from its Forbidden PLMN list, and registers with the selected PLMN.).
Regarding claim 12, Starsinic discloses all features of claim 11 as outlined above.
Starsinic also discloses wherein, when registration with the network is rejected, the at least one processor is further configured to execute the instructions to transmit a message requesting registration to a network indicated by a network ID associated with a priority lower than a priority associated with the network ID indicating the network ([0176]: when the UE registers with the network, the UE may provide its UE disaster priority so that the network can determine its willingness to serve the UE. For example, if the UE indicates that it is low priority, the network may reject the registration and provide a cause code indicating the priority levels that the network is willing to serve.).
Regarding claim 13, Starsinic discloses all features of claim 11 as outlined above.
Starsinic also discloses wherein the at least one processor is further configured to execute the instructions to receive a response message to a message requesting registration that is transmitted to a communication apparatus, the response message including the list information ([¶0086]: in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions.).
Regarding claim 14, Starsinic discloses a communication method being executed in a communication apparatus (FIG. 3D: gNode-B 180a), the communication method comprising:
managing list information in which a plurality of network IDs indicating a network available to a terminal device when a disaster occurs, a priority of the network ID, and identification information are associated with one another, the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs; and transmitting the list information (in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions. Different lists may be maintained in which the order of the PLMNs is based on the UE identity; [¶0093]: the information may include information about what priority level UEs the PLMN is willing to serve in the event of a disaster; [¶0105]: the message may include PLMN IDs that may be used during the disaster situation and a set of cell priorities that include cells of the PLMNs that can serve the UE during the disaster; [¶0242]: the message may further include multiple UE identifiers (e.g., UE ID or IMSI); [¶0168]: the UE uses a rule to prioritize the PLMNs to decrease the likelihood that a high percentage of the disaster roaming UEs will all attempt to select the same PLMN; for example the rule may be based on an identity of the UE.).
Regarding claim 15, Starsinic discloses all features of claim 14 as outlined above.
Starsinic also discloses wherein the list information is transmitted to the terminal device via a base station (Fig. 3B, [¶0267]: a RAN 103 includes Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with WRTUs 102a, 102b, and 102c.).
Regarding claim 16, Starsinic discloses all features of claim 15 as outlined above.
Starsinic also discloses wherein the list information is transmitted to the terminal device in registration processing related to the terminal device ([¶0199]: the UE sends a Registration Request to the AMF of the disaster PLMN to indicate that the UE is registering for disaster roaming).
Regarding claim 17, Starsinic discloses all features of claim 14 as outlined above.
Starsinic also discloses wherein the list information is received from another apparatus ([¶0132]: an access and mobility management function (AMF) may send NAS notification messages (e.g., UE Configuration Updated) to UE(s) that may include the Disaster Information).
Regarding claim 18, Starsinic discloses all features of claim 17 as outlined above.
Starsinic also discloses wherein the list information is received from a management apparatus configured to manage subscriber information of the terminal device in registration processing related to the terminal device ([¶0132]: an access and mobility management function (AMF) (“a management apparatus”) may send NAS notification messages (e.g., UE Configuration Updated) to UE(s) that may include the Disaster Information).
Regarding claim 19, Starsinic discloses a communication method being executed in a terminal device, the communication method comprising:
receiving list information in which a plurality of network IDs accessible by a terminal device when a disaster occurs, a priority of the network ID, and identification information are associated with one another ([¶0086]: in response to a UE providing an indication that the UE supports receiving disaster information, the network may provide a list of Forbidden PLMNs that the UE may try to connect to in case of disaster conditions. Different lists may be maintained in which the order of the PLMNs is based on the UE identity; [¶0093]: the information may include information about what priority level UEs the PLMN is willing to serve in the event of a disaster; [¶0105]: the message may include PLMN IDs that may be used during the disaster situation and a set of cell priorities that include cells of the PLMNs that can serve the UE during the disaster; [¶0242]: the message may further include multiple UE identifiers (e.g., UE ID or IMSI)), the identification information being used when one network ID is selected from among a plurality of network IDs having the same priority, among the plurality of network IDs ([¶0168]: the UE uses a rule to prioritize the PLMNs to decrease the likelihood that a high percentage of the disaster roaming UEs will all attempt to select the same PLMN; for example the rule may be based on an identity of the UE.); and
transmitting a message requesting registration to a network indicated by a network ID selected based on the priority and the identification information when a disaster occurs (FIG. 1B, [¶0073]-[¶0074]: the UE begins a Disaster PLMN Selection procedure to select a PLMN from its Forbidden PLMN list, and registers with the selected PLMN.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Agarwal et al. (US 2025/0280355 A1) – Methods and Apparatuses To Handle PLMN List.
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W MADDOX whose telephone number is (571)272-5834. The examiner can normally be reached M-Th 7:30am-5:00pm, 1st F 7:30am-4:00pm, 2nd F off.
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, Asad M Nawaz can be reached at 571-272-3988. 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.
/MICHAEL WAYNE MADDOX/Examiner, Art Unit 2463
/ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463