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 IDS filed March 31, 2025 has been considered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim independent claims 1 and 12, the claims recite “wherein the QUIC header is located after or inside the IPv6 extension header.” It is unclear as to what in intended by inside.
Dependent claims do not further recite additional support that clarifies what is intended by inside as claimed, therefore are also rejected.
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.
Claim(s) 1, 4, 8-12, 15, and 19-22 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sarker et al. (WO 2021009553, hereinafter referred to as “Sarker”).
Regarding claim 1, Sarker teaches a packet transmission method, comprising:
generating a Quick User Datagram Protocol Internet Connection (QUIC) packet ([0031] Notably, encryption in QUIC covers both the transport protocol headers as well as the payload, as opposed to TLS over TCP (e.g., HTTPS), which protects only the payload.) comprising an Internet Protocol version 6 (IPv6) extension header ([0042] an UDP option or an IPv6 Destination Header Extension) from the client to the server) and a QUIC header ([0031] Notably, encryption in QUIC covers both the transport protocol headers as well as the payload, as opposed to TLS over TCP (e.g., HTTPS), which protects only the payload.), wherein the QUIC header is located after or inside the IPV6 extension header ([0073] At reference 504, the network device inserts discovery information into a second packet within the IP packet, where the discovery information includes a set of features supported by the network device. The second packet may be included as a part of the UDP payload, a UDP option, or IPv6 Header Extension as explained herein. The network device first detects whether a second packet for discovery information exists in the received IP packet; and if it does, the network device may insert the discovery information when the frame size allows such insertion. If no such packet exists, the network device creates the second packet, inserts the discovery information in this second packet, and inserts it in the same UDP datagram as the QUIC initial packet, otherwise it may be inserted in a subsequent QUIC packet, or in the protected data field using UDP options and/or IPv6 Destination Header Extension within a UDP datagram. In one embodiment, the network device encrypts the discovery information. In one embodiment, the discovery information includes identity of the network device. In one embodiment, the identity of the network device includes one or more of its global identifier or common name, its node certificate, and its IP address.); and
sending the QUIC packet ([0042] he server may then send the inserted discovery information to the client when it recognizes the COPE packet, or it may discard the COPE packet when it does not recognize the COPE packet or determine not to allow the COPE functions. Independently of how the COPE packet is included in the IP packet (e.g., in an UDP payload, as an UDP option or an IPv6 Destination Header Extension) from the client to the server, the inserted information by the COPE node can be sent as a QUIC frame in the return path from the server to the client.).
Regarding claim 4, Sarker teaches the packet transmission method of claim 1, wherein the IPV6 extension header comprises an option field, wherein the option field comprises an option type field and an option data field, wherein a value of the option type field indicates the QUIC header, and wherein the option data field comprises the QUIC header ([0054] Thus, in some embodiments, a COPE packet may be transported to a COPE node (1) with a QUIC packet, (2) using UDP options, or (3) using IPv6 Destination Header Extension).
Regarding claim 8, Sarker teaches the packet transmission method of claim 1, wherein the generating comprises: receiving an IPV6 packet, wherein the IPV6 packet comprises the IPV6 extension header; and adding the QUIC header to the IPV6 packet to obtain the QUIC packet, and wherein the sending comprises sending the QUIC packet through the QUIC connection ([0041] In one embodiment, a client adds the COPE packet in the same UDP payload as the QUIC initial packet with the Crypto frame containing the TLS client hello, where the UDP datagram containing the QUIC initial packet and the COPE packet may be referred to as the initial UDP datagram. The COPE packet may also be added in a UDP datagram after the initial UDP datagram (e.g., the UDP datagram may contain the same 5-tuple as the initial UDP datagram) in an alternative embodiment. In one embodiment, the COPE packet may be added as an UDP Option or as an IPv6 Destination Header Extension in the IPv6 extension header chain in the initial UDP or a subsequent UDP datagram.).
Regarding claim 9, Sarker teaches the packet transmission method of claim 1, wherein the generating comprises: receiving a data packet from a user equipment; and adding the IPV6 extension header and the QUIC header to the data packet to obtain the QUIC packet so that a payload field of the QUIC packet comprises the data packet ([0030] QUIC is a general-purpose transport layer network protocol. While it may be referred to as the acronym for Quick User Datagram Protocol (UDP) Internet Connections, some organizations (e.g., Internet Engineering Task Force, IETF) refer to QUIC as the name of the protocol without treating it as an acronym. QUIC may be viewed as similar to Transmission Control Protocol (TCP) + enhancement such as Transport Layer Security (TLS) and/or Hypertext Transfer Protocol 2.0 (HTTP/2 or HTTP/2.0) but implemented on top of UDP. QUIC is therefore a UDP based stream-multiplexed and secure transport protocol with integrity protected header and encrypted payload. Yet unlike the traditional transport protocol stack with TCP (Transmission Control Protocol), which resides in the operating system kernel, QUIC can easily be implemented in the application layer.).
Regarding claim 10, Sarker teaches the packet transmission method of claim 1, wherein the generating comprises: generating service data; generating the QUIC packet based on the service data so that a payload field of the QUIC packet comprises the service data ([0030] QUIC is a general-purpose transport layer network protocol. While it may be referred to as the acronym for Quick User Datagram Protocol (UDP) Internet Connections, some organizations (e.g., Internet Engineering Task Force, IETF) refer to QUIC as the name of the protocol without treating it as an acronym. QUIC may be viewed as similar to Transmission Control Protocol (TCP) + enhancement such as Transport Layer Security (TLS) and/or Hypertext Transfer Protocol 2.0 (HTTP/2 or HTTP/2.0) but implemented on top of UDP. QUIC is therefore a UDP based stream-multiplexed and secure transport protocol with integrity protected header and encrypted payload. Yet unlike the traditional transport protocol stack with TCP (Transmission Control Protocol), which resides in the operating system kernel, QUIC can easily be implemented in the application layer.).
Regarding claim 11, Sarker teaches the packet transmission method of claim 1, wherein the QUIC packet does not comprise a User Datagram Protocol (UDP) header ([0030] QUIC is a general-purpose transport layer network protocol. While it may be referred to as the acronym for Quick User Datagram Protocol (UDP) Internet Connections, some organizations (e.g., Internet Engineering Task Force, IETF) refer to QUIC as the name of the protocol without treating it as an acronym.).
Claims 12, 15, 19-22 are similar to claims 1, 4, and 8-11, respectively, therefore are rejected under the same rationale.
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 (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 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.
Claim(s) 5-6 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sarker in view of Van de Velde et al., (US 20210352009, hereinafter referred to as “Van de Velde”).
Regarding claim 5, Sarker does not teach the packet transmission method of claim 4, wherein the IPV6 extension header comprises a destination options header (DOH), a segment routing header (SRH), or a hop-by-hop options header (HBH). Van de Velde teaches wherein the IPV6 extension header comprises a destination options header (DOH), a segment routing header (SRH), or a hop-by-hop options header (HBH) ([0084] an IPv6 SR header (SRH) can be used to attach a SID stack and cause the packet to be forwarded accordingly by the IPv6 nodes.). Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to enable the IPV6 extension header to includes one of DOH, SRH, or HBH in order to provide additional control information and services beyond the fixed IPV6 header, thus making the protocol more flexible.
Regarding claim 6, Sarker does not teach the packet transmission method of claim 1, wherein the IPV6 extension header comprises a first segment identifier (SID) and a second SID, wherein the first SID identifies a start point device of a first QUIC connection, wherein the second SID identifies an end point device of the first QUIC connection, and wherein the first QUIC connection is for transmitting the QUIC packet ([0144] Next, logic circuit 520 operates to look up the obtained RSID in RSID table 550.
[0145] If the RSID corresponding to packet 502 is not found in RSID table 550, then logic circuit 520 concludes that packet 502 is the first-to-arrive packet of the corresponding set S (also see FIG. 4) and proceeds to generate an appropriate control signal 522 that configures FCC 530 to generate the egress packet 504 corresponding to this packet 502, e.g., as further described below. Logic circuit 520 also operates to: (i) save the RSID corresponding to this packet 502, with the corresponding time stamp, in RSID table 550; (ii) start an expiration timer associated with the saved RSID; and (iii) start a packet counter configured to count the number of received packets from the corresponding packet set S, i.e., the packets associated with the same RSID. The expiration timer is configured to run from a fixed selected value down to zero, at which point the saved RSID is deleted from RSID table 550. The packet counter is configured to count the number of received packets from the corresponding packet set S by incrementing the count value by one each time a new packet with the same RSID is detected by logic circuit 520 in buffer 510. When the count value reaches N, the saved RSID is deleted from RSID table 550. The RSID deletion from RSID table 550, through either mechanism (i.e., based on the expiration timer or packet counter), helps to minimize or avoid possible RSID collisions in RSID table 550 for different packet sets S. The latter may help to keep the effective full RSID values relatively short and the corresponding replication/combination overhead as small as practically possible (also see the description of method 300, FIG. 3, for embodiments directed at adaptively changing the length of the RSID value).).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to enable the IPV6 extension header to comprise SID because SIDs are used to steer traffic through network, thus allowing them to be programmed directly into the packet header.
Claims 17-18 are similar to claims 5-6, respectively, therefore are rejected under the same rationale.
Allowable Subject Matter
Claims 2-3, 7,13-14, and 16 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Regarding claim 2, the prior art of record does not teach the packet transmission method of claim 1, wherein the QUIC header is a next header after the IPV6 extension header, and wherein a value of a next header field in the IPV6 extension header indicates the QUIC header.
Claim 3 depends on claim 2, therefore is objected to for its dependency.
Regarding claim 7, the prior art of record does not teach the packet transmission method of claim 6, wherein a first value of a function field in the first SID indicates sending the QUIC packet through the first QUIC connection, wherein a second value of an arguments field in the first SID indicates adding the QUIC header, wherein a third value of a function field in the second SID indicates receiving the QUIC packet through the first QUIC connection, and wherein a fourth value of an arguments field in the second SID indicates removing the QUIC header.
Claims 13-14 and 16 are similar to claims 2-3 and 7, therefore are objected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
BELKAR et al., WO 2021209132 - the UDP header of the outgoing packet comprises an indication that indicates that the QUIC payload of the outgoing packet comprises one or more RDMA transactions.
Deen, US 20230254342 - QUIC provides a feature not found in UDP or TCP transports.
GANDHI et al., US 20220286395 - Segment Routing Internet Protocol Version 6 (SRv6) micro segments (“uSIDs”) are included in destination addresses, and possibly in other Segment Identifiers (“SIDs”), of packets transported through a network, and invoking corresponding network behavior, including, but not limited to, realization of corresponding network slices.
DUTTA, US 20220191139 - GRE header is a network virtualization using GRE (NVGRE) header that allows multiple NVGRE overlays to be multiplexed onto a single IP underlay tunnel. The reliable transport layer can be implemented as Transmission Control Protocol (TCP) layer, a QUIC protocol, a Stream Control Transmission Protocol (SCTP) or a QUIC protocol to establish a set of multiplexed sub-connections or streams over a single connection between two endpoints of the tunnel, or a transport layer security (TLS) cryptographic protocol.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights