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
This Action is in response to applicant’s amendment/arguments submitted on September 10, 2026. Claims 1-20 are still currently pending in the present application.
Response to Arguments
Applicant's arguments filed September 10th, 2026 have been fully considered but they are not persuasive.
Regarding independent claim 1, Applicant has amended the claim to recite, inter alia, “communicating a response message to the UE responsive to the register message, wherein the response message includes the one or more codecs selected based on the feature tag.” Applicant asserts on page 1 of the Remarks that the amendment renders the claim “additionally distinguishable over the cited combination of references.” However, Applicant does not articulate with specificity which limitation of the amended claim the cited combination fails to teach or suggest. The amendment adds the phrase “responsive to the register message,” which merely clarifies the temporal and causal relationship between the register message and the response message, a relationship that was already implicit in the previously rejected claim language and already addressed by the prior art combination. Specifically, 3GPP TS 24.292 V12.7.0 teaches that when a UE registers to the IM CN subsystem, it includes its capabilities in the Contact header field of the REGISTER message (§ 6.2, pg. 16), and the network processes this registration and returns a response. Page 29, paragraph 3 of 3GPP discloses that “upon receiving a SIP 200 (OK) response from the remote UE, the SCC AS shall send a SIP 200 (OK) response” to the ICS UE, demonstrating the network communicating a response message to the UE responsive to the received registration signaling. The SIP 200 (OK) response is, by definition, responsive to the SIP REGISTER request that initiated the registration transaction, as defined in IETF RFC 3261 § 10.3, which is incorporated by reference in 3GPP TS 24.229. Vander Mey further teaches communicating the codec selection back to the originating device as part of the call-establishment signaling flow at FIG. 12, blocks 1210–1220, where an offer is transmitted (block 1210), parameters including round-trip time are assessed (block 1215), an appropriate codec is selected, and the call is initiated using the selected codec (block 1220) (col. 11, ll. 50–60). The selected codec must necessarily be communicated to the UE to enable the call, constituting a response message including the selected codecs responsive to the initial message. The combination of 3GPP’s registration-and-response framework with Vander Mey’s codec-selection-and-communication flow renders the amended limitation obvious. Adding the phrase “responsive to the register message” does not introduce a new structural or functional limitation that distinguishes over the combination. The rejection of claim 1 is therefore maintained.
With respect to independent claim 10, Applicant argues on page 2 of the Remarks that the cited combination fails to teach “selecting, based on the feature tag [indicating an access network connection type of the UE], the one or more codecs supported by the UE.” This argument is not persuasive. Applicant’s argument appears to rest on the premise that neither reference teaches selecting codecs based on a feature tag that indicates access network connection type. However, the combination teaches precisely this. Vander Mey teaches codec selection based on access-network-type information at col. 10, ll. 60–64, which discloses that “Signal strength, the existence of a WiFi connection, previous codecs used, etc., may also be taken into consideration” for codec selection. The existence of a WiFi connection is an access network connection type indicator distinguishing WiFi from cellular access. Col. 11, ll. 26–43 and FIG. 11 further disclose a codec selector (1110) that receives multiple inputs (1105a–c), including connection-type information, and maps them through a multidimensional space (1130) to select an appropriate codec (1115), with the codec selection expressly based on the access network connection characteristics of the UE. 3GPP teaches encoding the access network connection type as a discrete feature tag at § 6.2(b), pg. 16, which discloses “a .3gpp.accesstype media feature tag set to one of the following text strings based on the access network technology being used by the UE to register,” namely “wlan,” “cellular,” “docsis,” “dsl,” or “ethernet.” The combination operates such that 3GPP provides the mechanism by which the UE communicates its access network connection type to the network as a structured feature tag in a signaling message, while Vander Mey provides the substantive teaching that the network uses access-network-type information to select appropriate codecs. A person of ordinary skill in the art would find it obvious to use the access-type information conveyed via 3GPP’s feature tag as an input to Vander Mey’s codec selection process. Under MPEP § 2143(I)(A), combining prior art elements (feature-tag-based access-type signaling plus access-type-informed codec selection) according to known methods yields the predictable result of codec selection based on the feature tag indicating an access network connection type. Applicant does not identify any specific limitation of claim 10 that is absent from this combination, nor does Applicant explain why the combination’s teaching is insufficient. The conclusory assertion that the references “fail to disclose, teach, or suggest” the recited limitation does not constitute a substantive traversal under 37 C.F.R. § 1.111(b). The rejection of claim 10 is therefore maintained.
Turning to dependent claims 12 and 18, Applicant argues on pages 3–4 of the Remarks that 3GPP TS 24.292 V12.7.0 does not teach or suggest “non-terrestrial” or “satellite” access types, and that the Examiner’s citation to Section 6.2(b) for the non-terrestrial limitation is unsupported. Applicant specifically notes that the bulleted list in 3GPP recites only “wlan,” “cellular,” “docsis,” “dsl,” and “ethernet,” and that 3GPP does not mention “nonterrestrial,” “non-terrestrial,” or “satellite” anywhere in its disclosure. Applicant further argues that even under the combination with Vander Mey, the feature tag would at most read “cellular” and would fail to distinguish between terrestrial and non-terrestrial connection types, and that neither reference describes selecting one or more codecs based on the access network connection type being non-terrestrial.
Applicant’s arguments have been fully considered but are not persuasive. Claims 12 and 18 were not amended and are rejected on the same grounds using the same references, with a more detailed explanation of the rationale as set forth in the updated rejection below. To summarize: first, Applicant’s own specification at paragraphs [0030] and [0032], as acknowledged by Applicant in the Remarks at page 3, footnote 3, establishes that UEs communicate with non-terrestrial nodes using cellular access technology, meaning that under 3GPP’s framework the .3gpp.accesstype feature tag set to “cellular” encompasses non-terrestrial connections employing cellular protocols. Second, under Broadest Reasonable Interpretation per MPEP § 2111, the claim does not require the feature tag to explicitly recite “non-terrestrial” as a discrete text string; a feature tag conveying access technology information from which the non-terrestrial nature of the connection can be determined satisfies the limitation. Third, extending 3GPP’s expressly extensible access-type framework to include a non-terrestrial category is obvious to try under MPEP § 2143(I)(E), as the set of possible access types is finite and well-known, and the framework already demonstrates extensibility. Fourth, Vander Mey’s technology-agnostic KPI-based codec selection system would handle a non-terrestrial connection’s characteristic quality profile in the same manner as any degraded or constrained connection, and the lowest-bitrate-codec prioritization recited in claim 18 is the natural result of applying Vander Mey’s system to such a profile. The rejections of claims 12 and 18 are therefore maintained on the same grounds with the strengthened rationale detailed below.
Regarding independent claim 20, as amended, Applicant has added the limitations “wherein the access network connection type is a non-terrestrial access network connection type” and “select, based on the one or more feature tags indicating the non-terrestrial access network connection type, the one or more codecs supported by the UE.” Applicant argues on page 3 of the Remarks that the amendment renders the claim additionally distinguishable over the cited combination. In response to Applicant’s amendment, the Examiner has applied
Zheng et al., U.S. Patent Application Publication No. 2026/0172815 A1 in a new ground of rejection necessitated by the amendment. The combination of Vander Mey, 3GPP, and Zheng renders amended claim 20 obvious, as detailed in the rejection below. This new ground of rejection is necessitated by Applicant’s amendment and does not preclude finality of this Office Action.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2 and 8-18 are rejected under 35 U.S.C. 103 as being unpatentable over Vander Mey et al., U.S. Patent Number 9,667,801 A1 (hereinafter Vander Mey) and in view of 3GPP TS 24.292 V12.7.0 (hereinafter 3GPP).
Regarding claims 1, 2 and 10, Vander Mey discloses a method for selecting one or more codecs during registration (see fig. 12; expressly describes a process for selecting an initial codec for a VoIP connection prior to call establishment), the method comprising:
receiving, at a network, an offer message from a UE, wherein the offer message comprises a feature tag indicating one or more key performance indicators (KPIs) of a connection (i.e., Vander Mey's offer message carries connection performance information from the UE that is functionally equivalent to a feature tag indicating KPIs) (see col. 10, lines 55-67 and col. 22, lines 26-44 and figs. 7-9) between the UE and an access network exceeding a pre-determined threshold (i.e., Vander Mey discloses that codec selection is conditioned on connection quality meeting certain levels. Col. 10, lines 36-40 states that "[b]ased on these factors, a codec having appropriate attributes may be selected," implying that the values of the KPIs are assessed relative to the requirements of available codecs which necessarily involves implicit threshold-based evaluation. Col. 11, lines 26-43 and fig. 11 illustrates a codec selector (1110) that maps a multidimensional input space (1130) of network and device parameters to a codec output, which inherently requires comparing input values against criteria or thresholds associated with each codec option);
selecting, based on the feature tag, the one or more codecs supported by the UE (i.e., Vander Mey discloses codec selection based on received connection-type and KPI inputs. Specifically, the codec selector (1110) maps inputs (1105a–c) (including, e.g., the latency of the offer packet, the locations of the user devices, the preferences of the users (such as the minimum acceptable quality), etc.) to a codec selection (1115) using a multidimensional input space (1130). Vander Mey states that "[b]ased on these factors, a codec having appropriate attributes may be selected." The FIG. 12 flowchart further discloses the operational flow of selecting a codec (block 1220) after assessing the pre-call parameters including connection type and latency KPIs) (see col. 10, lines 26-41, col. 11, lines 26-42, col. 11, line 50 through col. 12, line 20 and figs. 11 & 12); and
communicating a response message to the UE, responsive to the register message, wherein the response message includes the one or more codecs selected based on the feature tag (i.e., Vander Mey discloses the completion of an offer-and-acknowledgment signaling sequence in which the selected codec is communicated back to the originating device. FIG. 12 (blocks 1210–1220) disclose the operational flow in which: an offer is received (block 1210), parameters are assessed (block 1215), and a call is initiated using the selected codec (block 1220) (see col. 10, lines 26-41 and col. 11, line 44 through col. 12, line 20).
To the extent Vander Mey does not expressly disclose a formal registration procedure, wherein the register message comprises a "feature tag" as a discrete data field in the offer message, it would have been obvious to one of ordinary skill in the art that encoding the access network connection type as a standardized tag or parameter within a SIP offer or similar signaling message is a routine implementation detail, given Vander Mey’s explicit teaching that this connection-type information is gathered and used for codec selection.
In an analogous field of endeavor, 3GPP teaches a method comprising: receiving, at a IMS network, a register message from a UE (if ICS is enabled for the UE, then the ICS UE registers to IM CN and includes its capabilities in the contact header field; Pg. 16; Section 6.2); selecting, based on the feature tag (access technology will be selected based on the feature tag; Pg. 16; Section 6.2); and communicating a response message to the UE (upon
receiving a SIP 200 response from the remote UE, the SCC AS shall send the SIP 200 response to the ICS UE; Pg. 29; Para. 3).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Vander Mey with 3GPP by implementing a formal registration procedure in which the register message comprises a "feature tag" as a discrete, standardized field in the signaling message. 3GPP explicitly teaches the use of standardized fields for conveying access network and capability information, and Vander Mey clearly describes the use of such information for codec selection. Incorporating a standardized feature tag into the signaling protocol would predictably enhance protocol interoperability, system robustness, and clarity of communication between endpoints. This modification would facilitate more reliable and efficient codec selection, reduce ambiguity in signaling, and ensure compatibility with evolving communication systems.
Regarding claims 8 and 13, Vander Mey in view of 3GPP teaches all the limitations of claims 1 and 10. The combination further teaches wherein based on the feature tag, the network prioritizes the one or more codecs from lowest bit rate to highest bit rate (i.e., Vander Mey teaches that codec selection is based on connection attributes such as latency, bandwidth, and signal quality (see Vander Mey col. 10, lines 36–41; col. 11, lines 26–43; Figs. 11–12). Fig. 15 illustrates codec selection as a function of available bitrate, with lower bit rate codecs prioritized for lower quality connections and higher bit rate codecs for better connections).
Regarding claim 9, Vander Mey in view of 3GPP teaches all the limitations of claim 8. The combination further teaches the method, further comprising: based on one or more updated KPIs exceeding the pre-determined threshold, communicating, by the UE, an update register message to the network, wherein the update register message includes an updated feature tag (i.e., Vander Mey describes monitoring connection quality and updating codec selection as network conditions change (see col. 12, lines 1–20; Figs. 12, 27, 29). The system records and uses updated parameters for future sessions (see col. 12, lines 5–20). While "register message" and "feature tag" as explicit fields are not called out, the offer and update signaling described is functionally equivalent: the UE communicates updated connection information to the network, which is used for codec selection.
Furthermore, 3GPP teaches a method comprising: receiving, at a network, a register message from a UE (if ICS is enabled for the UE, then the ICS UE registers to IM CN and includes its capabilities in the contact header field; Pg. 16; Section 6.2); selecting, based on the feature tag (access technology will be selected based on the feature tag; Pg. 16; Section 6.2); and communicating a response message to the UE (upon receiving a SIP 200 response from the remote UE, the SCC AS shall send the SIP 200 response to the ICS UE; Pg. 29; Para. 3).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Vander Mey with 3GPP to include communicating, by the UE, an update register message to the network, wherein the update register message includes an updated feature tag as a discrete, standardized field in the signaling message. 3GPP explicitly teaches the use of standardized fields for conveying access network and capability information, and Vander Mey clearly describes the use of such information for codec selection. Incorporating a standardized feature tag into the signaling protocol would predictably enhance protocol interoperability, system robustness, and clarity of communication between endpoints. This modification would facilitate more reliable and efficient codec selection, reduce ambiguity in signaling, and ensure compatibility with evolving communication systems.
Regarding claim 11, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches the method, wherein the feature tag is located in a contact header of the message from the UE (i.e., 3GPP teaches a method comprising: receiving, at a network, a register message from a UE (if ICS is enabled for the UE, then the ICS UE registers to IM CN and includes its capabilities in the contact header field; Pg. 16; Section 6.2); selecting, based on the feature tag (access technology will be selected based on the feature tag; Pg. 16; Section 6.2); and communicating a response message to the UE (upon receiving a SIP 200 response from the remote UE, the SCC AS shall send the SIP 200 response to the ICS UE; Pg. 29; Para. 3)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Vander Mey with 3GPP to include a method wherein the feature tag is located in the contact header of the message from the UE. Implementing the feature tag in this standardized location would predictably enhance protocol interoperability, improve system robustness, and increase the clarity of communication between endpoints. This modification would facilitate more reliable and efficient codec selection, reduce ambiguity in signaling, and ensure compatibility with evolving communication systems.
Regarding claim 12, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches wherein the feature tag indicates the access network connection type of the UE is a non-terrestrial network connection, for the following reasons.
First, Applicant’s own specification establishes that non-terrestrial connections employ cellular access technology. As Applicant acknowledges in the Remarks at page 3, footnote 3, citing specification paragraphs [0030] and [0032], UEs “may communicate with” non-terrestrial nodes “using any wireless telecommunications protocol desired,” such as cellular protocols “4G, 5G, [and] 6G.” Under 3GPP § 6.2(b), the .3gpp.accesstype feature tag is set to “cellular” when the UE is using cellular access technology. Because Applicant’s own disclosure confirms that non-terrestrial connections use cellular access technology, the “cellular” feature tag encompasses and indicates connections made via non-terrestrial infrastructure when the UE employs a cellular protocol stack. Under Broadest Reasonable Interpretation (MPEP § 2111), the claim does not require the feature tag to explicitly recite the text string “non-terrestrial”; a feature tag conveying information from which the non-terrestrial nature of the connection can be determined satisfies this limitation, particularly when associated with the high-latency, constrained-bandwidth, and packet-loss characteristics distinctive of non-terrestrial links that Vander Mey teaches as KPI factors (col. 10, ll. 55–67; col. 11, ll. 1–6).
Second, to the extent 3GPP § 6.2(b) does not expressly enumerate “non-terrestrial” as a discrete text string, extending the framework to include such a value would have been obvious to try under MPEP § 2143(I)(E) and KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007). The set of possible access network connection types is finite and well-known, and 3GPP’s framework is expressly extensible, as shown by the requirement that the UE “shall append a unique numerical single digit value for each registration flow to the text string value above (e.g ‘wlan1’)” (§ 6.2(b), pg. 16). A person of ordinary skill in the art confronted with the known need to support non-terrestrial access would find it obvious to add a corresponding text string value to the existing enumerated list, as this represents one of a finite number of identified, predictable solutions within an established and extensible framework.
Third, Vander Mey’s codec selection system is technology-agnostic and responds to connection quality parameters regardless of the underlying access infrastructure. Non-terrestrial connections are functionally characterized by high latency, constrained bandwidth, and distinct packet loss profiles the same parameters Vander Mey teaches as driving codec selection (col. 10, ll. 55–67; col. 13, ll. 36–40; FIG. 14; col. 14, ll. 13–36). The claim merely labels the connection type as “non-terrestrial,” which does not alter the functional operation of Vander Mey’s codec selection system.
Regarding claim 14, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches the method, wherein the access network connection type of the UE is a cell edge connection (see Vander Mey, col. 23, lines 36-47 and fig. 22).
Regarding claim 15, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches the method, wherein the access network connection type of the UE is a mobile hotspot network connection (see Vander Mey, col. 10, lines 31-36 & 60-64).
Regarding claim 16, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches the method, wherein the access network connection type of the UE is a public Wi-Fi network connection (see Vander Mey, col. 10, lines 31-36 & 60-64).
Regarding claim 17, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches the method, wherein the feature tag indicates the access network connection type is a 5G terrestrial connection (see 3GPP, page 16, section 6.2 b), and wherein a codec having a highest bit rate of the one or more codecs is selected (i.e., Vander Mey teaches using access network type (e.g., high-capacity connections) to select the most appropriate codec) (see col. 10, lines 26–41; col. 11, lines 7–17 and Figs. 11–12).
Regarding claim 18, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination further teaches wherein the feature tag indicates the access network connection type is a non-terrestrial connection for the reasons set forth in the rejection of claim 12 above. The combination further teaches that a codec having a lowest bit rate of the one or more codecs is prioritized by the network. Vander Mey teaches that codec selection is driven by connection quality characteristics, with lower-bitrate codecs selected for connections exhibiting higher latency and lower bandwidth (col. 10, ll. 55–67; col. 13, ll. 36–40: “if the measured packet error loss of the network goes above a pre-determined threshold (e.g., 10% packet loss rate during some period of time), then the method 1300 may decide to switch”; FIG. 14; col. 14, ll. 13–36: codec selection regions R1–R3 with explicit bitrate boundary values B0–B3). Non-terrestrial satellite connections are well-known to exhibit significantly higher latency and potentially constrained bandwidth compared to terrestrial connections. A person of ordinary skill in the art would understand that when the feature tag indicates a non-terrestrial connection type, the network would prioritize the lowest bitrate codec as the natural and predictable result of applying Vander Mey’s KPI-driven codec selection framework to the characteristic quality profile of a satellite link.
Claims 3, 4, 5, 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Vander Mey et al., U.S. Patent Number 9,667,801 A1 (hereinafter Vander Mey) and in view of 3GPP TS 24.292 V12.7.0 (hereinafter 3GPP) as applied to claim 1 above, and further in view of Badic et al., U.S. Patent Number 11,641,644 (hereinafter Badic).
Regarding claims 3, 4, 5, 6 and 7, Vander Mey in view of 3GPP teaches all the limitations of claim 1. The combination fails to explicitly teach wherein the one or more KPIs comprise a received signal strength indicator (RSSI), a reference signal received quality (RSRQ), a packet loss measure, a data throughput measure and a signal to noise ratio (SNR).
In analogous field of endeavor, Badic teaches a performance event may, in some aspects, be based on a received signal strength indicator (RSSI), a reference signal receive power (RSRP), a reference signal receive quality (RSRQ), a channel quality indicator (CQI), a packet loss rate (PLR), a bit error rate (BER), a block error rate (BLER), signal to noise ratio (SINR), a downlink throughput, an uplink throughput, a signal to noise ratio (S/R), a carrier to noise ratio (C/N), an interference to noise ratio (C/N), a handover duration, a handover success rate, minutes of user per dropped call (MOU), and/or other key performance indicators (KPIs), among others (see col. 267, lines 31-41).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the teachings of Badic with Vander Mey and 3GPP, wherein the one or more KPIs comprise a received signal strength indicator (RSSI), a reference signal received quality (RSRQ), a packet loss measure, a data throughput measure, and a signal to noise ratio (SNR), in order to provide a more comprehensive and fine-grained assessment of connection quality for codec selection and network management. Incorporating these well-known KPIs, as specifically enumerated and taught by Badic, would enable the system to make more accurate, robust, and context-aware decisions regarding codec selection and network operation. This modification would predictably improve the reliability, efficiency, and adaptability of the communication system, as it would allow for dynamic optimization based on real-time network conditions and user experience metrics.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Vander Mey et al., U.S. Patent Number 9,667,801 A1 (hereinafter Vander Mey) and in view of 3GPP TS 24.292 V12.7.0 (hereinafter 3GPP) as applied to claim 10 above, and further in view of Drozt et al., U.S. Patent Number 9,392,576 (hereinafter Drozt).
Regarding claim 19, Vander Mey in view of 3GPP teaches all the limitations of claim 10. The combination fails to explicitly teach the method, wherein the codec having the lowest bit rate of the one or more codecs is configured to provide push to talk.
In analogous field of endeavor, Drozt teaches, in the context of a 3GPP-compliant system supporting group communications and Push-to-Talk (PTT) over a shared MBMS bearer, that the infrastructure device (e.g., PTT call controller) dynamically manages codec selection and bearer resources. Drozt expressly describes that, to maximize the number of simultaneous PTT group calls, the system can instruct sources of active media streams to switch to a lower bit rate codec for PTT sessions. Drozt further explains that low bit rate codecs are particularly suited for PTT services in bandwidth-constrained scenarios (see col. 13, lines 50-64 and Fig. 6).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Vander Mey and 3GPP with those of Drozt to configure the codec having the lowest bit rate among the available codecs for use in push-to-talk (PTT) applications. Drozt clearly demonstrates the suitability and industry practice of using low bit rate codecs for PTT to minimize bandwidth usage while maintaining acceptable voice quality. Incorporating this teaching into the system of Vander Mey and 3GPP would predictably optimize resource utilization, enable efficient group communications and reliable PTT operation, especially under constrained network conditions.
Claim 20 is rejected under 35 U.S.C. § 103 as being unpatentable over Vander Mey et al., U.S. Patent Number 9,667,801 (hereinafter “Vander Mey”) in view of 3GPP TS 24.292 V12.7.0 (hereinafter “3GPP”), and further in view of Zheng et al., U.S. Patent Application Publication No. 2026/0172815 A1 (hereinafter “Zheng”).
Regarding claim 20, Vander Mey discloses a system for selecting one or more codecs, the system comprising: one or more computer processing components configured to perform operations comprising (see col. 3, lines 1-2, col. 11, lines 26-35 and fig. 11; depicts a codec selector (1110) implemented on "one or more user client devices and/or at a server" and fig. 30; discloses a computer system used to implement the embodiments);
receive one or more feature tags in a message from a UE, the one or more feature tags indicating at least one of: an access network connection type of the UE (Vander Mey discloses receiving an offer message transmitted from a user device (UE) to another device or server over a network. Specifically, Vander Mey discloses that "a non-media packet, referred to herein as the 'offer' or 'proposal', may be sent from one user's device to another user's device." Vander Mey further discloses that attributes of this offer message are analyzed to infer channel conditions, explicitly including "the existence of a WiFi connection" as a factor. The WiFi connection indicator constitutes a feature tag indicating the access network connection type (i.e., WiFi vs. cellular) of the UE) (see col. 10, lines 26-41 and col. 11, lines 7-17); and
select, based on the one or more feature tags, the one or more codecs supported by the UE (i.e., Vander Mey discloses codec selection based on received connection-type and KPI inputs. Specifically, the codec selector (1110) maps inputs (1105a–c) (including, e.g., the latency of the offer packet, the locations of the user devices, the preferences of the users (such as the minimum acceptable quality), etc.) to a codec selection (1115) using a multidimensional input space (1130). Vander Mey states that "[b]ased on these factors, a codec having appropriate attributes may be selected." The FIG. 12 flowchart further discloses the operational flow of selecting a codec (block 1220) after assessing the pre-call parameters including connection type and latency KPIs) (see col. 10, lines 26-41, col. 11, lines 26-42, col. 11, line 50 through col. 12, line 20 and figs. 11 & 12).
To the extent Vander Mey does not expressly disclose a "feature tag" as a discrete data field in the offer message, it would have been obvious to one of ordinary skill in the art that encoding the access network connection type as a standardized tag or parameter within a SIP offer or similar signaling message is a routine implementation detail, given Vander Mey’s explicit teaching that this connection-type information is gathered and used for codec selection.
In an analogous field of endeavor, 3GPP teaches a method comprising: receiving, at a network, a register message from a UE (if ICS is enabled for the UE, then the ICS UE registers to IM CN and includes its capabilities in the contact header field; Pg. 16; Section 6.2); selecting, based on the feature tag (access technology will be selected based on the feature tag; Pg. 16; Section 6.2); and communicating a response message to the UE (upon
receiving a SIP 200 response from the remote UE, the SCC AS shall send the SIP 200 response to the ICS UE; Pg. 29; Para. 3).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date, to combine the teachings of Vander Mey with 3GPP by implementing the "feature tag" as a discrete, standardized field in the signaling message. 3GPP explicitly teaches the use of standardized fields for conveying access network and capability information, and Vander Mey clearly describes the use of such information for codec selection. Incorporating a standardized feature tag into the signaling protocol would predictably enhance protocol interoperability, system robustness, and clarity of communication between endpoints. This modification would facilitate more reliable and efficient codec selection, reduce ambiguity in signaling, and ensure compatibility with evolving communication systems.
The combination of Vander Mey and 3GPP does not expressly teach “wherein the access network connection type is a non-terrestrial access network connection type” or “select, based on the one or more feature tags indicating the non-terrestrial access network connection type, the one or more codecs supported by the UE.”
In an analogous field of endeavor, Zheng teaches a capability synchronization method and system for a communication system that includes user equipment (UE), non-terrestrial network (NTN) devices, and terrestrial network devices (¶ [0006]; FIG. 1).
Zheng expressly teaches that UEs support a non-terrestrial network communication function and can “perform communication via a satellite in an area that is not covered or cannot be covered with mobile communication” (¶ [0003]). Zheng teaches that the radio access network may be classified into a terrestrial network RAN (TN-RAN) device and a non-terrestrial network RAN (NTN-RAN) device, where the NTN-RAN device includes “a satellite and a terrestrial transceiver station” (¶ [0060]). Zheng teaches that the UE sends a registration request message to the network that “includes network capability information of the SIM 3 of the UE 100, indicating that the UE 100 supports NTN communication” (¶ [0304]; S701), and that the network, upon receiving this message, “determines that the UE 100 has a capability of communicating with the NTN” (¶ [0307]; S702). Zheng further teaches that the network obtains NTN air interface capability information of the UE, which includes parameters such as “a carrier supported by the UE, an antenna polarization direction of the UE, maximum transmit power of the UE, and a duplex mode of the UE” (¶ [0026]), and that the NTN core network and NTN-RAN “may configure an air interface resource and a communication mode for the UE based on the NTN air interface capability information” (¶ [0119]; ¶ [0212]). These teachings establish that the access network connection type of the UE is a non-terrestrial access network connection type and that the UE communicates this non-terrestrial access type to the network via structured capability information in a registration-context message.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Vander Mey and 3GPP to include a non-terrestrial access network connection type, as taught by Zheng, and to select codecs based on a feature tag indicating the non-terrestrial access network connection type. Zheng demonstrates that non-terrestrial network access via satellite is a recognized and established access type in modern telecommunications systems, and that UEs communicate their NTN capability to the network during registration (¶¶ [0304], [0307]). A person of ordinary skill in the art would have been motivated to incorporate Zheng’s teaching of NTN access type indication into the feature-tag registration framework of 3GPP and the codec selection system of Vander Mey because doing so would predictably enable the system to identify UEs connected via satellite and adjust codec selection to accommodate the characteristic quality profile of non-terrestrial links, such as higher latency and potentially constrained bandwidth. Vander Mey teaches that codec selection is driven by connection quality characteristics (col. 10, ll. 55–67; col. 11, ll. 26–43; col. 13, ll. 36–40), and a PHOSITA would recognize that non-terrestrial connections have distinctive quality profiles warranting different codec selections. Under MPEP § 2143(I)(A), combining known elements (feature-tag-based access-type signaling from 3GPP, KPI-driven codec selection from Vander Mey, and NTN access type identification and capability exchange from Zheng) according to known methods yields the predictable result of codec selection responsive to a non-terrestrial connection type indicator.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anthony Addy whose telephone number is (571) 272-7795. The examiner can normally be reached Mon – Fri 8:00-5:00. 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. 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.
/ANTHONY S ADDY/Supervisory Patent Examiner, Art Unit 2645
Prosecution Insights