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 Amendment
Applicant’s amendment filed on March 17, 2026, has been entered. Claims 36-40 and 42-56 are presently pending with claims 36 and 48 being independent. Claims 37-38, 40, 42-47, and 49-55 have been previously presented. Claims 36, 39, and 48 are currently amended. Claim 56 is new. Claim 41 has been cancelled.
Response to Arguments
Applicant’s arguments with respect to claim(s) 36 and 48 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 36-40, 42-48, and 52-56 are rejected under 35 U.S.C. 103 as being unpatentable over Baek et al. (US 2022/0053455 A1; hereinafter Baek) in view of 3GPP TR 23.757 (V1.2.0 (2020-11), Study on architectural enhancements for 5G multicast-broadcast services (Release 17); hereinafter 3GPP).
Regarding claim 36, Baek teaches a method implemented at a Multicast Broadcast Service Function (MBSF) (¶ [0046] A cellular system may include a multicast/broadcast service function (MBSF).),
comprising:
receiving a first request to allocate a MBS session ID (read as TMGI) for an MBS session from an Application Function (AF) (¶ [0069] The AF may request an MBS service while delivering information for the MBS service to the MBSF.; ¶ [0072] The information for the MBS service may include a multicast group ID list (e.g., a TMGI).; ¶ [0173] AF may send to the NEF/MBSF a request (TMGI allocation request) for allocating a TMGI.; ¶ [0176] The information for the MBS service may further include an indication of requesting to allocate a TMGI.);
allocating the MBS session ID from the MBS session ID range for the MBS session and selecting at least one Multicast Broadcast - Session Management Function (MB-SMF), based on the first request (¶ [0076] The MBSF may set up an MBS service session, assign an MBS service session ID.; ¶ [0174] The NEF/MBSF may allocate a new TMGI value appropriate for the request.; ¶ [0175] The information for the MBS service may include information for the MBS service area.; ¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session.);
providing the allocated MBS session ID to the at least one MB-SMF (¶ [0178] The NEF/MBSF may transmit an MBS session start request message to the selected MB-SMF. The MBS session start request message may include TMGI information.; ¶ [0179] MB-SMF may provide the NRF with the MBS session ID, i.e., TMGI information.); and
sending the allocated MBS session ID to the AF (¶ [0078] The NEF/MBSF may transfer, to the AF, an MBS service response. MBS service session ID information may be transferred to the AF.).
Baek does not explicitly teach registering an Multicast Broadcast Service (MBS) session identifier (ID) range associated with the MBSF with a Network Repository Function (NRF).
In analogous art, 3GPP teaches registering an Multicast Broadcast Service (MBS) session identifier (ID) range associated with the MBSF with a Network Repository Function (NRF) (§ 6.2.2.1, step 2, The MBSF may have a pre-configured TMGI range for each MB-SMF. The TMGI range should also be configured/registered in the NRF to all AMFs to discover which MB-SMF is controlling an MB Session identified by a TMGI.; Note: Instant application’s specification at ¶ [00110] identifies the claimed MBS Session ID as a temporary mobile group identity (TMGI), stating that the “MBS Session ID (i.e., TMGI)” is used to identify the MBS session. Under the broadest reasonable interpretation (BRI) consistent with the specification, the claimed “MBS session (ID)” encompasses a TMGI, and the claimed “MBS session ID range” encompasses a range of TMGIs.);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine selecting identification information of MB-SMF and MBS session ID taught by 3GPP with Multicast Broadcast Service, MBS, taught by Baek. One would have been motivated to do so in order to reduce latency and improve service continuity during mobility, which would improve the user’s experience, by allowing the network to route the MBS session to a locally suitable MBS-SMF based on the device’s location (3GPP: page 138).
Regarding claim 37, Baek teaches wherein the at least one MB-SMF comprises multiple MB-SMF entities, and wherein the multiple MB-SMF entities are associated with different regions (¶ [0064] For local MBS services MB-SMFs may be located near the specific local area for an MBS service in the specific local area. These are referred to as a local MB-SMF.; ¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session. In this case, the MB-SMF may find an appropriate MB-SMF.).
Regarding claim 38, Baek teaches wherein the first request comprises service area information for the MBS session, and wherein the at least one MB-SMF is selected based on the service area information (¶ [0175] The AF may send a request for an MBS service while delivering information for the MBS service to the NEF/MBSF. The information for the MBS service may include information for the MBS service area in which the MBS service is provided (e.g., all or some of area information for an actual map, a cell ID list or a TAI list.; ¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session through the NRF. In this case, the MB-SMF may find an appropriate MB-SMF by transferring the TMGI or MBS session ID and MBS service area information to the NRF.).
Regarding claim 39, Baek teaches wherein the at least one MB-SMF is selected by querying a Network Repository Function, NRF (¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session through the NRF.; ¶ [0184] The SMF refers to information for the requested TMGI and requests the NRF, thereby discovering the MB-SMF serving the TMGI.).
Regarding claim 40, Baek teaches wherein the MBS session ID is a Temporary Mobile Group Identity, TMGI (¶ [0179] Along with the MBS session ID, i.e., TMGI information.).
Regarding claim 42, Baek teaches receiving a second request (read as requesting to start an MBS service) to start an MBS session from the AF (¶ [0069] The AF may request an MBS service to the MBSF so as to provide the MBS service through the 5GS.; ¶ [0173] AF may send, to the NEF/MBSF, a request (TMGI allocation request) before requesting to start an MBS service through a 5GS.; ¶ [0175] The AF may send a request for an MBS service while delivering information for the MBS service to the NEF/MBSF.);
determining at least one MB-SMF based on the second request (¶ [0076] If the MBS service is determined to be authorized, in operation, the MBSF may set up an MBS service session. Select an MBSU corresponding to the MBS service area.; ¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session through the NRF. In this case, MB-SMF may find an appropriate MB-SMF by transferring the TMGI or MGS session ID and MBS service area information to the NRF.);
sending the second request to the determined at least one MB-SMF (¶ [0178] The NEF/MBSF may transmit an MBS session start request message to the selected MB-SMF. The MBS session start request message may enable the NEF/MBSF to allocate a TMGI or may include an indication of requesting the MB-SMF to allocate a TMGI.);
receiving MBS session resource information for the MBS session from the at least one MB-SMF (¶ [0181] The MB-SMF may transfer information generated for MBS session service to the NEF/MBSF. The TMGI and the address/port information and tunnel ID for the MB-UPF to receive traffic may be transferred.); and
sending the MBS session resource information to the AF (¶ [0181] The MB-SMF may transfer information generated for the MBS session service to the NEF/MBSF or the AF. The MBSU or MBSTF may provide the MBSF with the tunnel ID and address/port information for receiving MBS traffic, and the NEF/MBSF may transfer the information along with the TMGI information to the AF.).
Regarding claim 43, Baek teaches requesting, in response to the second request, user plane information for the MBS session from a Multicast Broadcast Service Transport Function, MBSTF (FIG. 7A, operation 712 MBS session start response, operation 713 MBS service response (TMGI, MBSU/MBSTF address or MB-UPF address); ¶ [0181] Upon receiving the message of operation 712, the NEF/MBSF may transfer the TMGI and the address/port information and tunnel ID for the MB-UPF to receive traffic to the MBSU or a multicast-broadcast service traffic function (MBSTF). In operation 713, the MBSU or MBSTF may provide the MBSF with the tunnel ID and address/port information for receiving MBS traffic.); and
sending the user plane information in the MBSTF to the AF, without sending the MBS session resource information (Fig. 7A, operation 713 MBS service response (TMGI, MBSU/MBSTF address or MB-UPF address); ¶ [0181] In operation 713, the MBSU or MBSTF may provide the MBSF with the tunnel ID and address/port information for receiving MBS traffic, and the NEF/MBSF may transfer the information along with the TMGI information to the AF.).
Regarding claim 44, Baek teaches querying, in response to the second request, a Policy Control Function, PCF, for quality of service, QoS, information for the MBS session based on service requirements in the second request (Fig. 2A, operation 201 MBS service request, operation 202 Policy Authorization Request, operation 203 Policy Authorization Response; ¶ [0073] The information for the MBS service may also include characteristics of traffic generated by the MBS service (e.g., 5QI, resource type, maximum bit rate, guaranteed bit rate, and priority level), as QoS information.; ¶ [0075] The MBSF, which receives the request in operation 201, may transmit, to the PCF, the information received in operation 201 and the obtained characteristic information for the traffic generated due to the MBS service in operation 202 and may receive an authorization for the service in operation 203. In other words, in operation 202, the MBSF/NEF may transmit a policy authorization request to the PCF.; ¶ [0175] The information for the MBS service may also include characteristics of traffic generated by the MBS service as QoS information.; ¶ [0177] The MBSF may transmit, to the PCF, characteristic information for the traffic generated due to the MBS service and use it for the authorization for a future service.).
Regarding claim 45, Baek teaches wherein the second request comprises an MBS session ID (read as TMGI information), service area information, and service requirements (read as QoS information) (Fig. 7A, operation 708b MBS session start request (TMGI, MBS service type); ¶ [0175] The information for the MBS service may also include characteristics of traffic as QoS information.; ¶ [0178] In operation 708b, the NEF/MBSF may transmit an MBS session start request message to the selected MB-SMF. The MBS session start request message may include TMGI information and MBS service type.), and
wherein the at least one MB-SMF is determined based on the service area information (¶ [0177] The NEF/MBSF may select an MB-SMF. The MB-SMF may find an appropriate an appropriate MB-SMF by transferring the TMGI or MBS session ID and MBS service area information to the NRF and thereby request the NRF.).
Regarding claim 46, Baek teaches wherein the MBS session resource information comprises N6 tunnel information (read as tunnel ID and address/port information for the MB-UPF to receive MBS traffic) for the MBS session in a Multicast Broadcast - User Plane Function, MB-UPF (Fig. 2A, operation 211 N4 setup; ¶ [0100] In operation 211, the MB-SMF may select the MB-UPF to set up a shared delivery tunnel for the MB session and set up an N4.; ¶ [0180] A tunnel ID and address/port information for the MB-UPF to receive MBS traffic.; ¶ [0182] Transferring MBS traffic to the MB-UPF.).
Regarding claim 47, Baek teaches wherein the first request (read as allocate a TMGI) and the second request (read as MBS start request) are received in a single message (¶ [0178] The MBS start request message may include TMGI information and MBS service type. The MBS start request message may include an indication of requesting the MB-SMF to allocate a TMGI.).
Regarding claim 48, Baek teaches method implemented at a network function comprising (¶ [0049] The MBSF is a network function that manages the session for an MBS service.):
receiving a message associated with an MBS session (¶ [0089] AMG may select an appropriate MB-SMF and transfer, to the selected MB-SMF, a join request message for the multicast session received from the UE.; ¶ [0090] The join request message may include the MBS service session ID which is information for the MBS service session to be joined.);
obtaining identification information of an MB-SMF associated with the MBS session from the MBSF (¶ [0098] The MBSF may request to the MB-SMF to set up an MB session.; ¶ [0177] The MBSF may select an MB-SMF to serve the MBS session through the NRF.; ¶ [0179] The MB-SMF may provide the NRF with the address or ID of the MB-SMF along with the MBS session ID.; and
obtaining an MBS session context for the MBS session from the MB-SMF identified by the identification information (Fig. 2A, operation 211 N4 Setup, operation 212 MB session setup response; ¶ [0100] In operation 211, the MB-SMF may select the MB-UPF to set up a shared delivery tunnel for the MB session and set up an N4. In operation 212, the MB-SMF may transmit, to the NEF/MBSF, an MB session setup response message including information for the MB session ID and tunnel and obtained point information for the MB-UPF to the NEF/MBSF and set up an MB session for a (global) multicast service.).
Baek does not explicitly teach discovering an MBSF in response to the message by querying a NRF for identification information of the MBSF, wherein the MBSF is registered with the NRF with an associated MBS session ID range.
In analogous art, 3GPP teaches discovering an MBSF in response to the message by querying a NRF for identification information of the MBSF, wherein the MBSF is registered with the NRF with an associated MBS session ID range (§ 6.2.2.1, step 2, The MBSF may have a pre-configured TMGI range for each MB-SMF. The TMGI range should also be configured/registered in the NRF to all AMFs to discover which MB-SMF is controlling an MB Session identified by a TMGI.; Note: Instant application’s specification at ¶ [00110] identifies the claimed MBS Session ID as a temporary mobile group identity (TMGI), stating that the “MBS Session ID (i.e., TMGI)” is used to identify the MBS session. Under the broadest reasonable interpretation (BRI) consistent with the specification, the claimed “MBS session (ID)” encompasses a TMGI, and the claimed “MBS session ID range” encompasses a range of TMGIs.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine selecting identification information of MB-SMF and MBS session ID taught by 3GPP with Multicast Broadcast Service, MBS, taught by Baek. One would have been motivated to do so in order to reduce latency and improve service continuity during mobility, which would improve the user’s experience, by allowing the network to route the MBS session to a locally suitable MBS-SMF based on the device’s location (3GPP: page 138).
Regarding claim 50, Baek teaches wherein obtaining identification information of an MB-SMF associated with the MBS session from the MBSF comprises: providing an MBS session ID of the MBS session to the MBSF (¶ [0093] MB-SMF may transmit a message (notification of joining service) to the NEF/MBSF.; ¶ [0094] The join request message (notification of joining service) may include the MBS service session ID that is information for the MBS service session to be joined.);
obtaining the identification information of at least one MB-SMF, the identification information being associated with a service area (¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session through the NRF. The MB-SMF may find an appropriate MB-SMF by transferring MBS service area information to the NRF and thereby request the NRF.; ¶ [0179] The MB-SMF may provide the NRF with the address or ID of the MB-SMF along with the MBS session ID.); and
Baek does not explicitly teach selecting, in response to receiving the identification information of multiple MB-SMF entities, the identification information of one of the at least one MB-SMF based on location information of a terminal device associated with the MBS session.
In analogous art, 3GPP teaches selecting, in response to receiving the identification information of multiple MB-SMF entities, the identification information of one of the at least one MB-SMF based on location information of a terminal device associated with the MBS session (§6.21.2.1, The SMF queries the UDR for information about the multicast context. If the UDR provides information about location areas stored within the multicast context (including MB-SMF ID, location area and area session ID for each location area), the SMF selects location dependent multicast context information based on the location area where the UE is residing. The SMF determines the applicable MB-SMF ID, area session ID, location area in that manner.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine selecting identification information of MB-SMF taught by 3GPP with Multicast Broadcast Service, MBS, taught by Baek. One would have been motivated to do so in order to reduce latency and improve service continuity during mobility, which would improve the user’s experience, by allowing the network to route the MBS session to a locally suitable MBS-SMF based on the device’s location (3GPP: page 138).
Regarding claim 51, Baek teaches wherein obtaining identification information of an MB-SMF associated with the MBS session from the MBSF comprises: obtaining the identification information of a specific MB-SMF (¶ [0177] The NEF/MBSF may select an MB-SMF to serve the MBS session through the NRF.; ¶ [0179] The MB-SMF may provide the NRF with the address or ID of the MB-SMF along with the MBS session ID.).
Baek does not explicitly teach wherein obtaining identification information of an MB-SMF associated with the MBS session from the MBSF comprises: providing an MBS session ID of the MBS session and location information of a terminal device associated with the MBS session to the MBSF; and
In analogous art, 3GPP teaches wherein obtaining identification information of an MB-SMF associated with the MBS session from the MBSF comprises: providing an MBS session ID of the MBS session and location information of a terminal device associated with the MBS session to the MBSF (§6.14.2.2, step 1, The MBS AF sends Nnef_MBSSessionStart Request (TMGI, Service Area, Session ID); step 2, The NEF sends Nmbsf_MBSSessionStart Request (Service Area, Session ID) message to each MBSF provided by the MBS AF in step 1.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine selecting identification information of MB-SMF taught by 3GPP with Multicast Broadcast Service, MBS, taught by Baek. One would have been motivated to do so in order to reduce latency and improve service continuity during mobility, which would improve the user’s experience, by allowing the network to route the MBS session to a locally suitable MBS-SMF based on the device’s location (3GPP: page 138).
Regarding claim 52, Baek teaches wherein obtaining an MBS session context for the MBS session from the MB-SMF identified by the identification information comprises : providing an MBS session ID of the MBS session and location information associated with a terminal device (read as UE) associated with the MBS session to the MB-SMF (Fig. 2A, operation 207 UL NAS: MB Session Join Request (TMGI, MBS service session ID); ¶ [0089] In operation 207, the UE may transmit a NAS message to the AMF to join the multicast session, and the AMF may select an appropriate MB-SMF and transfer a join request message for the multicast session received from the UE.; ¶ [0090] The join request message may include at least one of the MBS service session ID, which is information for the MBS service session to be joined.; ¶ [0119] To check if the UE is in the local MBS area, the AMF or the NG-RAN may keep the MB-SMF updated for the location information for the UE. For example, when the UE departs from the local MBS area, the MB-SMF may be notified thereof.); and
obtaining the MBS session context from the MB-SMF (¶ [0179] The MB-SMF may allocate an appropriate TMGI and generates a context for serving an MBS session.; ¶ [0181] The MB-SMF may transfer information generated for the MBS session service to the NEF/MBSF or the AF.).
Regarding claim 53, Baek teaches wherein the network function is an Access and Mobility Management Function, AMF, and wherein the message is a request to join the MBS session by a terminal device or a request to create UE context during a handover procedure; or the network function is a Session Management Function, SMF, and the message is a request to join the MBS session by a terminal device or a request to update session management context during a handover procedure (¶ [0089] The UE may transmit a NAS message to the AMF to join the multicast session.; ¶ [0184] When the UE sends a request for joining the MBS session through the SMF.; Note: MPEP 2143.03: When a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 92 USPQ2d 1163, 1171 (Fed. Cir. 2009).).
Regarding claim 54, Baek teaches a network node to implement Multicast Broadcast Service Function, MBSF (Fig. 5),
comprising:
one or more processors (Fig. 5, element 530 Controller; ¶ [0157] A network entity may include a controller 530.; ¶ [0158] The controller 530 may include one or more processors.); and
one or more memories comprising computer program codes (read as store programs and data) (Fig. 5, element 520 Memory; ¶ [0161] The memory 520 may store programs and data necessary for the operation of the network entity.),
the one or more memories and the computer program codes configured to, with the one or more processors, cause the network node (read as electronic device) to perform the method according to claim 36 (¶ [0186] One or more programs stored in the computer readable storage medium are configured to be executed by one or more processors in an electronic device. One or more programs include instructions that enable the electronic device to execute methods according to the embodiments.).
Regarding claim 55, Baek teaches network node to implement a network function comprising (Fig. 5):
one or more processors (Fig. 5, element 530 Controller; ¶ [0157] A network entity may include a controller 530.; ¶ [0158] The controller 530 may include one or more processors.); and
one or more memories comprising computer program codes (read as store programs and data) (Fig. 5, element 520 Memory; ¶ [0161] The memory 520 may store programs and data necessary for the operation of the network entity.),
the one or more memories and the computer program codes configured to, with the one or more processors, cause the network node to perform the method according to claim 48 (¶ [0186] One or more programs stored in the computer readable storage medium are configured to be executed by one or more processors in an electronic device. One or more programs include instructions that enable the electronic device to execute methods according to the embodiments.).
Regarding claim 56, Baek does not explicitly teach wherein the at least one MB-SMF is selected further based on local configuration.
In analogous art, 3GPP teaches wherein the at least one MB-SMF is selected further based on local configuration (§ 6.2.2.1, step 2, NEF/MBSF selects based on local configuration an MB-SMF.).
Claim 49 is rejected under 35 U.S.C. 103 as being unpatentable over Baek in view of 3GPP further in view of Li et al. (US 2023/0371098 A1; hereinafter Li).
Regarding claim 49, Baek and 3GPP do not explicitly teach wherein discovering an MBSF comprises: querying an NRF for identification information of the MBSF based on an MBS session ID of the MBS session.
In analogous art, Li teaches wherein discovering an MBSF (read as SMF that manages the multicast PDU session) comprises: querying an NRF for identification information of the MBSF based on an MBS session ID (read as identification information of the multicast PDU session) of the MBS session (¶ [0119] The identification information of the multicast group may be the identification of the multicast PDU session corresponding to the multicast group.; ¶ [0197] The AMF may send the identification information of the multicast group to the NRF. The NRF finds a correspondence between the identification information of the SMF and the identification information of the multicast group and determines the SMF as the SMF that manages the multicast PDU session.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine querying an NRF taught by Li with selecting identification information of MB-SMF taught by 3GPP and Multicast Broadcast Service, MBS, taught by Baek. One would have been motivated to do so in order to improve scalability and efficient management of an MBS session, which would improve the user’s experience, by using the NRF’s standardized registration and discovery mechanism to dynamically identify MBS related network functions based on session and service area information (Li: ¶¶ [0003-0006]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jia et al. (US 2023/0164640 A1) discloses “Communication Method and Communication Apparatus”
Kim et al. (US 2023/0209446 A1) discloses “Multicast-Related Communication”
Ma et al. (US 2022/0377508 A1) discloses “Methods and System for Multicast and Broadcast Service Establishment in Wireless Communication Networks
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID M KAYAL whose telephone number is (703)756-4576. The examiner can normally be reached M-F 8:30-5:30 ET.
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, Ricky Ngo can be reached at 571-272-3139. 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.
/D.M.K./Examiner, Art Unit 2464
/RICKY Q NGO/Supervisory Patent Examiner, Art Unit 2464
Prosecution Insights