DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
This office action is in response to the communication(s) filed on 06/16/2026.
Claim(s) 1-20 is/are currently presenting for examination.
Claim(s) 1, 17, and 20 is/are independent claim(s).
Claim(s) 1-20 is/are rejected.
This action has been made FINAL.
Response to Arguments
Applicant's arguments filed on 06/16/2026 have been considered but are moot in view of the new ground(s) of rejection.
Applicant's amendment to title is acknowledged. However, the amended title is still not descriptive. Therefore, objection to the title is maintained. Examiner suggests amending the title to include the term “ethernet header compression” or “EHC”.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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 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.
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.
Claim(s) 1-7, and 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US_20220166854_A1_Fan in view of US_20230345323_A1_Xu and WO_2023005452_A1_Fan (Hereinafter, “Fan-52”).
Regarding claim 1, Fan teaches a data transmission method, wherein the method is performed by a first terminal device (Fan figure 7, and paragraph 246, “…the compression end is a terminal, the decompression end is a terminal…”, paragraph 248, “…in a scenario in which two terminals communicates with each other through a sidelink, the two terminals exchanges a capability of supporting EHC by using sidelink messages…”) and comprises: performing an Ethernet Header Compression (EHC) process based on EHC configuration information and generating a first data packet (Fan figure 7, steps S102-S103, paragraph 158, “…after receiving the Ethernet frame including the first to-be-compressed field, the compression end compresses the Ethernet header of the Ethernet frame based on the first correspondence including the first compression information and the value of the first to-be-compressed field and the first compression information. Correspondingly, the decompression end decompresses the Ethernet header of the compressed Ethernet frame based on the first correspondence when receiving the compressed Ethernet frame…”, and paragraphs 126-128, wherein the first correspondence is corresponding to the claimed “EHC configuration information”. Also see paragraphs 10, 126-128); and transmitting the first data packet to a second terminal device (Fan figure 7, step S104),
but does not teach wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed; and wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Xu from the same or similar fields of endeavor teaches: wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed (Xu paragraph 289, “…information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment, and the like.”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Xu into Fan, since Fan suggests a technique for ethernet header compression process, and Xu suggests the beneficial way of information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment so that/thus provide a crucial balance between network transmission efficiency and protocol state synchronization in the analogous art of communication.
Fan and Xu do not teach wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Fan-52 from the same or similar fields of endeavor teaches: wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB (Fan-52, translation, page 34, 2nd paragraph, “For example, in the case that multiple wireless bearers (or wireless links, wireless connections, transmission channels, etc.) can be established between the first communication device and the second communication device for data packet transmission, the compressed configuration information may also indicate support The target radio bearer for compression processing (that is, the first communication device compresses the data packets sent through the target radio bearer); similarly, the decompression configuration information may also indicate the target radio bearer that supports decompression processing (that is, the second communication device) The device decompresses the data packet received through the target radio bearer)”, and page 28, 5th paragraph, “…if the current UDC mechanism, RoHC mechanism, EHC mechanism and other compression mechanisms are used to compress…”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Fan-52 into Fan and Xu, since Fan and Xu suggests a technique for ethernet header compression, and Fan-52 suggests the beneficial way of the compressed configuration information indicates the target radio bearer for compression processing, and perform compression for the target radio bearer so that/thus improves the efficiency of data compression (Fan-52, translation, page 46, 7th paragraph) in the analogous art of communication.
Regarding claim 2, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC configuration information is any one of: preset EHC configuration information; EHC configuration information configured by a network device; and EHC configuration information configured by a terminal device (Fan figure 7, step S102, paragraph 126, “The compression end determines the first compression information included in the first correspondence as the first compression information of the Ethernet header of the Ethernet frame…”).
Regarding claim 3, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC configuration information comprises at least one of: a configuration comprising the EHC parameter (Fan paragraph 126, “…the compression information includes the identifier of the correspondence (or referred to as an identifier of the compression information). In this case, the first compression information includes an identifier of the first correspondence or an identifier of the first compression information. In the following embodiments, an example in which the information is a context identifier (CID) is used…”, paragraph 127, “…the compression information further includes a profile identifier (profile ID), so that the first compression information further includes a first profile ID…”); or a DRB configuration, configured to indicate whether a corresponding DRB is configured with an EHC process (Fan paragraph 247, “…a capability of the decompression end supporting EHC, a quantity of data radio bearers DRBs supporting the EHC at the decompression end, profile information supported by the decompression end, a maximum value MAX_CID of entries of correspondences supported by each DRB supporting the EHC, a capability of the decompression end supporting dynamic configuration of a profile parameter, and a sum of entries of correspondences maintained by DRBs supporting the EHC at the decompression end”, also see paragraph 252); wherein the configuration comprises the EHC parameter comprises at least one of: a configuration of an EHC parameter of a transmitting resource pool; a configuration of an EHC parameter of a receiving resource pool; a configuration of an EHC parameter of a resource-shared pool; and a configuration of an EHC parameter between the first terminal device and the second terminal device (Fan paragraph 127, profile ID).
Regarding claim 4, Fan, Xu, and Fan-52 teach the data transmission method according to claim 3, and Fan further teaches wherein the configuration of the EHC parameter between the first terminal device and the second terminal device comprises a terminal device identity (ID), the terminal device ID is configured to indicate a matching relationship between the configuration of the EHC parameter between the first terminal device and the second terminal device and a terminal device (Fan paragraph 127, “…the compression information further includes a profile identifier (profile ID), so that the first compression information further includes a first profile ID. The profile ID is used to identify a profile (profile). The profile is used to specify a compression mechanism, for example, the profile is used to indicate a compressible field and/or a compression manner. Different profiles are distinguished by using profile IDs. Alternatively, the profile ID is used to indicate a communication protocol of the Ethernet header and/or a to-be-compressed field of the Ethernet header”. The profile ID is corresponding to the claimed “terminal device ID”).
Regarding claim 5, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC parameter further comprises at least one of: an EHC CID length (Fan paragraph 144, “… A length value of a context identifier (context ID/CID) field is 2 to 16 bits…”); or a maximum value of a transmission end EHC CID (Fan paragraph 247, “… a maximum value MAX_CID of entries of correspondences supported by each DRB supporting the EHC…”).
Regarding claim 6, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC configuration information comprises a DRB configuration (Fan paragraph 247, paragraph 247, “… a maximum value MAX_CID of entries of correspondences supported by each DRB supporting the EHC… and a sum of entries of correspondences maintained by DRBs supporting the EHC at the decompression end”), and Fan-52 further teaches the DRB configuration comprises at least one of: a DRB ID (Fan-52, translation, page 49, 10th – 11th paragraphs, page 50,14th paragraph, DRB identifier/ID); a DRB transmission type; or a data-packet type corresponding to a DRB.
Regarding claim 7, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan-52 further teaches wherein the EHC configuration information is EHC configuration information configured by a network device (Fan-52, translation, page 48, 4th paragraph, “S902: The gNB configures a compression mode and a compression buffer for the UE according to the compression capability information reported by the UE. The gNB notifies the UE of the compression mode and the compression buffer information through the compression configuration information”), and the method further comprises: receiving a Radio Resource Control (RRC) message from the network device (Fan-52, translation, page 47, 6th paragraph, “Optionally, the gNB may send the compressed configuration information to the UE through an RRC message”); and acquiring the EHC configuration information based on the RRC message (Fan-52, translation, page 28, 9th paragraph, “S601: The first communication device acquires compressed configuration information…”).
Regarding claim 11, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC configuration information is EHC configuration information configured by the first terminal device (Fan figure 7, step S102, paragraph 126, “The compression end determines the first compression information included in the first correspondence as the first compression information of the Ethernet header of the Ethernet frame…”), and the method further comprises: transmitting the EHC configuration information to the second terminal device (Fan figure 7, steps S104-S105).; or transmitting the EHC configuration information to the second terminal device through a network device.
Regarding claim 12, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan further teaches wherein the EHC configuration information is EHC configuration information configured by the second terminal device (Fan paragraph 248, “…in a scenario in which two terminals communicates with each other through a sidelink, the two terminals exchanges a capability of supporting EHC by using sidelink messages…”. The decompression end determines its EHC capability information and sends it to the compression end), and the method further comprises: receiving the EHC configuration information from the second terminal device (Fan paragraph 248, “…the two terminals directly exchange an EHC capability of a sidelink interface by using sidelink RRC messages…”); or receiving the EHC configuration information from a network device, wherein the EHC configuration information is transmitted by the second terminal device to the network device (Fan paragraph 248, “…the two terminals exchange an EHC capability of a sidelink interface through a base station or another terminal.… the compression end receives the capability information of the decompression end by using a sidelink message, or receive the capability information of the decompression end through the base station or the another terminal…”).
Regarding claim 13, Fan, Xu, and Fan-52 teach the data transmission method according to claim 11, and Fan further teaches wherein the EHC configuration information comprises a EHC parameter (Fan paragraph 126, “…the compression information includes the identifier of the correspondence (or referred to as an identifier of the compression information). In this case, the first compression information includes an identifier of the first correspondence or an identifier of the first compression information. In the following embodiments, an example in which the information is a context identifier (CID) is used…”, paragraph 127, “…the compression information further includes a profile identifier (profile ID), so that the first compression information further includes a first profile ID…”), and the EHC parameter comprises at least one of: a transmitting EHC parameter of the first terminal device; a receiving EHC parameter of the first terminal device; a transmitting EHC parameter of the second terminal device; or a receiving EHC parameter of the second terminal device (Fan paragraph 247, “…a capability of the decompression end supporting EHC, a quantity of data radio bearers DRBs supporting the EHC at the decompression end, profile information supported by the decompression end, a maximum value MAX_CID of entries of correspondences supported by each DRB supporting the EHC, a capability of the decompression end supporting dynamic configuration of a profile parameter, and a sum of entries of correspondences maintained by DRBs supporting the EHC at the decompression end.” The capability information of the decompression end is corresponding to the claimed “transmitting/receiving EHC parameter of the second terminal device”).
Regarding claim 14, Fan, Xu, and Fan-52 teach the data transmission method according to claim 3, and Fan further teaches wherein the DRB configuration comprises a DRB ID, and the method comprises at least one of: the DRB configuration indicating the EHC process to be performed for a DRB of a first ID in response to the DRB ID being the first ID; the DRB configuration indicating the EHC process not to be performed for a DRB not of the first ID in response to the DRB ID being not the first ID; the EHC process being performed for a DRB corresponding to the DRB ID carried in the DRB configuration; or the EHC process being not performed for a DRB corresponding to a DRB ID not carried in the DRB configuration; wherein the DRB configuration comprises a DRB transmission type, and the method comprises at least one of: the DRB configuration indicating the EHC process to be performed for a DRB of a unicast type in response to the DRB transmission type being the unicast type; the DRB configuration indicating the EHC process not to be performed for a DRB of a non-unicast type in response to the DRB transmission type being the non-unicast type; the EHC process being performed for the DRB in response to the DRB transmission type being the unicast type; or the EHC process being not performed for the DRB in response to the DRB transmission type being the non-unicast type; wherein the DRB configuration comprises a data-packet type corresponding to a DRB, and the method comprises at least one of: the DRB configuration indicating the EHC process to be performed for a DRB of an ethernet-frame data-packet type in response to the data-packet type being an ethernet frame; the DRB configuration indicating the EHC process not to be performed for a DRB of a non-ethernet frame data-packet type in response to the data-packet type being a non-ethernet frame; the EHC process being performed for the DRB in response to the data-packet type being the ethernet frame; or the EHC process being not performed for the DRB in response to the data-packet type being the non-ethernet frame (Claims 14 further define an alternative of claim 3 (a Data Radio Bearer (DRB) configuration, configured to indicate whether a corresponding DRB is configured with an EHC process). As discussed above, Fan teaches “a configuration comprising an EHC parameter; the EHC parameter; and a Data Radio Bearer (DRB) configuration, configured to indicate whether a corresponding DRB is configured with an EHC process” and thus all the limitations of claims 14 have been met by addressing the alternative).
Regarding claim 15, Fan, Xu, and Fan-52 teach the data transmission method according to claim 3, and Fan further teaches wherein in response to any one of the EHC parameter not comprising an EHC CID length (Fan paragraph 207, “…when the EHC header does not carry the CID, the Ethernet header is the complete Ethernet header”), the EHC parameter comprising a plurality kind of EHC CID lengths (Fan paragraph 208, “…A length value of a context identifier (context ID/CID) field is 2 to 16 bits. For example, a length of the context ID field is 5 bits, 6 bits, 7 bits, 8 bits, or 16 bits…”), and the EHC configuration information being preset EHC configuration information (Fan paragraph 207, “…when the EHC header does not carry the CID, the Ethernet header is the complete Ethernet header”, paragraph 208, “…or the EHC header does not include the CID field. In this case, to ensure byte alignment of the EHC header, an extra bit location is filled with a reserved bit. Whether the Ethernet header field is the original Ethernet header or the compressed Ethernet header obtained after the first to-be-compressed field is removed is indicated by the indication field F...”), the EHC CID length is determined through any one of: a high layer indication (Fan paragraph 208, “This field indicates an identifier corresponding to compression information used for header compression of the Ethernet frame. When the value of F indicates that the subsequent Ethernet header is the original frame header, the decompression end ignores a value of the CID field, or the EHC header does not include the CID field…”); an ethernet-frame packet type; a preset rule; and a CID length of the corresponding DRB.
Regarding claim 16, Fan teaches the data transmission method according to claim 1, wherein in response to the EHC configuration information indicating to perform the EHC process, the method satisfies any one of: the first data packet comprising the EHC header; and the first data packet comprising an EHC header having a non-specific value CID; wherein in response to the EHC configuration information indicating to only perform the EHC process for a DRB having a DRB ID belonging to a first ID, the method satisfies any one of: a DRB ID corresponding to the first data packet belonging to the first ID, and the first data packet comprising the EHC header; and the DRB ID not belonging to the first ID or the DRB ID being a non-first ID, the first data packet not comprising the EHC header; or a DRB ID corresponding to the first data packet belonging to the first ID, and the first data packet comprising the EHC header having the non-specific value CID; and the DRB ID not belonging to the first ID or the DRB ID being a non-first ID, and the first data packet comprising the EHC header having the specific-value CID; wherein in response to the EHC configuration information indicating to only perform the EHC process for a DRB configured with the EHC process, the method satisfies any one of: a DRB corresponding to the first data packet being the DRB configured with the EHC process, and the first data pocket comprising the EHC header; and the DRB being a DRB not configured with the EHC process, and the first data packet not comprising the EHC header; or a DRB corresponding to the first data packet being the DRB configured with the EHC process, and the first data pocket comprising the EHC header having the non-specific value CID; and the DRB being a DRB not configured with the EHC process, and the first data packet comprising the EHC header having the specific value CID;
wherein in response to the EHC configuration information indicating to only perform the EHC process for a DRB, the method satisfies any one of: the first data pocket of a bearer comprising the EHC header in response to the bearer being the DRB; and a pocket of the bearer not comprising the EHC header in response to the bearer being not the DRB (Fan page 25, claim 11, “sending, the first correspondence to the decompression end by using a first packet data convergence protocol (PDCP) data protocol data unit (PDU), wherein the first PDCP data PDU comprises: a first Ethernet header compression EHC header, the first EHC header comprises: a first indication field wherein the first indication field is used to indicate whether the first EHC header comprises a complete Ethernet header; the first CID; and an Ethernet header of a second Ethernet frame, wherein a value of a to-be-compressed field in the Ethernet header of the second Ethernet frame is equal to the value of the first to-be-compressed field”); or the first data pocket of a bearer comprising the EHC header having the non-specific value CID in response to the bearer being the DRB; and a pocket of the bearer comprising the EHC header having the specific value CID in response to the bearer being not the DRB.
Regarding claim 17, Fan teaches a data processing method, wherein the method is performed by a second terminal device (Fan figure 7, and paragraph 246, “…the compression end is a terminal, the decompression end is a terminal…”, paragraph 248, “…in a scenario in which two terminals communicates with each other through a sidelink, the two terminals exchanges a capability of supporting EHC by using sidelink messages…”) and comprises: receiving a first data packet from a first terminal device (Fan figure 7, steps S104-S105); and performing an Ethernet Header Compression (EHC) reception process for the first data packet based on EHC configuration information (Fan figure 7, steps S106; paragraph 158, “…after receiving the Ethernet frame including the first to-be-compressed field, the compression end compresses the Ethernet header of the Ethernet frame based on the first correspondence including the first compression information and the value of the first to-be-compressed field and the first compression information. Correspondingly, the decompression end decompresses the Ethernet header of the compressed Ethernet frame based on the first correspondence when receiving the compressed Ethernet frame…”, and paragraphs 126-128, wherein the first correspondence is corresponding to the claimed “EHC configuration information”. Also see paragraphs 10, 126-128) and obtaining a second data packet (Fan figure 7, steps S107, recovering the original ethernet frame),
but does not teach wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed; and wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Xu from the same or similar fields of endeavor teaches: wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed (Xu paragraph 289, “…information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment, and the like.”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Xu into Fan, since Fan suggests a technique for ethernet header compression process, and Xu suggests the beneficial way of information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment so that/thus provide a crucial balance between network transmission efficiency and protocol state synchronization in the analogous art of communication.
Fan and Xu do not teach wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Fan-52 from the same or similar fields of endeavor teaches: wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB (Fan-52, translation, page 34, 2nd paragraph, “For example, in the case that multiple wireless bearers (or wireless links, wireless connections, transmission channels, etc.) can be established between the first communication device and the second communication device for data packet transmission, the compressed configuration information may also indicate support The target radio bearer for compression processing (that is, the first communication device compresses the data packets sent through the target radio bearer); similarly, the decompression configuration information may also indicate the target radio bearer that supports decompression processing (that is, the second communication device) The device decompresses the data packet received through the target radio bearer)”, and page 28, 5th paragraph, “…if the current UDC mechanism, RoHC mechanism, EHC mechanism and other compression mechanisms are used to compress…”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Fan-52 into Fan and Xu, since Fan and Xu suggests a technique for ethernet header compression, and Fan-52 suggests the beneficial way of the compressed configuration information indicates the target radio bearer for compression processing, and perform compression for the target radio bearer so that/thus improves the efficiency of data compression (Fan-52, translation, page 46, 7th paragraph) in the analogous art of communication.
Regarding claim 18, Fan, Xu, and Fan-52 teach the data transmission method according to claim 17, and Fan further teaches wherein the EHC reception process comprises at least one of: a high layer delivery (Fan figure 7, steps S104, and paragraph 211, “in step S104, the EHC header of the PDCP data PDU used to send the compressed Ethernet frame to the decompression end further includes check information”); a data decompression or recovery (Fan figure 7, steps S105-S107); or a header detection (Fan figure 7, steps S106-S107); (Note: the following limitations are optional) wherein the EHC reception process comprises the high layer delivery in response to the first data packet not comprising an EHC header; and the EHC reception process comprises the high layer delivery and at least one of the data decompression or recovery or the header detection in response to the first data packet comprising the EHC header; wherein the EHC reception process comprises the high layer delivery and the header detection in response to the first data packet comprising an EHC header having a specific value CID ; and the EHC reception process comprises the high layer delivery and at least one of the data decompression or recovery or the header detection in response to the first data packet comprising an EHC header having a non-specific value CID.
Regarding claim 19, Fan, Xu, and Fan-52 teach the data transmission method according to claim 17, and Fan further teaches wherein the first data packet is a data packet for which an EHC process has been performed (Fan figure 7, steps S103-S104), and the method further comprises: transmitting an EHC feedback packet to the first terminal device (Fan figure 12, steps S204).
Regarding claim 20, Fan teaches a terminal device, comprising: a memory, configured to store computer-executing instructions; and a processor, configured to perform the computer-executing instructions stored in the memory to implement (Fan figures 7, 28, and paragraph 246, “…the compression end is a terminal, the decompression end is a terminal…”, paragraph 248, “…in a scenario in which two terminals communicates with each other through a sidelink, the two terminals exchanges a capability of supporting EHC by using sidelink messages…”): performing an Ethernet Header Compression (EHC) process based on EHC configuration information and generating a first data packet (Fan figure 7, steps S102-S103, paragraph 158, “…after receiving the Ethernet frame including the first to-be-compressed field, the compression end compresses the Ethernet header of the Ethernet frame based on the first correspondence including the first compression information and the value of the first to-be-compressed field and the first compression information. Correspondingly, the decompression end decompresses the Ethernet header of the compressed Ethernet frame based on the first correspondence when receiving the compressed Ethernet frame…”, and paragraphs 126-128, wherein the first correspondence is corresponding to the claimed “EHC configuration information”. Also see paragraphs 10, 126-128); and transmitting the first data packet to a second terminal device (Fan figure 7, step S104); or receiving a first data packet from a first terminal device (Fan figure 7, steps S104-S105); and performing an EHC reception process for the first data packet based on EHC configuration information (Fan figure 7, steps S106) and obtaining a second data packet (Fan figure 7, steps S107, recovering the original ethernet frame),
but does not teach wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed; and wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Xu from the same or similar fields of endeavor teaches: wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: a maximum value of a unidirectional EHC Context Identifier (CID); or a continue EHC, configured to indicate whether to perform a reset process for the EHC parameter or an EHC status in response to a Packet Data Convergence Protocol (PDCP) being reconstructed (Xu paragraph 289, “…information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment, and the like.”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Xu into Fan, since Fan suggests a technique for ethernet header compression process, and Xu suggests the beneficial way of information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment so that/thus provide a crucial balance between network transmission efficiency and protocol state synchronization in the analogous art of communication.
Fan and Xu do not teach wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB.
Fan-52 from the same or similar fields of endeavor teaches: wherein the EHC configuration information indicates at least one of: to only perform an EHC process for a Data Radio Bearer (DRB) having a Data Radio Bearer Identifier (DRB ID) belonging to a first Identifier (ID); to only perform the EHC process for a DRB configured with the EHC process; or to only perform the EHC process for a DRB (Fan-52, translation, page 34, 2nd paragraph, “For example, in the case that multiple wireless bearers (or wireless links, wireless connections, transmission channels, etc.) can be established between the first communication device and the second communication device for data packet transmission, the compressed configuration information may also indicate support The target radio bearer for compression processing (that is, the first communication device compresses the data packets sent through the target radio bearer); similarly, the decompression configuration information may also indicate the target radio bearer that supports decompression processing (that is, the second communication device) The device decompresses the data packet received through the target radio bearer)”, and page 28, 5th paragraph, “…if the current UDC mechanism, RoHC mechanism, EHC mechanism and other compression mechanisms are used to compress…”).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Fan-52 into Fan and Xu, since Fan and Xu suggests a technique for ethernet header compression, and Fan-52 suggests the beneficial way of the compressed configuration information indicates the target radio bearer for compression processing, and perform compression for the target radio bearer so that/thus improves the efficiency of data compression (Fan-52, translation, page 46, 7th paragraph) in the analogous art of communication.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US_20220166854_A1_Fan in view of US_20230345323_A1_Xu, WO_2023005452_A1_Fan (Hereinafter, “Fan-52”), and US_20240064592_A1_Falkenberg.
Regarding claim 8, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, and Fan-52 further teaches wherein the EHC configuration information is EHC configuration information configured by a network device (Fan-52, translation, page 48, 4th paragraph, “S902: The gNB configures a compression mode and a compression buffer for the UE according to the compression capability information reported by the UE. The gNB notifies the UE of the compression mode and the compression buffer information through the compression configuration information”), but do not teach the method further comprises: receiving the EHC configuration information from the second terminal device, wherein the EHC configuration information is transmitted by the network device to the second terminal device; wherein the EHC configuration information comprises any one of: a configuration of an EHC parameter of a transmitting resource pool; and both the configuration of the EHC parameter of the transmitting resource pool and a configuration of an EHC parameter of a receiving resource pool.
Falkenberg teaches the method further comprises: receiving the EHC configuration information from the second terminal device, wherein the EHC configuration information is transmitted by the network device to the second terminal device (Falkenberg figure 23, the 2nd UE receives the first configuration parameters from the BS, and transmits it to the 1st UE); wherein the EHC configuration information comprises any one of: a configuration of an EHC parameter of a transmitting resource pool (Falkenberg paragraph 176, “the first configuration parameters may comprise sidelink resource pool configuration parameters”, a sidelink resource pool can be a transmitting pool and a receiving resource pool); and both the configuration of the EHC parameter of the transmitting resource pool and a configuration of an EHC parameter of a receiving resource pool (Falkenberg paragraph 176, “the first configuration parameters may comprise sidelink resource pool configuration parameters”, a sidelink resource pool can be a transmitting pool and a receiving resource pool).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Falkenberg’s the 2nd UE receives the first configuration parameters including sidelink resource pool configuration parameters from the BS, and transmits it to the 1st UE in Fan, Xu, and Fan-52’s system to reduce interference by letting the UE selects the resources indicated by the BS. This method for improving the system of Fan, Xu, and Fan-52 was within the ordinary ability of one of ordinary skill in the art based on the teachings of Falkenberg. Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Fan, Xu, Fan-52, and Falkenberg to obtain the invention as specified in claim 8.
Regarding claim 9, Fan, Xu, and Fan-52 teach the data transmission method according to claim 1, but do not teach wherein the EHC configuration information is EHC configuration information configured by a network device, and the method further comprises: transmitting the EHC configuration information to the second terminal device.
Falkenberg teaches wherein the EHC configuration information is EHC configuration information configured by a network device (Falkenberg figure 23, the BS generate the first configuration parameters, and paragraphs 35, 49, EHC protocol), and the method further comprises: transmitting the EHC configuration information to the second terminal device (Falkenberg figure 23, the 2nd UE receives the first configuration parameters from the BS, and transmits it to the 1st UE).
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Falkenberg’s the 2nd UE receives the first configuration parameters including sidelink resource pool configuration parameters from the BS, and transmits it to the 1st UE in Fan, Xu, and Fan-52’s system to reduce interference by letting the UE selects the resources indicated by the BS. This method for improving the system of Fan, Xu, and Fan-52 was within the ordinary ability of one of ordinary skill in the art based on the teachings of Falkenberg. Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Fan, Xu, Fan-52 and Falkenberg to obtain the invention as specified in claim 9.
Regarding claim 10, Fan, Xu, Fan-52, and Falkenberg teach the data transmission method according to claim 9, and Falkenberg further teaches wherein the EHC configuration information comprises any one of: a configuration of an EHC parameter of a transmitting resource pool (Falkenberg paragraph 176, “the first configuration parameters may comprise sidelink resource pool configuration parameters”, a sidelink resource pool can be a transmitting pool and a receiving resource pool); a configuration of an EHC parameter of a receiving resource pool (Falkenberg paragraph 176, “the first configuration parameters may comprise sidelink resource pool configuration parameters”, a sidelink resource pool can be a transmitting pool and a receiving resource pool); and both the configuration of the EHC parameter of the transmitting resource pool and the configuration of the EHC parameter of the receiving resource pool (Falkenberg paragraph 176, “the first configuration parameters may comprise sidelink resource pool configuration parameters”, a sidelink resource pool can be a transmitting pool and a receiving resource pool).
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 WEIBIN HUANG whose telephone number is (571)270-3695. The examiner can normally be reached Monday - Friday 9:30AM - 6:00PM.
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, Sujoy Kundu can be reached at (571)272-8586. 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.
/W.H/Examiner, Art Unit 2471
/SUJOY K KUNDU/Supervisory Patent Examiner, Art Unit 2471
Prosecution Insights