CTNF 17/231,149 CTNF 86046 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 07-37 AIA Applicant's arguments filed have been fully considered but they are not persuasive. Applicant has amended the claims and argued those amendments. Applicant has overcome the double patenting rejection. Examiner does not agree that the previous rejection was necessarily overcome by these amendments. Nonetheless, Examiner has provided new rejections to assuage any concerns Applicant may have had about the previous rejection . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-6 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 38.321 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 15)” v15.1.0; March 2018) and further in view of Parkvall (2017/0331577) and further in view of Meylan (2009/0156194) and further in view of Nimbalker (WO2018/032001) . Regarding claim 1, 3GPP TS 38.321 discloses a transmitting apparatus comprising: transmit first data for a first logical channel, and to transmit second data for a second logical channel; and (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4,6.1.2-5; multiple MSDU, MAC subPDU, some with fixed sized data inside and some with variable size data inside and identified by an LCID, logical channel identifier (e.g. logical channel)) select, from a plurality of medium access control (MAC) header patterns, a MAC header pattern for the second data, the selected MAC header pattern not including information about a data length of a MAC unit including the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not) set, to an LCID field, the selected LCID, wherein the LCID field is located across six bits starting with bit three and ending in bit eight of the first octet in a MAC header that corresponds to the MAC header pattern, (See 3GPP TS 38.321 pg. 46-48, section 6, 6.1.2, fig. 6.1.2-3; LCID field is set across 6 bits starting with bit 3 and ending at bit 8 of the Octet) place the MAC header corresponding to the selected MAC header pattern in front of the MAC unit including the second data, the LCID in the MAC header being used for the second data in the MAC unit and being used for identifying the second logical channel for the second data, and (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) multiplex the first data and the second data. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; multiple data units are multiplexed) 3GPP TS 38.321 discloses that MAC CE can have an L field for variable sized MAC CE or no L field for fixed-sized MAC CE. (See 3GPP TS 38.321 pg. 47-48) 3GPP TS 38.321 does not explicitly disclose that MAC SDUs (MSDUs) can be fixed length without an L field, a transmitter, and a processor. However, Parkvall does disclose that MAC SDUs (MSDUs) can be fixed length without an L field, a transmitter, and a processor. (See Parkvall para. 1865, 1864; processor and transceiver (e.g. transmitter/receiver); para. 579-580; MAC SDU can have fixed or variable length) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of that MAC SDUs (MSDUs) can be fixed length without an L field, a transmitter, and a processor of Parkvall with the motivation being to allow for reduced header overhead and further for faster processing and further for lower latency data and further for hardware efficiency by simplifying memory management and buffering and to decrease battery usage and further it is common sense that a device that transmits/receives has a transceiver and a processor for executing an algorithm in accordance with the method disclosed and further to allow for updating for new features and security and further to save money by using known components that are readily available. 3GPP TS 38.321 does not explicitly disclose select an LCID indicating the selected MAC header. However, Meylan does disclose select an LCID indicating the selected MAC header. (See Meylan fig. 4) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of select an LCID indicating the selected MAC header of Meylan with the motivation being to allow for quicker identification which could reduce delay and further to allow for special processing and further to reduce delay and further to maximize limited wireless resources by allowing for a hierarchy of priority and allowing the device to make better decisions about retransmissions, priority, throughput requirements, etc. 3GPP TS 38.321 does not explicitly disclose multiplexing two types of data. However, Nimbalker does disclose multiplexing two types of data. (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of multiplexing two types of data of Nimbalker with the motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently. Regarding claim 2, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1, wherein an R bit (reserved bit) is in the first bit and an R bit is in the second bit of the first octet in the MAC header. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-3; R bit in first and second bits of Octet 1) Regarding claim 3, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1, wherein the data length of the MSDU including the second data is fixed. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-3, 6.1.2-4; fixed-sized without L field) . Regarding claim 4, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1, wherein the second type includes Ultra-Reliable and Low-Latency Communication (URLLC). (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) The motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently Regarding claim 5, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1, wherein the first type includes Enhanced Mobile BroadBand (eMBB). (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) The motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently Regarding claim 6, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1. 3GPP TS 38.321 discloses wherein the data could be fixed in size or variable in size. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-4, 6.1.2-5) 3GPP TS 38.321 does not explicitly discloses wherein wherein the second data has a data size less than a data size of the first data. However, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of wherein the second data has a data size less than a data size of the first data with the motivation it is obvious to try (in that in at the time of the invention, there was a need to multiplex data of fixed and variable size and one of ordinary skill in the art could have pursued the known potential solutions with reasonable success; there are no unexpected results by the fixed size packets being smaller than the variable packets or vice versa) and further it is common sense (in that, the size of the packets in relation to each other could be less than, greater than, or equal; there is no unexpected results of one of ordinary skill in the art possessing ordinary creativity pursuing any of these options in order to meet network demands for throughput, delay, jitter, etc.) 07-21-aia AIA Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 38.321 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 15)” v15.1.0; March 2018) and further in view of Parkvall (2017/0331577) and further in view of Meylan (2009/0156194) and further in view of Nimbalker (WO2018/032001) and further in view of Duncan Ho (2009/0141670) . Regarding claim 13, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the transmitting apparatus according to claim 1. 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker does not explicitly disclose selecting a MAC header format based upon a data type. However, Duncan Ho does disclose selecting a MAC header format based upon a data type. (See Duncan Ho para. 62; select MAC header format based upon data type) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of selecting a MAC header format based upon a data type of Duncan Ho with the motivation being to allow for certain parameters to be sent unique to each data type and further to allow for specialized processing of certain data based upon the data type and header and further to reduce delay for certain sensitive data types and further to maximize limited bandwidth (by possibly eliminating unneeded fields) . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 38.321 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 15)” v15.1.0; March 2018) and further in view of Parkvall (2017/0331577) and further in view of Meylan (2009/0156194) and further in view of Nimbalker (WO2018/032001) . Regarding claim 9, 3GPP TS 38.321 discloses a wireless communication method comprising: transmitting first data for a first logical channel, and transmitting second data for a second logical channel, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4,6.1.2-5; multiple MSDU, MAC subPDU, some with fixed sized data inside and some with variable size data inside and identified by an LCID, logical channel identifier (e.g. logical channel)) select, from a plurality of medium access control (MAC) header patterns, a MAC header pattern for the second data, the selected MAC header pattern not including information about a data length of a MAC unit including the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not) setting, to an LCID field, the selected LCID, wherein the LCID field is located across six bits starting with bit three and ending in bit eight of the first octet in a MAC header that corresponds to the MAC header pattern, (See 3GPP TS 38.321 pg. 46-48, section 6, 6.1.2, fig. 6.1.2-3; LCID field is set across 6 bits starting with bit 3 and ending at bit 8 of the Octet) placing the MAC header corresponding to the selected MAC header pattern in front of the MAC unit including the second data, the LCID in the MAC header being used for the second data in the MAC unit and being used for identifying the second logical channel for the second data, and (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) multiplexing the first data and the second data. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; multiple data units are multiplexed) 3GPP TS 38.321 does not explicitly disclose that MAC SDUs (MSDUs) can be fixed length without an L field. However, Parkvall does disclose that MAC SDUs (MSDUs) can be fixed length without an L field. (See Parkvall para. 1865, 1864; processor and transceiver (e.g. transmitter/receiver); para. 579-580; MAC SDU can have fixed (without L field) or variable length (with L field)) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of that MAC SDUs (MSDUs) can be fixed length without an L field of Parkvall with the motivation being to allow for reduced header overhead and further for faster processing and further for lower latency data and further for hardware efficiency by simplifying memory management and buffering and to decrease battery usage. 3GPP TS 38.321 does not explicitly disclose select an LCID indicating the selected MAC header. However, Meylan does disclose select an LCID indicating the selected MAC header. (See Meylan fig. 4) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of select an LCID indicating the selected MAC header of Meylan with the motivation being to allow for quicker identification which could reduce delay and further to allow for special processing and further to reduce delay and further to maximize limited wireless resources by allowing for a hierarchy of priority and allowing the device to make better decisions about retransmissions, priority, throughput requirements, etc. 3GPP TS 38.321 does not explicitly disclose multiplexing two types of data. However, Nimbalker does disclose multiplexing two types of data. (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of multiplexing two types of data of Nimbalker with the motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently. Regarding claim 10, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the wireless communication method of claim 9, wherein an R bit (reserved bit) is in the first bit and an R bit is in the second bit of the first octet in the MAC header. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-3; R bit in first and second bits of Octet 1) Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 38.321 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 15)” v15.1.0; March 2018) and further in view of Parkvall (2017/0331577) and further in view of Meylan (2009/0156194) and further in view of Nimbalker (WO2018/032001) . Regarding claim 7, 3GPP TS 38.321 discloses a receiving apparatus, comprising: receive first data for a first logical channel, and to receive second data of for a second logical channel; and (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4,6.1.2-5; multiple MSDU, MAC subPDU, some with fixed sized data inside and some with variable size data inside and identified by an LCID, logical channel identifier (e.g. logical channel)) perform data processing according to a medium access control (MAC) header placed in front of the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not; para. 46-47, section 6.1; MAC entity ignores values of Reserved bits in downlink (e.g. implying it does not ignore the other values and uses them); para. 9-11; MAC entity provides services to upper layer (e.g. data processing is performed)) wherein the MAC header is placed in front of a MAC unit including the second data, the MAC header corresponding to a MAC header pattern that is selected from a plurality of MAC header patterns, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) the selected MAC header pattern not including information about a data length of the MAC unit including the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not) wherein the first data and the second data are multiplexed, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; multiple data units are multiplexed) wherein an LCID (Logical Channel Identity) field is located across six bits starting with bit three and ending in bit eight of the first octet in the MAC header, (See 3GPP TS 38.321 pg. 46-48, section 6, 6.1.2, fig. 6.1.2-3; LCID field is set across 6 bits starting with bit 3 and ending at bit 8 of the Octet) wherein the LCID in the MAC header is used for the second data in the MAC unit and is used for identifying the second logical channel for the second data. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) 3GPP TS 38.321 discloses that MAC CE can have an L field for variable sized MAC CE or no L field for fixed-sized MAC CE. (See 3GPP TS 38.321 pg. 47-48) 3GPP TS 38.321 does not explicitly disclose that MAC SDUs (MSDUs) can be fixed length without an L field, a receiver, and a processor. However, Parkvall does disclose that MAC SDUs (MSDUs) can be fixed length without an L field, a receiver, and a processor. (See Parkvall para. 1865, 1864; processor and transceiver (e.g. transmitter/receiver); para. 579-580; MAC SDU can have fixed or variable length) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of that MAC SDUs (MSDUs) can be fixed length without an L field, a receiver, and a processor of Parkvall with the motivation being to allow for reduced header overhead and further for faster processing and further for lower latency data and further for hardware efficiency by simplifying memory management and buffering and to decrease battery usage and further it is common sense that a device that transmits/receives has a transceiver and a processor for executing an algorithm in accordance with the method disclosed and further to allow for updating for new features and security and further to save money by using known components that are readily available. 3GPP TS 38.321 does not explicitly disclose select an LCID indicating the selected MAC header. However, Meylan does disclose select an LCID indicating the selected MAC header. (See Meylan fig. 4) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of select an LCID indicating the selected MAC header of Meylan with the motivation being to allow for quicker identification which could reduce delay and further to allow for special processing and further to reduce delay and further to maximize limited wireless resources by allowing for a hierarchy of priority and allowing the device to make better decisions about retransmissions, priority, throughput requirements, etc. 3GPP TS 38.321 does not explicitly disclose multiplexing two types of data. However, Nimbalker does disclose multiplexing two types of data. (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of multiplexing two types of data of Nimbalker with the motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently. Regarding claim 8, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the receiving apparatus according to claim 7, wherein an R bit (reserved bit) is in the first bit and an R bit is in the second bit of the first octet in the MAC header. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-3; R bit in first and second bits of Octet 1) Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 38.321 (“3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Medium Access Control (MAC) protocol specification (Release 15)” v15.1.0; March 2018) and further in view of Parkvall (2017/0331577) and further in view of Meylan (2009/0156194) and further in view of Nimbalker (WO2018/032001) . Regarding claim 11, 3GPP TS 38.321 discloses a wireless communication method comprising: receiving first data for a first logical channel, and second data for a second logical channel, and (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4,6.1.2-5; multiple MSDU, MAC subPDU, some with fixed sized data inside and some with variable size data inside and identified by an LCID, logical channel identifier (e.g. logical channel)) performing data processing according to a medium access control (MAC) header placed in front of the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not; para. 46-47, section 6.1; MAC entity ignores values of Reserved bits in downlink (e.g. implying it does not ignore the other values and uses them); para. 9-11; MAC entity provides services to upper layer (e.g. data processing is performed)) wherein the MAC header is placed in front of a MAC unit including of the second data, the MAC header corresponding to a MAC header pattern that is selected from a plurality of MAC header patterns, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) the selected MAC header pattern not including information about a data length of the MAC unit including the second data, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-1, 6.1.2-2, 6.1.2-3; plurality of MAC header patterns some not including a L, length, field, header is picked based upon whether the data is fixed or not) wherein the first data and the second data are multiplexed, (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; multiple data units are multiplexed) wherein an LCID (Logical Channel Identity) field is located across six bits starting with bit three and ending in bit eight of the first octet in the MAC header, (See 3GPP TS 38.321 pg. 46-48, section 6, 6.1.2, fig. 6.1.2-3; LCID field is set across 6 bits starting with bit 3 and ending at bit 8 of the Octet) wherein the LCID in the MAC header is used for the second data in the MAC unit and is used for identifying the second logical channel for the second data. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, fig. 6.1.2-4, 6.1.2-5; selected MAC header is put in front of data which contains an LCID, logical channel id (e.g. identifying the logical channel for the second data)) 3GPP TS 38.321 discloses that MAC CE can have an L field for variable sized MAC CE or no L field for fixed-sized MAC CE. (See 3GPP TS 38.321 pg. 47-48) 3GPP TS 38.321 does not explicitly disclose that MAC SDUs (MSDUs) can be fixed length without an L field. However, Parkvall does disclose that MAC SDUs (MSDUs) can be fixed length without an L field. (See Parkvall para. 1865, 1864; processor and transceiver (e.g. transmitter/receiver); para. 579-580; MAC SDU can have fixed or variable length) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of that MAC SDUs (MSDUs) can be fixed length without an L field of Parkvall with the motivation being to allow for reduced header overhead and further for faster processing and further for lower latency data and further for hardware efficiency by simplifying memory management and buffering and to decrease battery usage and further it is common sense that a device that transmits/receives has a transceiver and a processor for executing an algorithm in accordance with the method disclosed and further to allow for updating for new features and security and further to save money by using known components that are readily available. 3GPP TS 38.321 does not explicitly disclose select an LCID indicating the selected MAC header. However, Meylan does disclose select an LCID indicating the selected MAC header. (See Meylan fig. 4) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of select an LCID indicating the selected MAC header of Meylan with the motivation being to allow for quicker identification which could reduce delay and further to allow for special processing and further to reduce delay and further to maximize limited wireless resources by allowing for a hierarchy of priority and allowing the device to make better decisions about retransmissions, priority, throughput requirements, etc. 3GPP TS 38.321 does not explicitly disclose multiplexing two types of data. However, Nimbalker does disclose multiplexing two types of data. (See Nimbalker para. 1, 18, multiplexing eMBB or URLLC (e.g. different types)) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the apparatus of 3GPP TS 38.321 to include the teaching of multiplexing two types of data of Nimbalker with the motivation being to provide a variety of abilities to users seeking different goals such as eMBB users seeking massive data throughput, high capacity, and faster speeds while URLLC may seek extreme reliability, ultra-low latency (<1ms) and further to meet end user goals and maximizing limited wireless resources by meeting end user goals efficiently. Regarding claim 12, 3GPP TS 38.321 in view of Parkvall in view of Meylan in view of Nimbalker discloses the wireless communication method of claim 11, wherein an R bit (reserved bit) is in the first bit and an R bit is in the second bit of the first octet in the MAC header. (See 3GPP TS 38.321 pg. 47-48, section 6.1.2, figure 6.1.2-3; R bit in first and second bits of Octet 1) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN J CLAWSON whose telephone number is (571)270-7498. The examiner can normally be reached M-F 7:30-5:00 pm est. 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, Huy D Vu can be reached at (571) 272-3155. 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. /Stephen J Clawson/Primary Examiner, Art Unit 2461 Application/Control Number: 17/231,149 Page 2 Art Unit: 2461 Application/Control Number: 17/231,149 Page 3 Art Unit: 2461 Application/Control Number: 17/231,149 Page 4 Art Unit: 2461 Application/Control Number: 17/231,149 Page 5 Art Unit: 2461 Application/Control Number: 17/231,149 Page 6 Art Unit: 2461 Application/Control Number: 17/231,149 Page 7 Art Unit: 2461 Application/Control Number: 17/231,149 Page 8 Art Unit: 2461 Application/Control Number: 17/231,149 Page 9 Art Unit: 2461 Application/Control Number: 17/231,149 Page 10 Art Unit: 2461 Application/Control Number: 17/231,149 Page 11 Art Unit: 2461 Application/Control Number: 17/231,149 Page 12 Art Unit: 2461 Application/Control Number: 17/231,149 Page 13 Art Unit: 2461 Application/Control Number: 17/231,149 Page 14 Art Unit: 2461 Application/Control Number: 17/231,149 Page 15 Art Unit: 2461 Application/Control Number: 17/231,149 Page 16 Art Unit: 2461 Application/Control Number: 17/231,149 Page 17 Art Unit: 2461 Application/Control Number: 17/231,149 Page 18 Art Unit: 2461 Application/Control Number: 17/231,149 Page 19 Art Unit: 2461
Prosecution Insights