DETAILED ACTION
This communication is responsive to applicant’s response filed under 37 C.F.R §1.111 in response to a non-final office action. Claim(s) 1, 8, and 15 have been amended; Claims 2-4, 9-11, and 16-18 have been canceled; No claim(s) have been added. Claim(s) 1, 5-8, 12-15, and 19-20 are subject to examination.
Acknowledgement is made to the applicant’s amendment to 1, 8, and 15 to obviate the previous claim objection to claims 1, 8, and 15. The previous claim objection to claim 1, 8, and 15 is/are hereby withdrawn.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see Remarks, filed 01/22/2026, with respect to the rejection(s) of claim(s) 1, 5-8, 12-15, and 19-20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of QIAO et al. (US 20190116521 A1).
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.
Claim(s) 1, 6-8, 13-15, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over YI et al. (US 20200236591 A1), hereby referred to as YI, and in view of QIAO et al. (US 20190116521 A1) (see IDS 08/23/2022), hereby referred to as QIAO.
Claim 1:
YI teaches a method for transmitting data, comprising: a sending end device determining, a type of the first data packet (YI: FIG. 6 wherein PDCP SDU includes the header field of a SDAP PDU and para 129 (…upon reception of a PDSCP SDU from an upper layer, the transmitting PDCP entity checks whether the PDCP SDU includes first type header (e.g. IP header) or second type header (e.g. Ethernet header)…The upper layer could be an SDAP layer…”) wherein the configuration file identifier is a header field within PDCP SDU that maps to a data packet type, such as Ethernet and IP), wherein different data packet types corresponding to different configuration file identifiers according to the second mapping relationship (YI: para 126 (“…depending on whether the PDCP SDU contains IP or Ethernet.”) wherein different header fields/different configuration file identifiers indicate different types); and generating a first packet data convergence protocol (PDCP) protocol data unit (PDU), comprising performing header compression processing on a first data packet according to the type of the first data packet (YI: FIG. 8 item S1001 (“PDCP SDU includes first type header or second type header?”) and para 130 (“IF the PDCP SDU includes first type header (E.g. IP header)…applies first type header compression algorithm…ROHC…If the PDCP SDU includes the second type header (e.g. Ethernet header)…applies the second type header…EHC…includes both the first type…and the second type…applies either…ROHC…or EHC based on the predetermined rule.”) wherein header compression is based on type of data packet), wherein the first PDCP PDU comprises type information, and the type information is used to indicate that the type of the first data packet in the first PDCP PDU is one of an Ethernet data packet, an Internet protocol (IP) data packet, and an Ethernet data packet comprising an IP packet header (YI: FIG. 8 item S1001 (“PDCP SDU includes first type header or second type header?”) and para 129-130 (“includes first type…IP header…or second type header…Ethernet header…includes both the first type (e.g., IP) and the second type (e.g., Ethernet) headers…”)) wherein headers indicate type information), wherein the first data packet and a second data packet are mapped to a same data radio bearer (DRB), and the type of the first data packet is different from a type of the second data packet (YI: para 125 (“If the PDCP entity is used for a DRB that serves multiple QoS flows, and if one QoS flow is for Ethernet traffic and another QoS flow is for IP traffic, the PDCP entity should serve PDCP SDU with Ethernet and PDSCP SDU with IP simultaneously.”) wherein different types of packets are mapped to the same DRB), wherein the type information is the first configuration file identifier of the first data packet (YI: FIG. 6 wherein PDCP SDU includes the header field of a SDAP PDU and para 129 (…upon reception of a PDSCP SDU from an upper layer, the transmitting PDCP entity checks whether the PDCP SDU includes first type header (e.g. IP header) or second type header (e.g. Ethernet header)…The upper layer could be an SDAP layer…”) wherein the configuration file identifier is a header field within PDCP SDU that maps to a data packet type, such as Ethernet and IP).
While YI teaches determining according to a second mapping relationship between a header compression configuration and a data packet type header corresponds to a type of the first data packet, that a data packet type corresponding to a first header compression configuration of a first data packet is a type of the first packet, wherein different data packet types corresponding to different header compression configurations according to the second mapping (YI: para 129-130 (“includes first type…IP header…or second type header…Ethernet header…includes both the first type (e.g., IP) and the second type (e.g., Ethernet) headers…"PDCP entity applies either the first header compression algorithm (e.g., ROHC) or EHC based on the predetermined rule…”) wherein there is a mapping/predetermined rule), YI does not explicitly disclose a configuration file identifier.
QIAO, in the same field of endeavor, teaches the configuration file identifier (QIAO: para 260 (“…the (R)AN 105 may send to UE 100 an RRC connection reconfiguration message comprising an information element (E.g. PDCP-Config IE) to set the configurable PDCP parameters for data radio bearer…may comprise the profiles for the header compression…”) and Table 12 wherein profile identifiers are configuration file identifiers/a header compression configuration).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to have modified YI with QIAO for the benefit of improving network signaling and performance (QIAO: para 171).
Claim 6:
YI-QIAO teaches the method according to claim 5, wherein the sending end device is a terminal device (YI: FIG. 2 wherein the sending end device may be a wireless device/terminal device), but does not explicitly disclose the method further comprises: the terminal device receiving the second mapping relationship sent by a network device.
QIAO, in the same field of endeavor, teaches the method further comprises: the terminal device receiving the second mapping relationship sent by a network device (QIAO: para 260 (“…the (R)AN 105 may send to UE 100 an RRC connection reconfiguration message comprising an information element (E.g. PDCP-Config IE) to set the configurable PDCP parameters for data radio bearer…may comprise the profiles for the header compression…”) and Table 12 wherein profile identifiers are mapped to packet types and sent from the network device).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to have modified YI with QIAO for the benefit of improving network signaling and performance (QIAO: para 171).
Claim 7:
YI-QIAO teaches the method according to claim 6, wherein the second mapping relationship is located in a radio resource control (RRC) message (QIAO: para 260 (“…the (R)AN 105 may send to UE 100 an RRC connection reconfiguration message comprising an information element (E.g. PDCP-Config IE) to set the configurable PDCP parameters for data radio bearer…may comprise the profiles for the header compression…”) and Table 12 wherein profile identifiers are in RRC message).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to have modified YI with QIAO for the benefit of improving network signaling and performance (QIAO: para 171).
Claim 8:
YI teaches a sending end device, comprising: a processor (YI: FIG. 2 item 102 (“Processor(s)”)). For further limitations see rejection for claim 1 above.
Claim 13:
YI-QIAO teaches the sending device according to claim 12. For further limitations, see rejection for claim 6 above.
Claim 14:
YI-QIAO teaches the sending device according to claim 13. For further limitations, see rejection for claim 7 above.
Claim 15:
YI teaches a chip, comprising a processor for calling and running a computer program from a memory (YI: para 87 (“The memory(s)…connected to the processor(s)…store a variety of information related to operation…Herein, the processor(s) 102 and the memory(s) 104 may be a part of a communication…chip…”)). For further limitations see rejection for claim 1 above.
Claim 20:
YI-QIAO teaches the chip according to claim 19, wherein the device is a terminal device (YI: FIG. 7 wherein the terminal is the UE), the chip further comprises: a transceiver (YI: FIG. 2 item 106 (“Transceiver(s)”)). For further limitations, see rejection for claim 6 above.
Claim(s) 1, 5, 8, 12, 15, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over YI in view of MACK-CRANE et al. (US 20140334492 A1), hereby referred to as MACK.
Examiner’s Note: Under broadest reasonable interpretation, first configuration file identifier can be interpreted as any sort of identifier which has a relationship with the data packet type. For example, QIAO’s profile identifiers or the filed specification’s QFI (para 91). However, it can be interpreted as header information within the PDCP SDU, indicating a packet type. Such as the YI’s header information included in PDCP SDU/PDCP PDU data field (YI para 129 (“…checks whether the PDCP SDU includes first type header…or second type header…”) wherein data field/PDCP SDU includes a header type). The examiner recommends to further define “configuration file identifier” to differentiate between QFI, Profile ID, or Header Protocol/Ethertype fields. See alternate interpretation below:
Claim 1:
YI teaches a method for transmitting data, comprising: a sending end device determining, a type of the first data packet (YI: FIG. 6 wherein PDCP SDU includes the header field of a SDAP PDU and para 129 (…upon reception of a PDSCP SDU from an upper layer, the transmitting PDCP entity checks whether the PDCP SDU includes first type header (e.g. IP header) or second type header (e.g. Ethernet header)…The upper layer could be an SDAP layer…”) wherein the configuration file identifier is a header field within PDCP SDU that maps to a data packet type, such as Ethernet and IP), wherein different data packet types corresponding to different configuration file identifiers according to the second mapping relationship (YI: para 126 (“…depending on whether the PDCP SDU contains IP or Ethernet.”) wherein different header fields/different configuration file identifiers indicate different types); and generating a first packet data convergence protocol (PDCP) protocol data unit (PDU), comprising performing header compression processing on a first data packet according to the type of the first data packet (YI: FIG. 8 item S1001 (“PDCP SDU includes first type header or second type header?”) and para 130 (“IF the PDCP SDU includes first type header (E.g. IP header)…applies first type header compression algorithm…ROHC…If the PDCP SDU includes the second type header (e.g. Ethernet header)…applies the second type header…EHC…includes both the first type…and the second type…applies either…ROHC…or EHC based on the predetermined rule.”) wherein header compression is based on type of data packet), wherein the first PDCP PDU comprises type information, and the type information is used to indicate that the type of the first data packet in the first PDCP PDU is one of an Ethernet data packet, an Internet protocol (IP) data packet, and an Ethernet data packet comprising an IP packet header (YI: FIG. 8 item S1001 (“PDCP SDU includes first type header or second type header?”) and para 129-130 (“includes first type…IP header…or second type header…Ethernet header…includes both the first type (e.g., IP) and the second type (e.g., Ethernet) headers…”)) wherein headers indicate type information), wherein the first data packet and a second data packet are mapped to a same data radio bearer (DRB), and the type of the first data packet is different from a type of the second data packet (YI: para 125 (“If the PDCP entity is used for a DRB that serves multiple QoS flows, and if one QoS flow is for Ethernet traffic and another QoS flow is for IP traffic, the PDCP entity should serve PDCP SDU with Ethernet and PDSCP SDU with IP simultaneously.”) wherein different types of packets are mapped to the same DRB), wherein the type information is the first configuration file identifier of the first data packet (YI: FIG. 6 wherein PDCP SDU includes the header field of a SDAP PDU and para 129 (…upon reception of a PDSCP SDU from an upper layer, the transmitting PDCP entity checks whether the PDCP SDU includes first type header (e.g. IP header) or second type header (e.g. Ethernet header)…The upper layer could be an SDAP layer…”) wherein the configuration file identifier is a header field within PDCP SDU that maps to a data packet type, such as Ethernet and IP).
While YI teaches determining, according to a second mapping relationship between a header identification and a data packet type, that a data packet type corresponding to a first header identification of a first data packet is a type of the first data packet wherein different data packet types corresponding to different header identifications according to the second mapping (YI: para 129-130 (“includes first type…IP header…or second type header…Ethernet header…includes both the first type (e.g., IP) and the second type (e.g., Ethernet) headers…PDCP entity applies either the first header compression algorithm (e.g., ROHC) or EHC based on the predetermined rule…”) wherein there are different header types/identification mapped to either an IP type Ethernet type or Ethernet with IP type), YI does not explicitly teach a configuration file identifier.
MACK, in the same field of endeavor, teaches configuration file identifier (MACK: para 21 (“Header types may be known to both SDN controllers and switches by either a common name (e.g., a character string like “Ethernet” or “IPv4”) or a specified header field value (e.g., EtherType value, IP header Protocol field value, etc.…”) wherein headers include configuration file identifiers/common name or specified header field values that map to a packet type).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to have modified YI with MACK, the combination hereby referred to as YI-MACK, for the benefit of adapting to support a variety of packet headers (MACK: para 3).
Claim 5:
YI-MACK teaches the method according to claim 1, a first information in a data field of the first PDCP PDU (YI FIG. 6 wherein header information is in the SDAP PDU/PDCP SDU and para 129 (“…checks whether the PDCP SDU includes first type header…or second type header…”) wherein data field/PDCP SDU includes a header type), but does not explicitly disclose wherein the first configuration file identifier.
MACK, in the same field of endeavor, teaches, the first configuration file identifier (MACK: para 21 (“Header types may be known to both SDN controllers and switches by either a common name (e.g., a character string like “Ethernet” or “IPv4”) or a specified header field value (e.g., EtherType value, IP header Protocol field value, etc.…”) wherein headers typically include configuration file identifiers/common name or specified header field values that map to a packet type).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to have modified YI with MACK, the combination hereby referred to as YI-MACK, for the benefit of adapting to support a variety of packet headers (MACK: para 3).
Claim 8:
YI teaches a sending end device, comprising: a processor (YI: FIG. 2 item 102 (“Processor(s)”)). For further limitations see rejection for claim 1 above.
Claim 12:
YI-MACK teaches the sending device according to claim 8. For further limitations, see rejection for claim 5 above.
Claim 15:
YI teaches a chip, comprising a processor for calling and running a computer program from a memory (YI: para 87 (“The memory(s)…connected to the processor(s)…store a variety of information related to operation…Herein, the processor(s) 102 and the memory(s) 104 may be a part of a communication…chip…”)). For further limitations see rejection for claim 1 above.
Claim 19:
YI-MACK teaches the chip of claim 15. For further limitations, see rejection for claim 5 above.
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 ANGELIE T NGO whose telephone number is (571)272-0180. The examiner can normally be reached Mon - Thur: 8am - 5pm; 2nd Fri: 8am - 3pm.
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, Noel Beharry can be reached at (571) 270-5630. 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.
/A.T.N./Examiner, Art Unit 2416
/NOEL R BEHARRY/Supervisory Patent Examiner, Art Unit 2416
Prosecution Insights