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 02/02/2024.
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 NON-FINAL.
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 Objections
Claims 6 and 16 are objected to because of the following informalities: the acronym “DRB ID” is not defined in the instant claim and its parent claim(s). Appropriate correction is required.
Claims 6, 14 are objected to because of the following informalities: the typo “dada” should be changed to “data”. Appropriate correction is required.
Claim 17 is objected to because of the following informalities: the acronym “EHC” is not defined in the claim. Appropriate correction is required.
Claims 13 and 18 are objected to because of the following informalities: the acronym “CID” is not defined in the instant claim and its parent claim(s). Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-5, 11-15, and 17-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US_20220166854_A1_Fan.
Regarding claim 1, Fan discloses 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).
Regarding claim 2, Fan discloses the data transmission method according to claim 1, 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 discloses the data transmission method according to claim 1, wherein the EHC configuration information comprises at least one of: a configuration comprising an 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…”); 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…”); and a Data Radio Bearer (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 discloses the data transmission method according to claim 3, 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 discloses the data transmission method according to claim 1, wherein the EHC configuration information comprises an EHC parameter, and the EHC parameter comprises at least one of: an EHC Context ID (CID) length (Fan paragraph 144, “… A length value of a context identifier (context ID/CID) field is 2 to 16 bits…”); 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…”); a maximum value of a unidirectional EHC CID; and 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.
3Regarding claim 11, Fan discloses the data transmission method according to claim 1, 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 discloses the data transmission method according to claim 1, 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 discloses the data transmission method according to claim 11, 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; and 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 discloses the data transmission method according to claim 3, 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; and 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; and 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 dada-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 dada-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 dada-packet type in response to the dada-packet type being a non-ethernet frame; the EHC process being performed for the DRB in response to the dada-packet type being the ethernet frame; and the EHC process being not performed for the DRB in response to the dada-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 discloses “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 discloses the data transmission method according to claim 3, 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 17, Fan discloses a data transmission 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 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).
Regarding claim 18, Fan discloses the data transmission method according to claim 17, 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); and 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 and 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 and the header detection in response to the first data packet comprising an EHC header having a non-specific value CID.
Regarding claim 19, Fan discloses the data transmission method according to claim 17, 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 discloses 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).
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) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over US_20220166854_A1_Fan in view of US_20220159776_A1_Li.
Regarding claim 6, Fan discloses the data transmission method according to claim 1, 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”), but does not explicitly disclose the DRB configuration comprises at least one of: a DRB ID; a DRB transmission type; and a dada-packet type corresponding to a DRB.
Li discloses the DRB configuration comprises at least one of: a DRB ID (Li paragraph 202, “For example, one piece of SL-DRB configuration information, that is, configuration information corresponding to one SL-DRB ID…”, also see paragraph 510); a DRB transmission type; and a dada-packet type corresponding to a DRB.
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 Li’s the SL-DRB configuration information includes SL-DRB ID in Fan’s system to uniquely identify and manage each specific radio bearer for direct communication between UEs. This method for improving the system of Fan was within the ordinary ability of one of ordinary skill in the art based on the teachings of Li. Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Fan and Li to obtain the invention as specified in claim 6.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over US_20220166854_A1_Fan in view of US_20220279380_A1_Hori.
Regarding claim 7, Fan discloses the data transmission method according to claim 1, but does not disclose wherein the EHC configuration information is EHC configuration information configured by a network device, and the method further comprises: receiving a Radio Resource Control (RRC) message from the network device; and acquiring the EHC configuration information based on the RRC message.
Hori discloses wherein the EHC configuration information is EHC configuration information configured by a network device (Hori figure 4, step S400, and abstract, “…an RRC message including an EHC configuration…”), and the method further comprises: receiving a Radio Resource Control (RRC) message from the network device (Hori figure 4, step S402, abstract, “A terminal apparatus for communicating with a base station apparatus, the terminal apparatus including: a receiver configured to receive, from the base station apparatus, an RRC message including an EHC configuration…”); and acquiring the EHC configuration information based on the RRC message (Hori figure 4, step S404, abstract, “…The processing unit configures an EHC protocol in accordance with the EHC configuration…”).
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 Hori’s the UE applying the EHC configuration received from the base station via RRC in Fan’s system to optimize data transmission efficiency by reducing the overhead of Ethernet frames (Hori paragraph 24). This method for improving the system of Fan was within the ordinary ability of one of ordinary skill in the art based on the teachings of Hori. Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Fan and Hori to obtain the invention as specified in claim 7.
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_20240064592_A1_Falkenberg.
Regarding claim 8, Fan discloses the data transmission method according to claim 1, but does not disclose wherein the EHC configuration information is EHC configuration information configured by a network device, and 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 discloses 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: 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’s system to reduce interference by letting the UE selects the resources indicated by the BS. This method for improving the system of Fan 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 and Falkenberg to obtain the invention as specified in claim 8.
Regarding claim 9, Fan discloses the data transmission method according to claim 1, but does not disclose 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 discloses 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’s system to reduce interference by letting the UE selects the resources indicated by the BS. This method for improving the system of Fan 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 and Falkenberg to obtain the invention as specified in claim 9.
Regarding claim 10, Fan and Falkenberg disclose the data transmission method according to claim 9, and Falkenberg further discloses 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).
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US_20220166854_A1_Fan in view of US_20230345323_A1_Xu.
Regarding claim 16, Fan discloses the data transmission method according to claim 1, and 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 (Fan figure 7, steps S103-s104, and paragraph 211, the compressed ethernet frame includes the EHC header); but does not disclose wherein the EHC configuration information indicating at least one of: not to perform the EHC process; to perform the EHC process; to only perform the EHC process for a DRB having a DRB ID belonging to a first ID; to only perform the EHC process for a DRB configured with the EHC process; and to only perform the EHC process for a DRB; wherein in response to the EHC configuration information indicating not to perform the EHC process, the method satisfies any one of: the first data packet not comprising an EHC header; and the first data packet comprising an EHC header having a specific value CID; 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; 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, but does not discloses wherein the EHC configuration information indicating at least one of: not to perform the EHC process; to perform the EHC process; to only perform the EHC process for a DRB having a DRB ID belonging to a first ID; to only perform the EHC process for a DRB configured with the EHC process; and to only perform the EHC process for a DRB.
Xu discloses wherein the EHC configuration information indicating at least one of: not to perform the EHC process; to perform the EHC process (Xu paragraph 85, “…The PDCP header compression configuration information may include configuration information about whether to enable a header compression function, a maximum quantity of contexts, profile information for PDCP header compression, information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment, and the like”); to only perform the EHC process for a DRB having a DRB ID belonging to a first ID; to only perform the EHC process for a DRB configured with the EHC process; and to only perform the EHC process for a DRB; wherein in response to the EHC configuration information indicating not to perform the EHC process, the method satisfies any one of: the first data packet not comprising an EHC header; and the first data packet comprising an EHC header having a specific value CID; wherein in response to the EHC configuration information indicating to perform the EHC process (Xu paragraph 85, “…The PDCP header compression configuration information may include configuration information about whether to enable a header compression function, a maximum quantity of contexts, profile information for PDCP header compression, information indicating whether to continue to perform a header compression protocol or resetting header compression in a case of PDCP reestablishment, and the like”); 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; 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, but does not discloses wherein the EHC configuration information indicating at least one of: not to perform the EHC process; to perform the EHC process; to only perform the EHC process for a DRB having a DRB ID belonging to a first ID; to only perform the EHC process for a DRB configured with the EHC process; and to only perform the EHC process for a DRB.
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’s the configuration information indicating whether to perform a header compression protocol in Fan’s system to explicitly instruct the terminal device when should perform the header compression. This method for improving the system of Fan was within the ordinary ability of one of ordinary skill in the art based on the teachings of Xu. Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Fan and Xu to obtain the invention as specified in claim 16.
Conclusion
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