DETAILED ACTION
Applicant’s amendment and arguments filed September 18, 2025 is acknowledged.
Claims 1, 3, 5, 8-10, 12, 13, 28, 36, 37, and 44-46 have been amended.
Claims 6, 7, 11, 17-27, 30-35, and 38-43 are cancelled as previously indicated.
Claims 1-5, 8-10, 12-16, 28, 29, 36, 37, and 44-46 are currently pending.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 of this title, 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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, 3-5, 8-9, 12, 13, 28, 29, 36, 37, 45, and 46 are rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (hereinafter Qiao) (U.S. Patent Application Publication # 2021/0258828 A1) in view of RYU et al. (hereinafter Ryu) (U.S. Patent Application Publication # 2022/0338084 A1), and further in view of GANGAKHEDKAR et al. (hereinafter Gangkhedkar) (U.S. Patent Application Publication # 2021/0314815 A1).
Regarding claims 1 and 28, Qiao teaches a method and communications device (UE, figures 1-2) for use in a wireless communications network (wireless network, figures 1-2), the wireless communications network comprising an infrastructure equipment (network infrastructure devices such as RAN, figures 1-2) providing a wireless access interface, the communications device (UE, figures 1-2) comprising a transmitter (312, figure 3) configured to transmit data via the wireless access interface, a receiver (312, figure 3) configured to receive signals, and a controller (314, figure 3) configured to control the transmitter and the receiver so that the communications device is configured to:
identify within data for transmission on the wireless access interface a data frame having a protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN) ([0150]; “…An Ethernet frame may start with an Ethernet header, which contains destination and source MAC addresses as its first two fields. The middle section of the frame may be payload data including any headers for other protocols…” [0170]; [0177]; teaches identifying data for transmission included in an Ethernet frame comprising a plurality of header fields for transmission within a LAN; figure 9),
determine a selected first profile for header compression, the selected first profile for header compression being selected from a plurality of predetermined profiles and to form a compressed data frame for transmission on a wireless access interface of the wireless communications network, apply compression to the protocol header fields of the first data frame in accordance with the selected first profile for header compression a first compressed data frame for transmission on a wireless access interface of the wireless communication network; determine a second selected profile for header compression from the plurality of determined profiles ([0163]; “…PDCP PDU routing (in case of split bearers)…duplication of PDCP PDUs…”; teaches and suggests duplication of PDCP PDUs for subsequent header compression; [0164]; “…the header compression protocol may be based on the Robust Header Compression (ROHC) framework…There may be multiple header compression algorithms, called profiles, defined for the ROHC framework…”; [0166]-Table 1; [0168]; [0186]; “…the PDCP-Config IE may comprise the profile(s) for the header compression…”; [0187]; “…Ethernet profile configuration IE may comprise information about…one or more parameters on Ethernet packet header compression, and/or the profile identifier(s)…” [0279]; teaches selecting a profile for header compression from a plurality of profiles for each data frame and applying compression for transmission of the data frame in the wireless network), and
form a first packet data convergence protocol (PDCP) protocol data unit (PDU) comprising the first compressed data frame ([0193]; “…action may comprise constructing a PDCP PDU comprising at least the compressed header, the payload…”; [0194]; [0256]; teaches constructing a PDCP PDU comprising the compressed data frame).
However, Qiao may not explicitly disclose duplicate the data frame to form a first data frame and a second data frame, apply compression to the protocol header fields of the second data frame in accordance with the second selected profile for header compression to form a second compressed data frame for transmission on the wireless access interface, and form a second PCDP PDU comprising the second compressed data frame (although Qiao does suggest PDCP PDU routing in case of split bearers and duplication of PDCP PDUs; “…PDCP PDU routing (in case of split bearers)…duplication of PDCP PDUs…”; [0063]).
Nonetheless, in the same field of endeavor, Ryu teaches and suggests duplicate the data frame to form a first data frame and a second data frame, apply compression to the protocol header fields of the second data frame in accordance with the second selected profile for header compression to form a second compressed data frame for transmission on the wireless access interface, and form a second PCDP PDU comprising the second compressed data frame ([0380]; “…PDCP sub layer for a user plane performs…header compression and decompression (only for Robust Header Compression (RoHC))…PDCH PDU routing (for split bearer)…PDCP PDU copy…”; [0381]; [0382]; “…In the PDCP, the duplication includes a transmission of the same PDCP PDU(s) twice…”; teaches duplicating data frames to form separate PDCP PDUs in which header compression, RoHC, has been applied according to a profile for header compression associated with RoHC, to each of the duplicated data frames).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate duplicating data frames to form separate PDCP PDUs in which header compression, RoHC, has been applied according to a profile for header compression associated with RoHC, to each of the duplicated data frames as taught by Ryu with the method for header compression as disclosed by Qiao for the purpose of ensuring proper transmission and reducing overhead and radio resource waste, as suggested by Ryu.
However, Qiao, as modified by Ryu, may not explicitly disclose determining a first selected profile for header compression based on an indication of decompression success with respect to previously transmitted data frames and the indication of decompression success is received in a PDCP header of an uplink frame, each of the plurality of predetermined profiles specifying a subset of the protocol header fields, and apply compression to a subset of the protocol header fields of the first data frame in accordance with the selected first profile for header compression; and apply compression to at least a subset of the protocol header fields of the second data frame in accordance with the second selected profile for header compression, wherein the first PDCP PDU comprises an indication of the selected first profile for header compression, the second PDCP PDU comprises an indication of the second selected profile for header compressing (although Qiao does suggest the selected profile is indicated in the header of the transmitted packet and decompression acknowledgement).
Nonetheless, in the same field of endeavor, Gangkhedkar teaches and suggests determining a first selected profile for header compression based on an indication of decompression success (feedback/ACK) with respect to previously transmitted data frames and the indication of decompression success (feedback/ACK) is received in a PDCP header of an uplink frame (uplink/feedback ACK) ([0035]; [0037]; [0055]; [0105]; teaches determining the profile for header compression based on an indication, such as an ACK, indicating successful decompression with respect to a previously transmitted data packet), each of the plurality of predetermined profiles specifying a subset of the protocol header fields (static fields) ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields), and apply compression to a subset of the protocol header fields of the first data frame in accordance with the selected first profile for header compression ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields); and apply compression to at least a subset of the protocol header fields of the second data frame in accordance with the second selected profile for header compression ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields), wherein the first PDCP PDU comprises an indication of the selected first profile for header compression, the second PDCP PDU comprises an indication of the second selected profile for header compression ([0035]; [0055]; [0105]; teaches the compression profile is signaled in the PDCP PDU).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the compression profiles specifies a subset of fields, such as static fields, and the compression profile is signaled in the PDCP PDU and determining the profile for header compression based on an indication, such as an ACK, indicating successful decompression with respect to a previously transmitted data packet as taught by Gangkhedkar with the method for header compression as disclosed by Qiao, as modified by Ryu, for the purpose of providing a compression method about how to select to make a decompressing party decompress the data packets with the minimum memory space, as suggested by Gangkhedkar.
Regarding claim 3, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests transmitting the first compressed data frame and the second compressed data frame on the wireless access interface ([0164]; [0166]; [0187]; [0276]; teaches selecting a profile header compression and applying compression for transmission of data in the wireless network).
Regarding claim 4, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests wherein the frame format is an Ethernet or IEEE 802.3 frame format (figure 9; [0150]; teaches Ethernet frame format).
Regarding claim 5, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests transmitting an indication of at least one of the selected first profile for header compression or the selected second profile for header compression ([0166]; [0187]; [0244]; teaches transmitting the indication of the profile for header compression).
Regarding claim 8, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests determining whether conditions for modifying at least one of the selected first profile for header compression or selected second profile header for header compression are satisfied and, if the conditions for modifying are satisfied, modifying the at least one of the selected first profile for header compression or the second selected profile for header compression and repeating steps a)-g) for subsequent data in accordance with the modified at least one of the first selected profile for header compression or selected second profile header for header compression ([0164]; [0166]; [0187]; [0244]; [0276]; teaches modifying the selected profile header compression).
Regarding claim 9, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests wherein modifying at least one of the first selected profile for header compression or the second profile for header compression comprises selecting from the plurality of predetermined profiles the modified at least one of the first selected profile for header compression or selected second profile for header compression ([0166]; [0187]; [0244]; [0265]; teaches selecting a modified profile for header compression).
Regarding claim 12, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests determining a number of sequential frames that have been compressed in accordance with the at least one of the first selected profile for header compression or second selected profile for header compression since a most recent modification thereof, wherein the conditions for modifying the at least one of the first selected profile for header compression or second selected profile for header compression comprise conditions based on the determined number ([0163]; teaches sequence numbering of frames according to the profile).
Regarding claim 13, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests wherein the conditions for modifying the at least one of the first selected profile for header compression or second selected profile for header compression comprise conditions based on a current first selected profile for header compression and a current second selected profile for header compression ([0166]; [0187]; [0244]; [0265]; teaches selecting a modified profile for header compression based on the UE header compression capability).
Regarding claim 29, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests wherein the controller is configured to control the transmitter so that the communications device is operable to transmit the first compressed data frame and the second compressed data frame on the wireless access interface ([0164]; [0166]; [0187]; [0276]; teaches selecting a profile header compression and applying compression for transmission of data in the wireless network).
Regarding claim 36, Qiao teaches infrastructure equipment (network infrastructure devices such as RAN, figures 1-2) for use in a wireless communications network (wireless network, figures 1-2), the infrastructure equipment providing a wireless access interface, the infrastructure equipment comprising a transmitter configured to transmit signals to a communications device (UE, figures 1-2) via the wireless access interface in a cell, a receiver (312, figure 3) configured to receive data from the communications device, and a controller (314, figure 3), configured to control the transmitter and the receiver so that the infrastructure equipment is operable:
identify within data for transmission on the wireless access interface a data frame having a protocol header, the protocol header comprising a plurality of protocol header fields and associated with a medium access control (MAC) frame format for data transmission within a local area network (LAN) ([0150]; “…An Ethernet frame may start with an Ethernet header, which contains destination and source MAC addresses as its first two fields. The middle section of the frame may be payload data including any headers for other protocols…” [0170]; [0177]; teaches identifying data for transmission included in an Ethernet frame comprising a plurality of header fields for transmission within a LAN; figure 9),
determine a first selected profile for header compression, the first selected profile for header compression being selected from a plurality of predetermined profiles and to form a compressed data frame for transmission on a wireless access interface of the wireless communications network, apply compression to the protocol header fields of the first data frame in accordance with the first selected profile for header compression a first compressed data frame for transmission on a wireless access interface of the wireless communication network; determine a second selected profile for header compression from the plurality of determined profiles ([0163]; “…PDCP PDU routing (in case of split bearers)…duplication of PDCP PDUs…”; teaches and suggests duplication of PDCP PDUs for subsequent header compression; [0164]; “…the header compression protocol may be based on the Robust Header Compression (ROHC) framework…There may be multiple header compression algorithms, called profiles, defined for the ROHC framework…”; [0166]-Table 1; [0168]; [0186]; “…the PDCP-Config IE may comprise the profile(s) for the header compression…”; [0187]; “…Ethernet profile configuration IE may comprise information about…one or more parameters on Ethernet packet header compression, and/or the profile identifier(s)…” [0279]; teaches selecting a profile for header compression from a plurality of profiles for each data frame and applying compression for transmission of the data frame in the wireless network), and
form a first packet data convergence protocol (PDCP) protocol data unit (PDU) comprising the first compressed data frame ([0193]; “…action may comprise constructing a PDCP PDU comprising at least the compressed header, the payload…”; [0194]; [0256]; teaches constructing a PDCP PDU comprising the compressed data frame).
However, Qiao may not explicitly disclose duplicate the data frame to form a first data frame and a second data frame, apply compression to the protocol header fields of the second data frame in accordance with the second selected profile for header compression to form a second compressed data frame for transmission on the wireless access interface, and form a second PCDP PDU comprising the second compressed data frame (although Qiao does suggest PDCP PDU routing in case of split bearers and duplication of PDCP PDUs; “…PDCP PDU routing (in case of split bearers)…duplication of PDCP PDUs…”; [0063]).
Nonetheless, in the same field of endeavor, Ryu teaches and suggests duplicate the data frame to form a first data frame and a second data frame, apply compression to the protocol header fields of the second data frame in accordance with the second selected profile for header compression to form a second compressed data frame for transmission on the wireless access interface, and form a second PCDP PDU comprising the second compressed data frame ([0380]; “…PDCP sub layer for a user plane performs…header compression and decompression (only for Robust Header Compression (RoHC))…PDCH PDU routing (for split bearer)…PDCP PDU copy…”; [0381]; [0382]; “…In the PDCP, the duplication includes a transmission of the same PDCP PDU(s) twice…”; teaches duplicating data frames to form separate PDCP PDUs in which header compression, RoHC, has been applied according to a profile for header compression associated with RoHC, to each of the duplicated data frames).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate duplicating data frames to form separate PDCP PDUs in which header compression, RoHC, has been applied according to a profile for header compression associated with RoHC, to each of the duplicated data frames as taught by Ryu with the method for header compression as disclosed by Qiao for the purpose of ensuring proper transmission and reducing overhead and radio resource waste, as suggested by Ryu.
However, Qiao, as modified by Ryu, may not explicitly disclose determining a first selected profile for header compression based on an indication of decompression success with respect to previously transmitted data frames and the indication of decompression success is received in a PDCP header of an uplink frame, each of the plurality of predetermined profiles specifying a subset of the protocol header fields, and apply compression to a subset of the protocol header fields of the first data frame in accordance with the first selected profile for header compression; and apply compression to at least a subset of the protocol header fields of the second data frame in accordance with the second selected profile for header compression, wherein the first PDCP PDU comprises an indication of the first selected profile for header compression, the second PDCP PDU comprises an indication of the second selected profile for header compressing (although Qiao does suggest the selected profile is indicated in the header of the transmitted packet and decompression acknowledgement).
Nonetheless, in the same field of endeavor, Gangkhedkar teaches and suggests determining a first selected profile for header compression based on an indication of decompression success (feedback/ACK) with respect to previously transmitted data frames and the indication of decompression success (feedback/ACK) is received in a PDCP header of an uplink frame (uplink/feedback ACK) ([0035]; [0037]; [0055]; [0105]; teaches determining the profile for header compression based on an indication, such as an ACK, indicating successful decompression with respect to a previously transmitted data packet), each of the plurality of predetermined profiles specifying a subset of the protocol header fields (static fields) ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields), and apply compression to a subset of the protocol header fields of the first data frame in accordance with the first selected profile for header compression ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields); and apply compression to at least a subset of the protocol header fields of the second data frame in accordance with the second selected profile for header compression ([0030]; [0102]; claim 6; teaches the compression profiles specifies a subset of fields, such as static fields), wherein the first PDCP PDU comprises an indication of the first selected profile for header compression, the second PDCP PDU comprises an indication of the second selected profile for header compression ([0035]; [0055]; [0105]; teaches the compression profile is signaled in the PDCP PDU).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the compression profiles specifies a subset of fields, such as static fields, and the compression profile is signaled in the PDCP PDU and determining the profile for header compression based on an indication, such as an ACK, indicating successful decompression with respect to a previously transmitted data packet as taught by Gangkhedkar with the method for header compression as disclosed by Qiao, as modified by Ryu, for the purpose of providing a compression method about how to select to make a decompressing party decompress the data packets with the minimum memory space, as suggested by Gangkhedkar.
Regarding claim 37, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests wherein the controller is configured to control the transmitter so that the communications device is operable to transmit the first compressed data frame and the second compressed data frame on the wireless access interface ([0164]; [0166]; [0187]; [0276]; teaches selecting a profile header compression and applying compression for transmission of data in the wireless network).
Regarding claim 45, Qiao, as modified by Ryu and Gangkhedkar, further teaches and suggests measuring a quality metric of the radio channel, wherein the quality metric includes at least one of signal-to-noise ratio (SNR), bit error rate (BER), or packet loss rate; and selecting at least one of the first profile for header compression or the second selected profile for header compression based on the measured quality metric ([0134]; [0138]; [0216]; teaches determining a quality metric for determining the compression profile).
Regarding claim 46, Qiao teaches selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose transmitting an initial uncompressed data frame to establish a compression context; and subsequently applying compression to data frames based on at least one of the first selected profile for header compression or the second selected profile for header compression.
Nonetheless, in the same field of endeavor, Gangkhedkar further teaches and suggests transmitting an initial uncompressed data frame to establish a compression context; and subsequently applying compression to data frames based on at least one of the first selected profile for header compression or the second selected profile for header compression ([0103]; teaches transmitting an initial uncompressed packet in order to establish compression context and applying compression based on the profile).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate transmitting an initial uncompressed packet in order to establish compression context and applying compression based on the profile as taught by Gangkhedkar with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of providing a compression method about how to select to make a decompressing party decompress the data packets with the minimum memory space, as suggested by Gangkhedkar.
Claims 2 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (hereinafter Qiao) (U.S. Patent Application Publication # 2021/0258828 A1) in view of RYU et al. (hereinafter Ryu) (U.S. Patent Application Publication # 2022/0338084 A1) and GANGAKHEDKAR et al. (hereinafter Gangkhedkar) (U.S. Patent Application Publication # 2021/0314815 A1), and further in view of CMCC (Non-Patent Literature – “Consideration on Ethernet Header Compression” – 3GPP TSG-RAN WG2 #104).
Regarding claim 2, Qiao, as modified by Ryu and Gangkhedkar, discloses selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose wherein the plurality of predetermined profiles comprise a first profile according to which no protocol header fields are compressed, a second profile according to which a plurality of fields are compressed, and a third profile according to which a subset of the plurality of fields are compressed.
Nonetheless, in the same field of endeavor, CMCC further teaches and suggests wherein the plurality of predetermined profiles comprise a first profile according to which no protocol header fields are compressed, a second profile according to which a plurality of fields are compressed, and a third profile according to which a subset of the plurality of fields are compressed (pages 2-3, section 2.2; Table 5; “…RAN2 can design the Ethernet header compression guided by the principle of existing RoHC mechanism, identifying the compression fields…”; teaches specifying the header or header fields, or subset of the header fields for header compression of the fields in accordance to profiles; Table 5).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate specifying a subset of the header fields for header compression of the fields in accordance to the profile as taught by CMCC with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of providing effective header compression, as suggested by CMCC.
Regarding claim 14, Qiao, as modified by Ryu and Gangkhedkar, discloses selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose wherein in accordance with one of the plurality of predetermined profiles, no header fields are compressed.
Nonetheless, , in the same field of endeavor, CMCC further teaches and suggests wherein in accordance with one of the plurality of predetermined profiles, no header fields are compressed (pages 2-3, section 2.2; Table 5; “…RAN2 can design the Ethernet header compression guided by the principle of existing RoHC mechanism, identifying the compression fields…”; teaches specifying the header or header fields, or subset of the header fields for header compression of the fields in accordance to profiles; Table 5, where each level represents the profile and the associated compression fields are identified including no header compression).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate specifying a subset of the header fields for header compression of the fields in accordance to the profile as taught by CMCC with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of providing effective header compression, as suggested by CMCC.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (hereinafter Qiao) (U.S. Patent Application Publication # 2021/0258828 A1) in view of RYU et al. (hereinafter Ryu) (U.S. Patent Application Publication # 2022/0338084 A1) and GANGAKHEDKAR et al. (hereinafter Gangkhedkar) (U.S. Patent Application Publication # 2021/0314815 A1), and further in view of Dinan (U.S. Patent # 7,948,913 B1).
Regarding claim 10, Qiao, as modified by Ryu and Gangkhedkar, discloses selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose determining a quality of a radio channel of the wireless access interface, and wherein the conditions for modifying the at least one of the first selected profile for header compression or second selected profile for header compression comprise conditions based on the quality of the radio channel.
Nonetheless, in the same field of endeavor, Dinan teaches and suggests determining a quality of a radio channel of the wireless access interface, and wherein the conditions for modifying the selected profile for header compression comprise conditions based on the quality of the radio channel (column 3, lines 11-18; teaches determining a channel quality for selecting a header-compression algorithm).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate determining a channel quality for selecting a header-compression algorithm as taught by Dinan with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of effectively selecting a header compression algorithm, as suggested by Dinan.
Claims 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Qiao et al. (hereinafter Qiao) (U.S. Patent Application Publication # 2021/0258828 A1) in view of RYU et al. (hereinafter Ryu) (U.S. Patent Application Publication # 2022/0338084 A1) and GANGAKHEDKAR et al. (hereinafter Gangkhedkar) (U.S. Patent Application Publication # 2021/0314815 A1), and further in view of Yi et al. (hereinafter Yi) (U.S. Patent Application Publication # 2010/0091709 A1).
Regarding claim 15, Qiao, as modified by Ryu and Gangkhedkar, discloses selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose ciphering the compressed data frame.
Nonetheless, in the same field of endeavor, Yi teaches and suggests ciphering the compressed data frame ([0057]; [0071]; teaches ciphering the header-compressed frame).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate ciphering the header-compressed frame as taught by Yi with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of processing header-compressed data.
Regarding claim 16, Qiao, as modified by Ryu and Gangkhedkar, discloses selecting a profile for header compression from a plurality of profiles and applying compression for transmission of the data frame in the wireless network, but may not explicitly disclose applying an integrity protection function to the compressed data frame.
Nonetheless, in the same field of endeavor, Yi teaches and suggests applying an integrity protection function to the compressed data frame ([0057]; [0071]; teaches applying integrity protection to the header-compressed frame).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate applying integrity protection to the header-compressed frame as taught by Yi with the method for header compression as disclosed by Qiao, as modified by Ryu and Gangkhedkar, for the purpose of processing header-compressed data.
Allowable Subject Matter
Claim 44 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments with respect to claims 1-5, 8-10, 12-16, 28, 29, 36, 37, and 44-46 have been considered but are moot in view of the new ground(s) of rejection as necessitated by Applicant’s amendment.
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 extension fee 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 date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUK JIN KANG whose telephone number is (571) 270-1771. The examiner can normally be reached on Monday-Friday 8am-5pm.
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, Chirag Shah can be reached on (571) 272-3144. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist/customer service whose telephone number is (571) 272-2600.
/Suk Jin Kang/
Examiner, Art Unit 2477
December 20, 2025
/CHIRAG G SHAH/Supervisory Patent Examiner, Art Unit 2477
Prosecution Insights