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 .
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, 8-18 and 20 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, 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 the method, wherein the feature tag indicates the access network connection type of the UE is a non-terrestrial network connection (see 3GPP, page 16, section 6.2 b).
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 the method, wherein the feature tag indicates the access network connection type is a non-terrestrial connection (see 3GPP, page 16, section 6.2 b), and a codec having a lowest bit rate of the one or more codecs is prioritized by the network (i.e., Vander Mey teaches using access network type as a feature tag and prioritizing lower bit rate codecs for connections with lower throughput or higher latency) (see col. 10, line 55 through col. 11, line 25; Fig. 15).
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 from a UE, the one or more feature tags indicating at least one of: an access network connection type of the UE or one or more key performance indicators (KPIs) of a connection between an access network and 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.
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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Karimli et al., U.S. Patent Number 11,394,753 discloses dynamic rate adaptation during real-time LTE communication.
Park et al., U.S. Patent Number 11,330,020 discloses method for controlling codec on basis of channel conditions and electronic device.
Khay-Ibbat et al., U.S. Patent Number 9,253,238 discloses device-initiated codec rate change during a voice call.
Poulin, U.S. Publication Number 2013/0156119 A1 discloses methods, systems, and computer readable media for selecting a codec pair based on network conditions.
Dunne et al., U.S. Publication Number 2015/0264104 A1 discloses quality of experience for communication sessions.
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