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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 11th, 2026 has been entered.
In this office action:
Claims 1, 3-6, 8-9, 11-14, 16-17, and 19-23 are pending.
Claims 1, 3-6, 8-9, 11-14, 16-17, and 19-23 are rejected.
Summary of Previous Office Action
In the Final Office Action mailed on December 17th, 2025:
Claims 1, 3-9, 11-17 and 19-23 were rejected under 35 U.S.C. 103 as being unpatentable over Przybysz et al. (Pub. No. US 2010/0316045), hereinafter Przybysz; in view of Soni (Pub. No. US 2016/0028636); and further in view of Deivasigamani et al. (Pub. No. US 2016/0353344), hereinafter Deivasigamani.
Response to Amendment
The amendments filed on March 11th, 2026 have been entered.
Claims 1, 6, 8-9, 14, 16-17, and 19-20 have been amended.
Claims 7 and 15 have been canceled.
Response to Arguments
In Applicant Arguments/Remarks (Pages 7-8), filed on March 11th, 2026, the Applicant argues that Przybysz doesn’t disclose "modifying, based on the determined first DSCP marking, the network request, the modification comprising inserting the first DSCP marking into the header of the network request," as amended.
In response, the Examiner respectfully disagrees.
Przybysz discloses modifying, based on the determined first DSCP marking, the network request, the modification comprising inserting the first DSCP marking into the header of the network request (See Parag. [0042]; The SIP message is classified at the P-CSCF to determine the relevant DSCP value for the IP packet in which the SIP message will be forwarded to the access network ... See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header).
Przybysz discloses that the SIP message sent from the MMTEL AS or the Presence AS to the S-CSCF is forwarded to the P-CSCF which classifies the SIP message to determine the relevant DSCP value for the IP packet; the P-CSCF analyses the message and content of the incoming SIP message from the S-CSCF and sets the correct DSCP; and the SIP message is classified by including an explicit indication in the SIP message, the MMTEL AS sets in the SIP message header an indication of high forwarding priority, while the Presence AS would set a low forwarding priority indication. The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header (See Przybysz Parag. [0042-0045]).
In addition, the claim language defines the modification as “inserting the first DSCP marking into the header of the network request” which is consistent with determining the DSCP value and including it in the IP packet header of the IP packet containing all or part of the SIP message, as taught by Przybysz.
Therefore, the Examiner has reasonably interpreted the modification performed on the IP packet by including the determined DSCP value in the header to be equivalent to the claimed limitation above.
Claim Rejections - 35 USC § 103
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 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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-6, 8-9, 11-14, 16-17 and 19-23 are rejected under 35 U.S.C. 103 as being unpatentable over Przybysz et al. (Pub. No. US 2010/0316045), hereinafter Przybysz; in view of Soni (Pub. No. US 2016/0028636); and further in view of Deivasigamani et al. (Pub. No. US 2016/0353344), hereinafter Deivasigamani.
Claim 1. Przybysz discloses [a] method comprising:
identifying a header of a network request, the header comprising priority information for the network request (See Parag. [0042]; A SIP message (a network request) sent from the MMTEL AS or the Presence AS to the S-CSCF is forwarded to the P-CSCF. The SIP message is classified at the P-CSCF … See Parag. [0044]; the SIP message is classified by including an explicit indication in the SIP message, the MMTEL AS sets in the SIP message header an indication of high forwarding priority, while the Presence AS would set a low forwarding priority indication (the header comprising priority information for the network request). See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). See also Parag. [0044-0045]);
determining, based on the priority information, a first Differentiated Services Code Point (DSCP) marking (See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority (priority information). See also Parag. [0043]);
modifying, based on the determined first DSCP marking, the network request, the modification comprising inserting the first DSCP marking into the header of the network request (See Parag. [0042]; The SIP message is classified at the P-CSCF to determine the relevant DSCP value for the IP packet in which the SIP message will be forwarded to the access network ... See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header);
communicating the network request to a destination identified within the header (See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header); and
receiving a response message comprising 3rd Generation Partnership Project (3GPP) information, the 3GPP information comprising a second DSCP marking with the value of the first DSCP marking (See Parag. [0033]; types of SIP message characteristic that may be analysed by the SIP classifier in order to accord a DSCP value to a SIP containing IP packet header include SIP response (typically the response will have the same DSCP value as the request it responds to). See Parag. [0041]; the invention applies to 3GPP IMS and access networks is illustrated schematically in FIG. 4. See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). Examiner’s interpretation: The Examiner reasonably interprets the SIP response in the 3GPP IMS and access networks to be equivalent to the claimed response message, where the SIP response includes a DSCP value (a second DSCP marking) with the values of the DSCP in the request (the first DSCP marking). In addition, the Examiner reasonably interprets the SIP response to be received by the classifier within the P-CSCF to be analyzed).
Przybysz doesn't explicitly disclose: opening, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking; [and] communicating the modified network request to a destination via the opened TCP socket.
However, Soni discloses:
opening, on a network, a transmission control protocol (TCP) socket (See Parag. [0055]; Server device 220 may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. See also Parag. [0029]; create a socket for receiving IP packets from client device 210… See also Parag. [0016]), the opened TCP socket being related to a value of the first DSCP marking (See Parag. [0055]; Server device 220 may determine the DSCP value of B is associated with the streaming video service and a TCP optimization module … Server device 220 may load the TCP optimization module and process the IP packet based on the TCP optimization module. See also claim 10; receive the packet via a transmission control protocol (TCP) socket; store the DSCP information in a memory associated with the TCP socket. See also Parag. [0040] [0042-0043]); [and]
communicating, via the opened TCP socket, the modified network request to a destination identified within the header (See Parag. [0054]; Based on the IP packet including the request to fetch video data, network device 240 may set the DSCP bits to indicate a value of B. See Parag. [0011]; The IP header may include DSCP bits. See Parag. [0055]; Server device 220 (destination) may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the method of allocating a priority to an Internet Protocol packet , taught by Przybysz, to opening, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking, and communicating the modified network request to a destination via the opened TCP socket, as taught by Soni. This would be convenient for a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing quality of service (QoS) on Internet Protocol (IP) networks (Soni, Parag. [0001]).
Przybysz in view of Soni disclose opening the TCP socket, but Przybysz in view of Soni doesn’t explicitly disclose opening the TCP socket is performed by the P-CSCF/network device.
However, Deivasigamani discloses a Proxy Call Session Control Function (P-CSCF) opening, on a network, a transmission control protocol (TCP) socket (See Parag. [0046]; the P-CSCF (i.e., Proxy Call Session Control Function) may open a TCP socket. See also Parag. [0038] [0040]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network device, taught by Przybysz in view of Soni, to open the TCP socket, as taught by Deivasigamani. This would be convenient to re-attempt to connect the VoLTE (Voice over LTE) call (Deivasigamani, Parag. [0046]).
Claim 3. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 1,
Przybysz further discloses wherein determining the first DSCP marking is performed by a network function on the network (See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). See also Parag. [0033]).
Claim 4. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 3,
Przybysz in view of Soni doesn’t explicitly disclose wherein opening the TCP socket is performed by the network function.
However, Deivasigamani discloses wherein opening the TCP socket is performed by the network function (See Parag. [0046]; the P-CSCF (i.e., Proxy Call Session Control Function) may open a TCP socket. See also Parag. [0038] [0040]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the opening of the TCP socket, taught by Przybysz in view of Soni, to be performed by the network function, as taught by Deivasigamani. This would be convenient to re-attempt to connect the VoLTE (Voice over LTE) call (Deivasigamani, Parag. [0046]).
Claim 5. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 3,
Przybysz in view of Soni doesn’t explicitly disclose wherein opening the TCP socket is performed by a proxy associated with the network function.
However, Deivasigamani discloses wherein opening the TCP socket is performed by a proxy associated with the network function (See Parag. [0046]; the P-CSCF (i.e., Proxy Call Session Control Function) may open a TCP socket. See also Parag. [0038] [0040]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the opening of the TCP socket, taught by Przybysz in view of Soni, to be performed by a proxy associated with the network function, as taught by Deivasigamani. This would be convenient to re-attempt to connect the VoLTE (Voice over LTE) call (Deivasigamani, Parag. [0046]).
Claim 6. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 1,
Przybysz doesn’t explicitly disclose wherein the destination corresponds to a server on the network, wherein the server receives the communicated modified network request via a socket that corresponds to the value of the first DSCP marking.
However, Soni discloses wherein the destination corresponds to a server on the network, wherein the server receives the communicated modified network request via a socket that corresponds to the value of the first DSCP marking (See Parag. [0055]; Server device 220 may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. Server device 220 may read the DSCP bits included in the IP packet through a socket option and determine the DSCP bits indicate a DSCP value of B. Server device 220 may determine the DSCP value of B is associated with the streaming video service and a TCP optimization module. See Parag. [0038]; A socket option may be used to retrieve information from the IP packet at the socket that received the IP packet in real time as the IP packet is received. For example, server device 220 may invoke a listener thread to accept new connections with client device 210 and to listen for IP packets received via the socket. The listener thread may read the DSCP bits through the socket option. See also Parag. [0040] [0042-0043]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the method of allocating a priority to an Internet Protocol packet, taught by Przybysz, to include wherein the destination corresponds to a server on the network, wherein the server receives the communicated modified network request via a socket that corresponds to the value of the first DSCP marking, as taught by Soni. This would be convenient for a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing quality of service (QoS) on Internet Protocol (IP) networks (Soni, Parag. [0001]).
Claim 8. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 1,
Przybysz doesn’t explicitly disclose determining a Quality of Service (QoS) mechanism for the modified network request based on the first DSCP marking; and applying the QoS mechanism to the modified network request, wherein the communicated modified network request is subject to the applied QoS mechanism.
However, Soni discloses determining a Quality of Service (QoS) mechanism for the modified network request based on the first DSCP marking; and applying the QoS mechanism to the modified network request, wherein the communicated modified network request is subject to the applied QoS mechanism (See Parag. [0031]; The IP header may be used to deliver the IP packet from client device 210 to server device 220 and may include a Differentiated Services filed (DS field) that includes DSCP bits. For instance, the first six bits of the DS field may include the DSCP bits and may indicate QoS properties for routing the IP packet via network 230; the DSCP bits may define the way network devices 240 should queue the IP packet while being forwarded or routed in network 230. See Parag. [0035]; network devices 240 may selectively prioritize routing of IP packets sent from client device 210 to server device 220 based on the DSCP bits (i.e., QoS properties for routing the IP packet via network 230) included in the IP packet).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the method of allocating a priority to an Internet Protocol packet, taught by Przybysz, to include determining a Quality of Service (QoS) mechanism for the modified network request based on the first DSCP marking; and applying the QoS mechanism to the modified network request, wherein the communicated modified network request is subject to the applied QoS mechanism, as taught by Soni. This would be convenient for a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing quality of service (QoS) on Internet Protocol (IP) networks (Soni, Parag. [0001]).
Claim 9. Przybysz discloses [a] network device comprising: a processor (See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). Examiner’s note: P-CSCF requires a processor (CPU) to function because it's a core network element in the IP Multimedia Subsystem (IMS)) configured to:
identify a header of a network request, the header comprising priority information for the network request (See Parag. [0042]; A SIP message (a network request) sent from the MMTEL AS or the Presence AS to the S-CSCF is forwarded to the P-CSCF. The SIP message is classified at the P-CSCF … See Parag. [0044]; the SIP message is classified by including an explicit indication in the SIP message, the MMTEL AS sets in the SIP message header an indication of high forwarding priority, while the Presence AS would set a low forwarding priority indication (the header comprising priority information for the network request). See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). See also Parag. [0044-0045]);
determine, based on the priority information, a first Differentiated Services Code Point (DSCP) marking (See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority (priority information). See also Parag. [0043]);
modify, based on the determined first DSCP marking, the network request, the modification comprising inserting the first DSCP marking into the header of the network request (See Parag. [0042]; The SIP message is classified at the P-CSCF to determine the relevant DSCP value for the IP packet in which the SIP message will be forwarded to the access network ... See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header);
communicate the modified network request to a destination identified within the header (See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header); and
receive a response message comprising 3rd Generation Partnership Project (3GPP) information, the 3GPP information comprising a second DSCP marking with the value of the first DSCP marking (See Parag. [0033]; types of SIP message characteristic that may be analysed by the SIP classifier in order to accord a DSCP value to a SIP containing IP packet header include SIP response (typically the response will have the same DSCP value as the request it responds to. See Parag. [0041]; the invention applies to 3GPP IMS and access networks is illustrated schematically in FIG. 4. See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). Examiner’s interpretation: The Examiner reasonably interprets the SIP response in the 3GPP IMS and access networks to be equivalent to the claimed response message, where the SIP response includes a DSCP value (a second DSCP marking) with the values of the DSCP in the request (the first DSCP marking). In addition, the Examiner reasonably interprets the SIP response to be received by the classifier within the P-CSCF to be analyzed).
Przybysz doesn't explicitly disclose: open, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking; [and] communicate the modified network request to a destination via the opened TCP socket.
However, Soni discloses:
open, on a network, a transmission control protocol (TCP) socket (See Parag. [0055]; Server device 220 may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. See also Parag. [0029]; create a socket for receiving IP packets from client device 210… See also Parag. [0016]), the opened TCP socket being related to a value of the first DSCP marking (See Parag. [0055]; Server device 220 may determine the DSCP value of B is associated with the streaming video service and a TCP optimization module … Server device 220 may load the TCP optimization module and process the IP packet based on the TCP optimization module. See also claim 10; receive the packet via a transmission control protocol (TCP) socket; store the DSCP information in a memory associated with the TCP socket. See also Parag. [0040] [0042-0043]); [and]
communicate, via the opened TCP socket, the modified network request to a destination identified within the header (See Parag. [0054]; Based on the IP packet including the request to fetch video data, network device 240 may set the DSCP bits to indicate a value of B. See Parag. [0011]; The IP header may include DSCP bits. See Parag. [0055]; Server device 220 (destination) may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the system of allocating a priority to an Internet Protocol packet, taught by Przybysz, to open, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking, and communicate the modified network request to a destination via the opened TCP socket, as taught by Soni. This would be convenient for a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing quality of service (QoS) on Internet Protocol (IP) networks (Soni, Parag. [0001]).
Przybysz in view of Soni disclose opening the TCP socket, but Przybysz in view of Soni doesn’t explicitly disclose opening the TCP socket is performed by the P-CSCF/network device.
However, Deivasigamani discloses a Proxy Call Session Control Function (P-CSCF) open, on a network, a transmission control protocol (TCP) socket (See Parag. [0046]; the P-CSCF (i.e., Proxy Call Session Control Function) may open a TCP socket. See also Parag. [0038] [0040]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network device, taught by Przybysz in view of Soni, to open the TCP socket, as taught by Deivasigamani. This would be convenient to re-attempt to connect the VoLTE (Voice over LTE) call (Deivasigamani, Parag. [0046]).
Claim 11 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 3.
Claim 12 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 4.
Claim 13 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 5.
Claim 14 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 6.
Claim 16 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 8.
Claim 17. Przybysz discloses [a] non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, that when executed by a network device (See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). Examiner’s note: P-CSCF requires a processor (CPU)/memory to function because it's a core network element in the IP Multimedia Subsystem (IMS)), perform a method comprising:
identifying a header of a network request, the header comprising priority information for the network request (See Parag. [0042]; A SIP message (a network request) sent from the MMTEL AS or the Presence AS to the S-CSCF is forwarded to the P-CSCF. The SIP message is classified at the P-CSCF … See Parag. [0044]; the SIP message is classified by including an explicit indication in the SIP message, the MMTEL AS sets in the SIP message header an indication of high forwarding priority, while the Presence AS would set a low forwarding priority indication (the header comprising priority information for the network request). See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). See also Parag. [0044-0045]);
determining, based on the priority information, a first Differentiated Services Code Point (DSCP) marking (See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority (priority information). See also Parag. [0043]);
modifying, based on the determined first DSCP marking, the network request, the modification comprising inserting the first DSCP marking into the header of the network request (See Parag. [0042]; The SIP message is classified at the P-CSCF to determine the relevant DSCP value for the IP packet in which the SIP message will be forwarded to the access network ... See Parag. [0044]; The SIP classifier maps the explicit indications to the correct DSCP values reflecting the requested forwarding priority. See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header);
communicating the modified network request to a destination identified within the header (See Parag. [0045]; The DSCP value is included in the IP packet header of the IP packet containing all or part of the SIP message. The IP packet is then forwarded across the network according to the DSCP value in its header. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header); and
receiving a response message comprising 3rd Generation Partnership Project (3GPP) information, the 3GPP information comprising a second DSCP marking with the value of the first DSCP marking (See Parag. [0033]; types of SIP message characteristic that may be analysed by the SIP classifier in order to accord a DSCP value to a SIP containing IP packet header include SIP response (typically the response will have the same DSCP value as the request it responds to. See Parag. [0041]; the invention applies to 3GPP IMS and access networks is illustrated schematically in FIG. 4. See Parag. [0040]; the SIP classifier is typically located at a Proxy Call Session Control Function (P-CSCF). Examiner’s interpretation: The Examiner reasonably interprets the SIP response in the 3GPP IMS and access networks to be equivalent to the claimed response message, where the SIP response includes a DSCP value (a second DSCP marking) with the values of the DSCP in the request (the first DSCP marking). In addition, the Examiner reasonably interprets the SIP response to be received by the classifier within the P-CSCF to be analyzed).
Przybysz doesn't explicitly disclose: opening, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking; [and] communicating the modified network request to a destination via the opened TCP socket.
However, Soni discloses:
opening, on a network, a transmission control protocol (TCP) socket (See Parag. [0055]; Server device 220 may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. See also Parag. [0029]; create a socket for receiving IP packets from client device 210… See also Parag. [0016]), the opened TCP socket being related to a value of the first DSCP marking (See Parag. [0055]; Server device 220 may determine the DSCP value of B is associated with the streaming video service and a TCP optimization module … Server device 220 may load the TCP optimization module and process the IP packet based on the TCP optimization module. See also claim 10; receive the packet via a transmission control protocol (TCP) socket; store the DSCP information in a memory associated with the TCP socket. See also Parag. [0040] [0042-0043]); [and]
communicating, via the opened TCP socket, the modified network request to a destination identified within the header (See Parag. [0054]; Based on the IP packet including the request to fetch video data, network device 240 may set the DSCP bits to indicate a value of B. See Parag. [0011]; The IP header may include DSCP bits. See Parag. [0055]; Server device 220 (destination) may receive the IP packet sent from client device 210, via network device 240, at a TCP socket. Examiner’s interpretation: An IP packet is interpreted to include the destination address in the header).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the system of allocating a priority to an Internet Protocol packet, taught by Przybysz, to opening, on a network, a transmission control protocol (TCP) socket, the opened TCP socket being related to a value of the first DSCP marking, and communicating the modified network request to a destination via the opened TCP socket, as taught by Soni. This would be convenient for a simple, scalable, and coarse-grained mechanism for classifying and managing network traffic and providing quality of service (QoS) on Internet Protocol (IP) networks (Soni, Parag. [0001]).
Przybysz in view of Soni disclose opening the TCP socket, but Przybysz in view of Soni doesn’t explicitly discloses opening the TCP socket is performed by the P-CSCF/network device.
However, Deivasigamani discloses a Proxy Call Session Control Function (P-CSCF) opening, on a network, a transmission control protocol (TCP) socket (See Parag. [0046]; the P-CSCF (i.e., Proxy Call Session Control Function) may open a TCP socket. See also Parag. [0038] [0040]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network device, taught by Przybysz in view of Soni, to open the TCP socket, as taught by Deivasigamani. This would be convenient to re-attempt to connect the VoLTE (Voice over LTE) call (Deivasigamani, Parag. [0046]).
Claim 19 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 6.
Claim 20 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 8.
Claim 21. Przybysz in view of Soni and Deivasigamani discloses [t]he method of claim 1,
Przybysz further discloses wherein the 3GPP information comprises a 3GPP priority header of the response message, wherein the second DSCP marking is within the 3GPP priority header of the response message (See Parag. [0002]; A Differentiated Services Code Point (DSCP) value is included in the header of the IP packet, which accords a priority to the IP packet ... See Parag. [0033]; types of SIP message characteristic that may be analysed by the SIP classifier in order to accord a DSCP value to a SIP containing IP packet header include SIP response (typically the response will have the same DSCP value as the request it responds to). See Parag. [0039]; The SIP classifier analyses the explicit indication and maps the indication directly to an applicable DSCP value for inclusion in the SIP containing IP packet header. This requires an extension of RFC 4412 "Communications Resource Priority for the Session Initiation Protocol" that defines new resource priority syntax and semantics to request specific IP packet forwarding priority in the Resource-Priority SIP header. See Parag. [0041]; the invention applies to 3GPP IMS and access networks is illustrated schematically in FIG. 4. See also Parag. [0040] [0045]).
Claim 22 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 21.
Claim 23 is taught by Przybysz in view of Soni and Deivasigamani as described for claim 21.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Asthana et al. (Pub. No. US 2007/0091900) – Related art in the area of prioritizing TCP control packet traffic, (Abstract; A method is provided for transmitting data, wherein control packets are given priority with respect to application data packets. In general, this is accomplished by establishing a separate, distinct link flow over which only control packets (e.g., TCP control packets) will be transmitted. A higher priority is associated with this link flow. In addition, the reliability of control packets sent over the dedicated link flow can be improved upon by increasing the number of retransmissions associated with the control packets and/or decreasing the window of time before the retransmissions are sent. A system, mobile terminal, network entity, and computer program product for implementing the method are also provided.).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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 on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Examiner, Art Unit 2445
Prosecution Insights