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 .
Examiner finds no 35 USC 101 rejections in the current claim language.
Examiner finds no credible double patenting rejections in the current claim language.
Claim Objections
Claims 11 – 20 are objected to because of the following informalities:
Claim 11 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 12 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 13 recites the limitation "The device" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “The method for a device”;
Claim 13 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 14 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 15 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 16 recites the limitation "the method" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 17 recites the limitation "the method" in line 1 (both instances). There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 18 recites the limitation "the method" in line 1 (both instances). There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 19 recites the limitation "the method" in line 1 (both instances). There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Claim 20 recites the limitation "the method" in line 1 (both instances). There is insufficient antecedent basis for this limitation in the claim.
Examiner recommends the language “the method for a device”;
Examiner recommends a thorough review of the claim language in order to correct possible antecedent basis concerns.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pulicherla et al. (U.S. Pat. Pub. No. 2014/0092783) (System and Method for Classification of Media in VOIP Sessions with RTP Source Profiling/Tagging).
1. A device comprising a processor configured to at least:
receive (Fig. 3, item 302; paragraph 44) a first stream identifier (ID) associated with a first packet data unit (PDU) set (RTP packet), wherein the first stream ID is received in a PDU set marking header extension (HE) (Fig. 2; Abstract “identifying an identification of an RTP data stream; inserting the identification of the RTP data stream into an RTP header extension; and transmitting, by use of a network interface, an RTP packet comprising the RTP header extension”; paragraphs 8, 9; paragraph 45 “… insert a ClassIdentifier, Name and/or Priority tag into an RTP header extension …”);
determine, from the PDU set marking HE, that the first stream ID is associated with a first media stream (Fig. 3, steps 304, 306, 312; paragraph 51; paragraph 52 “At step 304, the incoming RTP packet is examined to determine whether it includes a known RTP header extension in accordance with an embodiment of the present invention”; paragraph 56 “At step 312, the RTP packet is processed, including the effect of any play settings if an RTP header extension was detected and interpreted. Control of method 300 then passes to step 314”); and
send at least the first stream ID identifying the first media stream and the first PDU set associated with the first stream ID (Fig. 2, items 206, 208; Abstract “identifying an identification of an RTP data stream; inserting the identification of the RTP data stream into an RTP header extension; and transmitting, by use of a network interface, an RTP packet comprising the RTP header extension”; paragraph 8; paragraph 9; paragraph 49 “the RTP is transmitted, withe with or without a defined RTP header extension …”).
Regarding claim 11, the rejection of claim 1 under 35 USC 102 (see above) applies fully.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Liao (U.S. Pat. Pub. No. 2025/0274809) in view of Pulicherla et al. (U.S. Pat. Pub. No. 2014/0092783).
1. A device comprising a processor configured to at least:
receive a first stream identifier (ID) associated with a first packet data unit (PDU) set (Fig. 16, item 1602; paragraph 149 “At block 1602, the SMF can receive PDU Set related QoS Parameters …”), wherein the first stream ID is received in a PDU set marking header extension (HE) (paragraph 40 “In some implementations, network nodes can characterize each Sub-QoS flow by PDU Set type, PDU Set Importance level, or both, based on the UPF-detected information from a higher layer of the packet header. For example, for an RTP/SRTP-based media stream, the characterization can be based on bits included in the existing RTP/SRTP extension header or a new extension header; for a slice-based media stream, the characterization can be based on NAL bits in network abstraction layer header…”; paragraph 52 “When the UPF 370 operates as a PDU Session Anchor (PSA) UPF, to support PDU Set based QoS handling for XRM services, the PSA UPF 370 identifies PDUs that belong to PDU Sets and determines the following PDU Set Information, based for example on the RTP extension header defined in 3GPP TS26.522, which the PSA UPF 370 transmits to the NG-RAN 105 in the GTP-U header”);
determine, from the PDU set marking HE, that the first stream ID is associated with a first media stream (Abstract; paragraphs 40, 52); and
send at least the first stream ID identifying the first media stream and the first PDU set associated with the first stream ID (Fig. 16, item 1606; Abstract “… transmits the QoS profile to a radio access network (RAN) via which the UE accesses the CN (1606)”; paragraph 16 “generating a QoS profile associated with a QoS flow identifier (QFI) of the QoS flow for the media type; and transmitting the QoS profile to a radio access network (RAN) via which the UE accesses the CN”; paragraph 149; paragraph 52).
However, Liao does not explicitly disclose that the ID is received (inserted) in a header extension as seen in independent claim 1 (and independent claim 11).
Liao does disclose that the ID is included in a header extension (paragraph 40 “For example, for an RTP/SRTP-based media stream, the characterization can be based on bits included in the existing RTP/SRTP extension header or a new extension header”).
In the same field of invention (wireless communications supporting traffic organized into PDU sets), Pulicherla discloses that the first stream ID is received (inserted) in a PDU set marking header extension (HE) (Fig. 2; Abstract “identifying an identification of an RTP data stream; inserting the identification of the RTP data stream into an RTP header extension; and transmitting, by use of a network interface, an RTP packet comprising the RTP header extension”; paragraphs 8, 9; paragraph 45 “… insert a ClassIdentifier, Name and/or Priority tag into an RTP header extension …”).
It would have been obvious to one of ordinary skill in the art at the time of filing to implement the ID inserted in the header extension of Pulicherla into the invention of Liao in order to properly and efficiently implement the invention of Liao.
2. The device of claim 1, wherein the first stream ID identifying the first media stream and the first PDU set associated with the first stream ID are sent to one or more of a user plane function (UPF), radio access network (RAN) node, or a media client (Fig. 16, item 1606; Abstract “… transmits the QoS profile to a radio access network (RAN) via which the UE accesses the CN (1606)”; paragraph 149).
3. The device of claim 1, wherein the processor is configured to generate the first stream ID, wherein the first stream ID is generated as part of one or more of a real time protocol (RTP) session negotiation or a provisioning session (paragraph 119 “In another implementation, the UPF 370 uses the PDU Set Configuration, which the SMF 366 from SMF as discussed below with reference to FIG. 12. For example, for I/P/B frames, the PDU Set Importance level, the PDU Set type, or both can depend on the PDU Set Configuration which defines specific bits in RTP/SRTP extension header or a special-purpose (new) extension RTP header”; Fig. 7; paragraph 65 “Referring to FIG. 7, a reference QoS model 700 illustrates example QoS provisioning between a UE such as the UE 102 and a PSA UPF such as the UPF 370”).
4. The device of claim 1, wherein the first stream ID is received by a user plane function (UPF) from an application server (AS) or an application function (AF) (Fig. 8; items 370, 390; paragraphs 84, 85, 77).
5. The device of claim 1, wherein the first stream ID is received on a control plane (Fig. 2; paragraph 49).
6. The device of claim 1, wherein the first media stream associated with the first stream ID is multiplexed into a single QoS flow (paragraph 61 “… multiplex different QoS flows with different PDU Set QoS requirements …”; paragraph 59 “These models correspond to different combinations of one-to-one mapping and multiplexing/demultiplexing between PDU Sets, QoS flows, and DRBs”).
7. The device of claim 1, wherein the processor is configured to send an indication indicating that the first media stream is split into two or more quality of service (QOS) flows (Fig. 7; paragraph 59 “These models correspond to different combinations of one-to-one mapping and multiplexing/demultiplexing between PDU Sets, QoS flows, and DRBs”; paragraph 68).
8. The device of claim 1, wherein the processor is configured to:
receive a second stream ID associated with a second PDU set (paragraph 93 “the N2 message which the SMF 366 transmits to the RAN 105 can include a PDU Set based QoS profile. The RAN 105 can perform PDU Set based scheduling for DRBs based on one or more QoS profiles associated with multiple QFIs and PS-QoS parameters”);
determine that the second stream ID is associated with a second media stream (Abstract; paragraphs 40, 52; paragraph 93 “multiple QFIs”); and
send the second stream ID identifying the second media stream and the second PDU set associated with the second stream ID (Fig. 16, item 1606; Abstract “… transmits the QoS profile to a radio access network (RAN) via which the UE accesses the CN (1606)”; paragraph 16; paragraph 93).
9. The device of claim 1, wherein the processor is configured to send an indication indicating that the first media stream is multiplexed with a second media stream, wherein the first media stream and the second media stream are multiplexed into a quality of service (QOS) flow (Fig. 7; paragraph 59 “These models correspond to different combinations of one-to-one mapping and multiplexing/demultiplexing between PDU Sets, QoS flows, and DRBs”; paragraph 68).
10. The device of claim 1, wherein the processor is configured to send a list of stream IDs multiplexed with the first media stream (paragraph 99 “The QoS profiles can include an aggregated QoS profile per media stream identified by a QoS flow correlation ID, which in turn includes a QoS flow Correlation ID, aggregated QoS parameters, a PDU Session ID, and an optional list of QFIs that associated with the QoS flow correlation ID”).
Regarding claims 11 – 20, the rejection of claims 1 – 10 under 35 USC 103 (see above) applies fully.
For future email communications (including interview agendas), Applicant should file the appropriate PTO form (PTO/SB/439) or file an air interview request.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH R COULTER whose telephone number is (571)272-3879. The examiner can normally be reached M-F, 9am-5pm (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, Oscar Louie can be reached at M-H, 7:30am-2:30pm (EST). 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.
/KENNETH R COULTER/Primary Examiner, Art Unit 2445
/KRC/