DETAILED ACTION
This action is responsive to claims filed on 10/16/2024.
Claims 1-20 are pending examination.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/16/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
Acknowledgment is made of applicant’s claim for domestic benefit/national stage under 35 U.S.C. 119(e), 120, 121, 365(c), or 386(c) for parent Application No PCT/CN2022/088094 filed on 4/21/2022.
Drawings
The drawings were received on 10/16/2024. These drawings are acceptable.
Abstract
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because the abstract has less than 50 words in length. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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-18 are rejected under pre-AIA 35 U.S.C. 103 as being unpatentable over Kim et al. (US 20220014966 A1; hereinafter Kim) and further in view of Wang et al. (US 20230224383 A1; hereinafter Wang).
Regarding Claim 1, Kim disclose(s):
A data transmission method, comprising:
receiving, by a Packet Data Convergence Protocol (PDCP) layer, a first Service Data Adaptation Protocol (SDAP) Packet Data Unit (PDU) sent by a SDAP layer, the first SDAP PDU being a downlink SDAP control PDU, wherein the downlink SDAP control PDU comprises at least one of following information: [ (See Kim ¶165-170; Fig. 1E, 1Q, and 1R)
[0168] FIG. 1R is a diagram illustrating SDAP control data (SDAP control PDU or end-marker control PDU) generated by an SDAP layer device.
[0169] In FIG. 1R, 1r-01 represents a structure of SDAP control data, and may have the same structure as that of an uplink SDAP header. The SDAP control data structure is SDAP control data indicating that the data flow corresponding to a QFI field value has ended or is the last with a field indicating a QoS Flow ID (QFI), and may be called an end marker control PDU.
[0170] In the following description of the disclosure, when it is set to use the SDAP layer device or when it is set to use the SDAP header and when UDC is set by an RRC message such as 1e-10, 1e-40, or 1e-75 in FIG. 1E, if the transmitting PDCP layer device receives SDAP control data from an upper layer device (e.g., SDAP layer device), methods for efficiently processing SDAP control data are proposed.
PNG
media_image1.png
637
415
media_image1.png
Greyscale
PNG
media_image2.png
541
405
media_image2.png
Greyscale
PNG
media_image3.png
357
372
media_image3.png
Greyscale
]
first information for indicating whether the first SDAP PDU is a data PDU or a control PDU; [(See Kim ¶165-170; ¶192-198 Fig. 1R and 2i)
[0168] FIG. 1R is a diagram illustrating SDAP control data (SDAP control PDU or end-marker control PDU) generated by an SDAP layer device. A specific 1-1 embodiment of the transmitter and the receiver performing the security check procedure in the disclosure is as follows.
[0192] As another method, data processing may be performed using a 1-bit D/C field of an SDAP header 1r-01 or SDAP control data instead of a 1-bit indicator of the PDCP header. For example, when the 1-bit D/C field of the SDAP header 1r-01 or the SDAP control data indicates SDAP control data (when the D/C field is 0, it may indicate SDAP control data, and when the D/C field is 1, it may indicate SDAP user data (or SDAP header)), it may indicate that there is no UDC header or that there is no UDC header and that only SDAP control data to which user compression is not applied is included. Therefore, the transmitting PDCP layer device does not need to generate a UDC header. The receiving PDCP layer device may first identify the 1-bit D/C field of the SDAP header or SDAP control data before applying the user decompression procedure, and when the SDAP user data or SDAP header is indicated, the receiving PDCP layer device may process the UDC header as in the other embodiments and perform a user decompression procedure. When the 1-bit D/C field of SDAP control data or the SDAP header indicates SDAP control data, the receiving PDCP layer device determines that there is no UDC header and the SDAP control data is not ciphered; thus, the receiving PDCP layer device may not apply a deciphering procedure, but process quickly SDAP control data without applying a user data decompression procedure. In other words, the transmitting PDCP layer device and the receiving PDCP layer device may separate and process SDAP control data (SDAP control PDU) and SDAP user data (SDAP data PDU).
PNG
media_image3.png
357
372
media_image3.png
Greyscale
]
second information for indicating a Quality of Service (Qos) flow Identifier (ID) associated with the first SDAP PDU; [(See Kim ¶165-170; Fig. 1R and 2i)
[0168] FIG. 1R is a diagram illustrating SDAP control data (SDAP control PDU or end-marker control PDU) generated by an SDAP layer device. A specific 1-1 embodiment of the transmitter and the receiver performing the security check procedure in the disclosure is as follows.
[0169] In FIG. 1R, 1r-01 represents a structure of SDAP control data, and may have the same structure as that of an uplink SDAP header. The SDAP control data structure is SDAP control data indicating that the data flow corresponding to a QFI field value has ended or is the last with a field indicating a QoS Flow ID (QFI), and may be called an end marker control PDU.
]
third information for indicating a control PDU type to which the first SDAP PDU belongs; [(See Kim ¶165-170; ¶403-405; Fig. 1R and 2i)
[0168] FIG. 1R is a diagram illustrating SDAP control data (SDAP control PDU or end-marker control PDU) generated by an SDAP layer device. A specific 1-1 embodiment of the transmitter and the receiver performing the security check procedure in the disclosure is as follows.
[0404] Transmitter: When an integrity verification failure or a deciphering failure occurs, when an HFN asynchronous problem is suspected, or when a hacker intrusion is suspected, in order to trigger the security check procedure, the transmitter may define a PDU type as in 2i-05 to newly define and use a first PDCP control PDU…
PNG
media_image3.png
357
372
media_image3.png
Greyscale
PNG
media_image4.png
211
289
media_image4.png
Greyscale
]
fifth information for indicating a QoS attribute of the PDU [(See Kim ¶163-170; Fig. 1Q)
[0163] In the disclosure, a sixth embodiment of efficiently performing a user data compression method when the SDAP layer device is set or the SDAP header is set based on an RRC message is proposed as follows. In the sixth embodiment, it is characterized that the user data compression method is not applied to the SDAP header and that the SDAP header is not ciphered and that the UDC header is not ciphered, and due to the above characteristics, there is the advantage that the transmitter or the receiver may use QoS information of the SDAP header without the need for a deciphering procedure of information of the SDAP header. Further, because the UDC header was not ciphered, the receiving PDCP layer device may identify a checksum field of the UDC header before deciphering to identify integrity of the UDC buffer, and when there is an error in integrity, the receiving PDCP layer device may immediately discard the data without deciphering to reduce unnecessary data processing. When the checksum field identification of the UDC header passes, the receiving PDCP layer device may perform a deciphering procedure on data except for the PDCP header, the SDAP header, and the UDC header, and then apply a decompression procedure. For example, the base station may use the QoS information for scheduling, and even in the UE implementation, the receiving PDCP layer device may perform an UDC procedure and ciphering on data received from the upper layer with a hardware accelerator without the need to generate an SDAP header or UDC header whenever upper layer data is received, and in implementation, because the SDAP header or the UDC header may be generated and attached later, it is easy in the UE implementation. Further, in the sixth embodiment of the disclosure, by positioning the SDAP header in front of the UDC header, a structure of the PDCP PDU may configure data in order of the PDCP header, the SDAP header, the UDC header, and the compressed data (e.g., PDCP SDU), and when the PDCP layer device performs an UDC compression procedure, the UDC header may be together generated; thus, it may be easy in implementation that the UDC header may be positioned in front of the pressed data. Accordingly, in the sixth embodiment, it may be characterized by having a structure in which the UDC header is positioned behind the SDAP header to concatenate the UDC header and compressed data.
PNG
media_image5.png
549
438
media_image5.png
Greyscale
]
sixth information for indicating an ID of the PDU set or the frame associated with the first SDAP PDU;
seventh information for indicating an ID of a Group of Pictures (GOP) to which the PDU set or the frame associated with the first SDAP PDU belongs; or
eighth information for indicating IDs of at least part of PDUs in the PDU set associated with the first SDAP PDU.
Kim does not explicitly disclose:
fourth information for indicating a frame type corresponding to a PDU set or a frame associated with the first SDAP PDU;
fifth information for indicating a QoS attribute of the PDU set, the frame or a PDU associated with the first SDAP PDU;
sixth information for indicating an ID of the PDU set or the frame associated with the first SDAP PDU;
seventh information for indicating an ID of a Group of Pictures (GOP) to which the PDU set or the frame associated with the first SDAP PDU belongs; or
eighth information for indicating IDs of at least part of PDUs in the PDU set associated with the first SDAP PDU.
However Wang, analogous art also teaching SDAP PDU transmissions does disclose:
fourth information for indicating a frame type corresponding to a PDU set or a frame associated with the first SDAP PDU; [(See Wang ¶32; ¶47-48; Fig. 4)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic)..]
fifth information for indicating a QoS attribute of the PDU set, the frame or a PDU associated with the first SDAP PDU; [(See Wang ¶32; ¶47-55; Fig. 4)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
[0055] XR traffic can have different QoS requirements than traffic of other applications due to the specific traffic characteristics of XR traffic. For example, not all packets in an XR traffic are equally important, and different packets may have different QoS requirements. Not all bits within an ADU are equally significant, and different packet delay budgets (PDBs) may be assigned for packets within one ADU. ADU-based error rate (AER) (the percentage of ADUs in error in a specified measurement window) can be defined as a QoS parameter. Different data rates, PDBs, packet error rates (PER), AER, and the like, can be specified for different streams from one XR traffic.]
sixth information for indicating an ID of the PDU set or the frame associated with the first SDAP PDU; [(See Wang ¶32; ¶47-55; Fig. 4)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
[0055] XR traffic can have different QoS requirements than traffic of other applications due to the specific traffic characteristics of XR traffic. For example, not all packets in an XR traffic are equally important, and different packets may have different QoS requirements. Not all bits within an ADU are equally significant, and different packet delay budgets (PDBs) may be assigned for packets within one ADU. ADU-based error rate (AER) (the percentage of ADUs in error in a specified measurement window) can be defined as a QoS parameter. Different data rates, PDBs, packet error rates (PER), AER, and the like, can be specified for different streams from one XR traffic.]
seventh information for indicating an ID of a Group of Pictures (GOP) to which the PDU set or the frame associated with the first SDAP PDU belongs; or [(See Wang ¶32; ¶47-55; Fig. 4)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
[0055] XR traffic can have different QoS requirements than traffic of other applications due to the specific traffic characteristics of XR traffic. For example, not all packets in an XR traffic are equally important, and different packets may have different QoS requirements. Not all bits within an ADU are equally significant, and different packet delay budgets (PDBs) may be assigned for packets within one ADU. ADU-based error rate (AER) (the percentage of ADUs in error in a specified measurement window) can be defined as a QoS parameter. Different data rates, PDBs, packet error rates (PER), AER, and the like, can be specified for different streams from one XR traffic.]
eighth information for indicating IDs of at least part of PDUs in the PDU set associated with the first SDAP PDU. [(See Wang ¶32; ¶47-55; Fig. 4)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
[0055] XR traffic can have different QoS requirements than traffic of other applications due to the specific traffic characteristics of XR traffic. For example, not all packets in an XR traffic are equally important, and different packets may have different QoS requirements. Not all bits within an ADU are equally significant, and different packet delay budgets (PDBs) may be assigned for packets within one ADU. ADU-based error rate (AER) (the percentage of ADUs in error in a specified measurement window) can be defined as a QoS parameter. Different data rates, PDBs, packet error rates (PER), AER, and the like, can be specified for different streams from one XR traffic.]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the communication system of Kim with that of Wang to include various packet information in order to be aware of attributes carried in particular data packets, as per Wang (¶47-48), with reasonable expectation of success.
Regarding Claims 2 and 13, Kim and Wang disclose(s):
The method of claim 1, further comprising:
identifying, by the PDCP layer based on the downlink SDAP control PDU, SDAP PDUs or SDAP Service Data Units (SDUs) having an association relationship, wherein the association relationship means belonging to a same PDU set or a same frame. [(See Wang ¶32; ¶47-55; ¶89-93; Fig. 4 and 8)
[0089] In the process 800, the PDCP layer assigns the discard timers based on knowledge of the packet characteristic of the XR packet when a PDCP SDU is received from an upper layer. There may be two alternatives for knowing the packet characteristics. One is that the PDCP layer itself inspects the packets (e.g., by looking at the IP header and/or the RTP header). The other alternative is that the upper layer (e.g., SDAP layer) can perform packet inspection and indicate the packet attribute to the PDCP layer when it delivers the packet to the PDCP layer. For example, interlayer signaling can be employed. In an embodiment, the packet attribute information can be carried in an SDAP header of an SDAP PDU.
[0090] Generally, different discard timer time interval values may be assigned to different types of the XR data packets with an aim to allow the more important packets to have more opportunity to be transmitted and to have less opportunity to be dropped. In addition, for the same type of XR data packets, different discard timer values may be assigned in some examples.
[0091] During the process 800, the packets belonging to a same ADU can be treated collectively. From an XR application perspective, XR video frames may be independent or dependent on other previous and/or future frames. Therefore, if an IP packet belonging to a particular ADU arrives too late, it may negatively affect previous ADUs, upcoming ADUs, as well as the play-out time of the current ADU. Thus, in some embodiments, all relevant PDCP packets that carry the IP packets belonging to an ADU (which may not be used for XR rendering) are dropped together. This can be beneficial from a capacity point of view. The media streaming transport layer (e.g., RTP) can be employed to provide ADU information for each member packet within a protocol header in order to help a radio layer protocol (e.g., PDCP) to get the ADU information for each packet.
[0092] In some embodiments, a set of coordinated PDCP discard timers is assigned to all the relevant PDCP packets that carry the IP packets belonging to an ADU (or other XR data packet unit that is used at the media stream transport layer). In some embodiments, a set of coordinated PDCP discard timers is assigned to all the relevant PDCP packets that carry the IP packets belonging to a particular XR frame (or other unit that is used at XR encoder). As a result, all the PDCP packets for an XR ADU or a XR frame (or another type of unit) can be discarded together.
[0093] To achieve coordinated PDCP packets dropping for these packets, in an embodiment, the PDCP may set the same discard timer for all of these packets (i.e. the packets belongs to an ADU or a XR frame) and then start the timer at the same time. In an embodiment, the packets, received by PDCP layer from the upper layer not at the same time, can be assigned with a set of coordinated discard timer values in order to trigger group based coordinated PDCP packet dropping. For example, at time point T, the PDCP layer receives a PDCP SDU-1 for ADU-1 or XR frame-1, and the discard timer can be set with 60 ms. Then at time point T+10 ms, when the PDCP layer receives a PDCP SDU-2 for ADU-1 or XR frame-1, the discard timer can be set with 50 ms. In an embodiment, the PDCP layer records the XR ADU and XR frame that the PDCP SDU belongs to. In case of PDCP SDU discarding, the PDCP layer can discard all of the PDCP SDUs belonging to the same XR ADU and XR frame regardless of whether the discard timers expire or not.
]
Regarding Claim 3 and 14, Kim and Wang disclose(s):
The method of claim 1, further comprising:
receiving, by the PDCP layer, a second SDAP PDU sent by the SDAP layer, the second SDAP PDU being a downlink SDAP data PDU, wherein the downlink SDAP data PDU in a first format comprises first information for indicating whether the second SDAP PDU is a data PDU or a control PDU. [(See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i and see Wang ¶32; ¶47-55; Fig.2 )
((See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i)
[0406] A detailed 1-2 embodiment of the transmitter and the receiver performing a security check procedure in the disclosure is as follows. [0407] Transmitter: When an integrity verification failure or a deciphering failure occurs, when an HFN asynchronous problem is suspected, or when a hacker intrusion is suspected, in order to trigger the security check procedure, the transmitter may define a PDU type as in 2i-10 to newly define and use a third PDCP control PDU or to define a new 1-bit S field to the third PDCP control PDU. Alternatively, a new 1-bit S field may be defined to the PDCP header of the PDCP data PDU as in 2i-20. That is, a third PDCP control PDU or a PDCP data PDU in which a PDCP header including a new 1-bit S field is concatenated may be used as a security check request message in FIG. 2H…
[0408] Receiver: When the receiver receives a security check request message through the third PDCP control PDU, the receiver defines a fourth PDCP control PDU as in 2i-15 and include and transmit security key values (e.g., security identifier, security key value, or COUNT value) using in the receiver. For example, the receiver may include and transmit a COUNT value corresponding to data having a highest PDCP sequence number among data transmitted so far from the transmitting PDCP layer device or a COUNT value corresponding to data having a highest PDCP sequence number among data received so far in the receiving PDCP layer device in the fourth PDCP control PDU…
PNG
media_image6.png
671
327
media_image6.png
Greyscale
(See Wang ¶32; ¶47-55; Fig.2 and 15)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
]
Regarding Claims 4 and 15, Kim and Wang disclose(s):
The method of claim 3, wherein the PDCP layer and the SDAP layer are protocol layers of a network device; and the method further comprises:
determining, by the network device, whether a format of the downlink SDAP data PDU is a first format or a second format. [ (See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i)]
Regarding Claims 5 and 16, Kim and Wang disclose(s):
The method of claim 4, wherein determining, by the network device, whether the format of the downlink SDAP data PDU is the first format or the second format comprises:
if the network device receives first capability information reported by a terminal device, determining, by the network device, that the format of the downlink SDAP data PDU is the first format; and (See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
if the network device does not receive the first capability information reported by the terminal device, determining, by the network device, that the format of the downlink SDAP data PDU is the second format, (See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
wherein the first capability information is used for indicating that the terminal device supports the downlink SDAP data PDU in the first format. [(See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
Regarding Claims 6 and 17, Kim and Wang disclose(s):
The method of claim 4, wherein determining, by the network device, whether the format of the downlink SDAP data PDU is the first format or the second format comprises:
receiving, by the network device, second capability information reported by a terminal device; (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
if the second capability information indicates that the terminal device supports a first capability, determining, by the network device, that the format of the downlink SDAP data PDU is the first format; and (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
if the second capability information indicates that the terminal device does not support the first capability, determining, by the network device, that the format of the downlink SDAP data PDU is the second format, (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
wherein the first capability is a capability that the terminal device supports the downlink SDAP data PDU in the first format, or the first capability is a capability that the terminal device supports a first protocol version. (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶32; ¶47-55; Fig.2 and 15)
Regarding Claim 7, Kim disclose(s):
A data transmission method, comprising:
receiving, by a terminal device, a indicating whether the second SDAP PDU is a data PDU or a control PDU. [(See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i and see Wang ¶32; ¶47-55; Fig.2 )
(See Kim ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1R, 2E, 2i)
[0192] As another method, data processing may be performed using a 1-bit D/C field of an SDAP header 1r-01 or SDAP control data instead of a 1-bit indicator of the PDCP header. For example, when the 1-bit D/C field of the SDAP header 1r-01 or the SDAP control data indicates SDAP control data (when the D/C field is 0, it may indicate SDAP control data, and when the D/C field is 1, it may indicate SDAP user data (or SDAP header)), it may indicate that there is no UDC header or that there is no UDC header and that only SDAP control data to which user compression is not applied is included. Therefore, the transmitting PDCP layer device does not need to generate a UDC header. The receiving PDCP layer device may first identify the 1-bit D/C field of the SDAP header or SDAP control data before applying the user decompression procedure, and when the SDAP user data or SDAP header is indicated, the receiving PDCP layer device may process the UDC header as in the other embodiments and perform a user decompression procedure. When the 1-bit D/C field of SDAP control data or the SDAP header indicates SDAP control data, the receiving PDCP layer device determines that there is no UDC header and the SDAP control data is not ciphered; thus, the receiving PDCP layer device may not apply a deciphering procedure, but process quickly SDAP control data without applying a user data decompression procedure. In other words, the transmitting PDCP layer device and the receiving PDCP layer device may separate and process SDAP control data (SDAP control PDU) and SDAP user data (SDAP data PDU).
[0406] A detailed 1-2 embodiment of the transmitter and the receiver performing a security check procedure in the disclosure is as follows. [0407] Transmitter: When an integrity verification failure or a deciphering failure occurs, when an HFN asynchronous problem is suspected, or when a hacker intrusion is suspected, in order to trigger the security check procedure, the transmitter may define a PDU type as in 2i-10 to newly define and use a third PDCP control PDU or to define a new 1-bit S field to the third PDCP control PDU. Alternatively, a new 1-bit S field may be defined to the PDCP header of the PDCP data PDU as in 2i-20. That is, a third PDCP control PDU or a PDCP data PDU in which a PDCP header including a new 1-bit S field is concatenated may be used as a security check request message in FIG. 2H…
[0408] Receiver: When the receiver receives a security check request message through the third PDCP control PDU, the receiver defines a fourth PDCP control PDU as in 2i-15 and include and transmit security key values (e.g., security identifier, security key value, or COUNT value) using in the receiver. For example, the receiver may include and transmit a COUNT value corresponding to data having a highest PDCP sequence number among data transmitted so far from the transmitting PDCP layer device or a COUNT value corresponding to data having a highest PDCP sequence number among data received so far in the receiving PDCP layer device in the fourth PDCP control PDU…
PNG
media_image6.png
671
327
media_image6.png
Greyscale
Kim does not explicitly disclose:
A data transmission method, comprising:
receiving, by a terminal device, a second Service Data Adaptation Protocol (SDAP) Packet Data Unit (PDU) sent by a network device, the second SDAP PDU being a downlink SDAP data PDU, wherein the downlink SDAP data PDU in a first format comprises first information for indicating whether the second SDAP PDU is a data PDU or a control PDU.
However Wang, analogous art also teaching SDAP PDU transmissions does disclose:
A data transmission method, comprising:
receiving, by a terminal device, a second Service Data Adaptation Protocol (SDAP) Packet Data Unit (PDU) sent by a network device, the second SDAP PDU being a downlink SDAP data PDU, wherein the downlink SDAP data PDU in a first format comprises first information for indicating whether the second SDAP PDU is a data PDU or a control PDU. [(See Wang ¶32; ¶47-55; Fig.2 and 15)
[0032] Extended reality (XR) traffic from XR applications can have special traffic characteristics compared with traditional applications. For example, a set of data packets can carry the payload of one unit of information generated at the application level (e.g., a video frame or a video slice from an encoder of an XR service). The whole set of data packets is needed by the application layer (e.g., a decoder) to use the corresponding unit of information. (The unit of information can be referred to as an application data unit (ADU).) The ADU can be a data burst or a PDU set, where appropriate. Those interrelated data packets need to be identified and handled collectively when being transmitted through a wireless network. For another example, data packets carrying the payloads of different units of information (e.g., I-frame versus P-frame) may have different importance. Those different groups of data packets can be identified and treated differently during transmission. The existing radio access networks (RANs) (e.g., Long Term Evolution (LTE) RAN or New Radio (NR) RAN) are typically designed to be service-agnostic (or application-agnostic), which limits the support a RAN can provide for XR traffic.
[0047] During media stream coding in an encoder and packet assembly in the media streaming transport protocol layer (e.g., RTP layer), various packet information may be included within protocol headers to indicate attributes of the application data payload. By inspecting this information, a lower layer (e.g., IP, SDAP, PDCP, etc.) can be aware of attributes of application data carried in a particular data packet. The lower layer can accordingly apply packet-specific handling strategies.
[0048] Examples of the said information to express the attributes of a particular data packet can include: (1) the packet belongs to which media streaming picture slice; (2) the packet belongs to which application data unit (ADU); (3) the packet belongs to which encoding layer (e.g. base layer or enhanced layer for better quality viewing); (4) the packet belongs to which media streaming frame (or picture); (5) the packet belongs to which type of media streaming frame (e.g. I-frame or P-frame); (6) the packet belongs to critical data or non-critical data; (7) the packet delay budget for the packet; (8) priority of the packet; (9) the packet is new transmission or retransmission at media streaming transport protocol layer or application layer; (10) the packet is a redundant packet or a non-redundant transmission; (11) the packet is a control packet or a data streaming packet from media streaming transport protocol layer; (12) the reliability requirement of the packet; and (13) the packet belongs to which media traffic type (e.g. XR traffic).
]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the communication system of Kim with that of Wang to include plurality of PDUs in order to send a set of data packets for XR traffic, as per Wang (¶32), with reasonable expectation of success.
Regarding Claim 8, Kim and Wang disclose(s):
The method of claim 7, further comprising:
receiving, by the terminal device, first indication information sent by the network device, wherein the first indication information is used for indicating whether the first format or a second format is to be used by the terminal device as a format of the downlink SDAP data PDU; and (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
determining, by the terminal device, the format of the downlink SDAP data PDU based on the first indication information. (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
Regarding Claim 9, Kim and Wang disclose(s):
The method of claim 8, wherein the first indication information is configured per Qos flow, configured per DRB, configured per PDU session, or configured per User Equipment (UE).
[(see Kim ¶132; ¶321-326) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
[0321] Main functions of the NR SDAPs 2d-01 and 2d-45 may include some of the following functions. [0322] Transfer of user plane data [0323] Mapping between a QoS flow and a DRB for both DL and UL [0324] Marking QoS flow ID in both DL and UL packets [0325] Reflective QoS flow to DRB mapping for the UL SDAP PDUs.
[0326] For the SDAP layer device, the UE may receive setup on whether to use a header of the SDAP layer device or a function of the SDAP layer device for each PDCP layer device, for each bearer, or for each logical channel based on an RRC message, and when the SDAP header is set, the UE may instruct to update or reset a QoS flow of the uplink and downlink and mapping information on data bearer with NAS QoS reflection setup 1-bit indicator (NAS reflective QoS) and AS QoS reflection setup 1-bit indicator (AS reflective QoS) of the SDAP header. The SDAP header may include QoS flow ID information representing QoS. The QoS information may be used as a data processing priority, scheduling information, and the like to support a smooth service.
(See Wang ¶5; ¶34)
[0005] In an embodiment, the radio protocol layer is a service data adaption protocol (SDAP) layer in the RAN protocol stack. The SDU is an internet protocol (IP) packet. The processing includes mapping the IP packet to a data radio bearer (DRB) according to which one of the multiple classes the IP packet is classified into, wherein IP packets belonging to different classes are mapped to different DRBs.
[0034] In some embodiments, a service data adaption protocol (SDAP) layer is configured to inspect header information of upper protocol layers carried in internet protocol (IP) packets and accordingly classify IP packets into different classes, such as a critical IP packet class and a non-critical IP packet class. Based on the inspection and classification results, IP packets from a quality of service (QoS) flow can be mapped to different data radio bearers (DRBs). In some embodiments, SDAP protocol data units (PDUs) of different DRBs can be associated with discard timers having different time intervals.
Regarding Claim 10, Kim and Wang disclose(s):
The method of claim 7, further comprising:
if the terminal device reports first capability information to the network device, determining, by the terminal device and the network device, that the format of the downlink SDAP data PDU is the first format; and (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
if the terminal device does not report the first capability information to the network device, determining, by the terminal device and the network device, that the format of the downlink SDAP data PDU is the second format, (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
wherein the first capability information is used for indicating that the terminal device supports the downlink SDAP data PDU in the first format. (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
Regarding Claims 11, Kim and Wang disclose(s):
The method of claim 7, further comprising:
reporting, by the terminal device, second capability information to the network device;
if the second capability information indicates that the terminal device supports a first capability, determining, by the terminal device and the network device, that the format of the downlink SDAP data PDU is the first format; and (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
if the second capability information indicates that the terminal device does not support the first capability, determining, by the terminal device and the network device, that the format of the downlink SDAP data PDU is the second format, (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
wherein the first capability is a capability that the terminal device supports the downlink SDAP data PDU in the first format; or, the first capability is a capability that the terminal device supports a first protocol version. (See Kim ¶155-160; ¶166-170; ¶192; ¶321-325; ¶406-409; Fig. 1H-1K; 1R, 2E, 2i) (See Wang ¶5; ¶32-34; ¶47-72; ¶117-128; Fig.2, Fig. 5, and 15-16)
Regarding Claims 12, Kim disclose(s):
A data transmission device, comprising: a processor and a memory, wherein the memory is configured to store computer-executable instructions, and the processor is configured to invoke and execute the computer-executable instructions stored in the memory to perform an operation of: (See Kim ¶619; Fig. 2o)
receiving, by a Packet Data Convergence Protocol (PDCP) layer, a first Service Data Adaptation Protocol (SDAP) Packet Data Unit (PDU) sent by a SDAP layer, the first SDAP PDU being a downlink SDAP control PDU, wherein the downlink SDAP control PDU comprises at least one of following information: (See Kim ¶165-170; Fig. 1E, 1Q, and 1R)
first information for indicating whether the first SDAP PDU is a data PDU or a control PDU; (See Kim ¶165-170; ¶192-198 Fig. 1R and 2i)
second information for indicating a Quality of Service (Qos) flow Identifier (ID) associated with the first SDAP PDU; (See Kim ¶165-170; Fig. 1R and 2i)
third information for indicating a control PDU type to which the first SDAP PDU belongs; (See Kim ¶165-170; ¶403-405; Fig. 1R and 2i)
fifth information for indicating a QoS attribute of the PDU (See Kim ¶163-170; Fig. 1Q)
Kim does not explicitly disclose:
fourth information for indicating a frame type corresponding to a PDU set or a frame associated with the first SDAP PDU;
fifth information for indicating a Qos attribute of the PDU set, the frame or a PDU associated with the first SDAP PDU;
sixth information for indicating an ID of the PDU set or the frame associated with the first SDAP PDU;
seventh information for indicating an ID of a Group of Pictures (GOP) to which the PDU set or the frame associated with the first SDAP PDU belongs; or
eighth information for indicating IDs of at least part of PDUs in the PDU set associated with the first SDAP PDU.
However Wang, analogous art also teaching SDAP PDU transmissions does disclose:
fourth information for indicating a frame type corresponding to a PDU set or a frame associated with the first SDAP PDU; (See Wang ¶32; ¶47-48; Fig. 4)
fifth information for indicating a Qos attribute of the PDU set, the frame or a PDU associated with the first SDAP PDU; (See Wang ¶32; ¶47-55; Fig. 4)
sixth information for indicating an ID of the PDU set or the frame associated with the first SDAP PDU; (See Wang ¶32; ¶47-55; Fig. 4)
seventh information for indicating an ID of a Group of Pictures (GOP) to which the PDU set or the frame associated with the first SDAP PDU belongs; or (See Wang ¶32; ¶47-55; Fig. 4)
eighth information for indicating IDs of at least part of PDUs in the PDU set associated with the first SDAP PDU. (See Wang ¶32; ¶47-55; Fig. 4)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the communication system of Kim with that of Wang to include various packet information in order to be aware of attributes carried in particular data packets, as per Wang (¶47-48), with reasonable expectation of success.
Regarding Claims 18, Kim and Wang disclose(s):
A communication device comprising: a processor and a memory, wherein the memory is configured to store computer-executable instructions, and the processor is configured to invoke and execute the computer-executable instructions stored in the memory to perform the method of claim 7. (See Kim ¶619; Fig. 2o)
Regarding Claims 19, Kim and Wang disclose(s):
A non-transitory computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, causes a processor to perform the method of claim 1. (See Kim ¶619; Fig. 2o)
Regarding Claims 20, Kim and Wang disclose(s):
A non-transitory computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, causes a processor to perform the method of claim 7. (See Kim ¶619; Fig. 2o)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Rowan K Fakhro whose telephone number is (703)756-1467. The examiner can normally be reached Monday - Friday 8:00am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Marcus R Smith can be reached at (571) 270-1096. 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.
/RKF/Patent Examiner, Art Unit 2468
/MARCUS SMITH/Supervisory Patent Examiner, Art Unit 2468
Prosecution Insights