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 .
Response to Arguments
Applicant's arguments filed have been fully considered but they are not persuasive.
Argument 1 is Not Persuasive.
Regarding Applicant’s Argument 1, Applicant argues that modifying 3GPP TS 38.321 to provide fixed-length MAC SDU without an L field would render 3GPP unsatisfactory for its intended purpose and change its principle operation because section 6.1.2 states that MAC SDU are of variable sizes; and that the fixed-size with no L field of 3GPP relates to MAC control elements rather than MAC SDUs. Examiner disagrees. Non-obviousness cannot be established by attacking references individually where, as here, the ground of unpatentability is based upon the teachings of a combination of references. In re Keller, 642 F.2d 413, 426 (CCPA 1981). Rather, the test for obviousness is whether the combination of references, taken as a whole, would have suggested the patentee’s invention to a person having ordinary skill in the art. In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986). That is, Applicant is attempting to singularly argue that 3GPP TS 38.321 does not teach what the NonFinal Office action clearly states is in Parvall. That is, Parkvall discloses that MAC SDUs can have a fixed length without an L field. (See Parkvall para. 579) More particularly, Parvall states that MAC elements may be either MAC control elements or MAC SDU and expressly teaches that the structure [R/R/E/LCID] is used for fixed-length MAC SDUs and fixed-length MAC control elements, whereas [R/R/E/LCID/F/Length] is used for variable-length MAC SDUs and control elements. Parkvall further characterizes the arrangement as reusing the LTE channel structure. Therefore, the proposed modification does not require converting a MAC CE of 3GPP into a MAC SDU. Instead Parvall supplies the express teaching that a MAC SDU itself may be fixed length and may use a MAC subheader that omits the Length field.
Further, the fact that 3GPP itself describes MAC SDUs as variable in size does not establish that the underlying MAC architecture would become inoperable or unsatisfactory if the known fixed-length MAC-SDU teaching of Parkvall were applied. The intended function of the pertinent MAC structure remains the transport and multiplexing of MAC elements using MAC headers/subheaders. Parkvall demonstrates that fixed and variable length MAC SDUs can predictably coexist within substantially the same MAC header architecture.
Also, obviousness does not require bodily incorporating the precise structure of the secondary reference into the primary reference. In re Keller, 642 F.2d 413, 425 (CCPA 1981). The question is what the combined teachings would have suggested to one of ordinary skill in the art. Here, Parkvall’s express teaching of fixed-length MAC SDU using a no-Length subheader demonstrates that the modification is a known and predictable MAC-header alternative rather than a modification that destroys MAC operation.
Therefore, Applicant’s argument is not persuasive.
Argument 2 is Not Persuasive.
Regarding Applicant’s Argument 2, Applicant argues that ‘…by using the LCID, these features of claim 1 enable signaling that an LCH (logical channel) and a data length are unnecessary, thereby making it possible to indicate the absence of LCH and data length fields without utilizing information other than the LCID. Such an advantage is not disclosed in any of the cited references…’ Examiner disagrees with this logic. Claims are not rendered patentable merely because Applicant recognizes an additional advantage arising from an otherwise obvious structure. MPEP 2145 states that prima facie obviousness is not rebutted by merely recognizing additional advantages or latent properties present but not recognized in the prior art. Therefore, Applicant’s argument is not persuasive.
Argument 3 is Not Persuasive.
Regarding Applicant’s Argument 3, Applicant argues that ‘…3GPP TS 38.321 fails to disclose or suggest "the LCID in the MAC header [corresponding to the selected MAC header pattern not including information about a data length of the MSDU] ... being used for identifying the second logical channel for the second data [in the MSDU]" as recited by claim 1…’ . Examiner disagrees. Non-obviousness cannot be established by attacking references individually where, as here, the ground of unpatentability is based upon the teachings of a combination of references. In re Keller, 642 F.2d 413, 426 (CCPA 1981). Rather, the test for obviousness is whether the combination of references, taken as a whole, would have suggested the patentee’s invention to a person having ordinary skill in the art. In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986). Parkvall discloses that MAC SDUs can have a fixed length without an L field. (See Parkvall para. 579) More particularly, Parvall states that MAC elements may be either MAC control elements or MAC SDU and expressly teaches that the structure [R/R/E/LCID] is used for fixed-length MAC SDUs and fixed-length MAC control elements, whereas [R/R/E/LCID/F/Length] is used for variable-length MAC SDUs and control elements. Meylan further teaches the known use of an LCID value to cause the receiver to recognize particular MAC treatment. Specifically, fig. 4 of Meylan teaches setting the LCID to a specific value reserved for Random Access Response. That is, the combination would have been obvious to one of ordinary skill in the art possessing ordinary creativity. Therefore, Applicant’s argument is not persuasive.
Regarding claims 7, 9, and 11, Applicant presents no additional arguments but merely summarily concludes that these claims are patentable. Examiner disagrees and directs Applicant to arguments above and rejections below.
Regarding claim 3, Applicant argues ‘…3GPP TS 38.321, pg. 47-48, section 6.1.2, figures 6.1.2-3, 6.1.2-4, merely discloses that "Fixed-sized MAC CE." 3GPP TS 38.321 does not disclose a fixed sized MAC SDU. Thus, 3GPP TS 38.321 fails to disclose or suggest "wherein the data length of the MSDU including the second data is fixed" of claim 3…’ Examiner disagrees. First, the claim 3 rejection does not say the MSDU is fixed; Applicant is misreading the rejection. Second, claim 3 depends upon claim 1 imports all of the limitations and the entire rejection. That is, Parkvall does disclose that MAC SDUs can have a fixed length without an L field. As outlined above the combination of references does teach the limitations.
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.
Claims 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 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.)
Claims 13 and 14 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) 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).
Regarding claim 14, 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 LCID indicates logical channel. (See 3GPP TS 38.321 section 6.2.1; LCID field identifies logical channel of corresponding MAC SDU; table 6.2.1-1 and 6.2.1-2 assign LCID values to the id of the logical channel for both DL-SCH and UL SCH)
the selected MAC header pattern not including the information about the data
length; (See Parkvall para. 579, fig. 22; R/R/E/LCID for fixed length MAC SDU and R/R/E/LCID/F/Length for variable) 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 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
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.
Claims 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
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.
Claims 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
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.
Claims 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
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 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
Prosecution Insights