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 .
Claim Objections
Claims 1 and 6 are objected to because acronym QUIC is not defined at least once in the claims.
Claims 1 and 6 are objected to because expression “popping up, in chronological order in which to-be-sent data is placed into the to-be-sent queues for the QUIC data streams, the to-be-sent data one by one from a to-be-sent queue for each of QUIC data streams that contains the to-be-sent data” requires better sentencing to give easier understanding of the limitation.
Claims 4, 5 and 9 are objected to because claims as written in long paragraphs makes it difficult to easily understand the claims. A simpler recitation by segmenting the large limitations is advised.
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 3-5 and 8-9 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.
Claims 3 and 8 recite expressions “data stream queuing queue” and “queues for the QUIC data streams” lacks clarity. It is not understood if they are the same queues or different queues.
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.
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, 3, 6 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Reisbick; Richard US 20210329062 A1, hereinafter Reisbick, in view of Kwan; Bruce et al US 12231342 B1, hereinafter Kwan, and further in view of XU, SHAN et al CN 111064792 A, hereinafter XU.
Regarding claims 1 and 6, Reisbick teaches, a data transmission method for Internet of Things devices, wherein a machine type communication gateway collects information of all of Internet of Things devices connected to the machine type communication gateway, allocates one (The claim is understood, under BRI (Broadest Reasonable Interpretation), to be a method of collecting IoT (Internet of Things) data or packet from various IoT devices in an aggregator and sending the aggregated data to a network entity. An aggregator can be a Gateway, Multiplexor, Concentrator, Router etc. Data or packet can be in various format such as QUIC stream. Network entity can be server, central Core or Radio or Network Access Node. Such method is well-known in the art. Reisbick Fig. 1; [7] “a method is provided for multi-tenant Internet-of-Things (IoT) gateway routing. The method includes: receiving, by an IoT gateway routing system, a plurality of input device data streams from a plurality of IoT devices via an IoT network;”, [27] “In other embodiments, multiple input device data streams 113 can be used to generate a single output device data stream 133 … In other embodiments, the generating can involve any suitable modification of the data streams to prepare for communicating the output device data streams 133 for communication.”. IoT data packets are known to comprise short or small data.), the method comprises:
Step 1. by the machine type communication gateway, reading the short data packets sent by all of the Internet of Things devices, acquiring see explanation above and further in para [6] “ transmit output device data streams to the cloud network, each output device data stream generated from at least a respective input device data stream of the input device data streams”, [27] “In other embodiments, multiple input device data streams 113 can be used to generate a single output device data stream 133);
Step 2. by the machine type communication gateway, newly creating an empty data packet; popping up, in chronological order in which to-be-sent data is placed (This limitation.is about mapping multiple input data streams to an output data stream by the gateway in order to be transmitted over a transmission frame. Para [6]-[7] discloses mapping of multiple input data streams to an output data stream, and sent via an associated communication technology at the output, thus, implying applying a transmission frame (=streamframe). “A central base station” is interpreted, in the context of the claim, as an entity such as a server or a device intended to receive the aggregated packet. Fig. 1; Para [27] “As described herein, some implementations of the router 125 can then transmit the output device data streams 133 over the cloud network 115 to one or more remote servers 117.”. It is inherent that incoming data from IoT devices is processed as they arrive, therefore, processed in chronological order).
While it is implied in Reisbick the use of “queues” or buffers or cache in the gateway for input and output data stream processing, following the Reisbick’s teachings of modifying and mapping the data from the input to the output (see e.g., [27] “In other embodiments, the generating can involve any suitable modification of the data streams to prepare for communicating the output device data streams 133 for communication.”), however, in the same field of endeavor, Kwan expressly teaches using “queues” in the gateway for input and output data stream processing as recited in the claim “constructs one to-be-sent queue for each queues for the acquired “into the to-be-sent queues for the “from a to-be-sent queue” (Kwan col.1, l.18-24 “A computer network is a set of computing components … Each computing component may be a separate computing device, such as, without limitation, a hub, a switch, a bridge, a router, a server, a gateway, … Each computing component, or “network device,” is considered to be a node within the network”; col.25, l.39-45 “At block 708, data units received at block 704 are stored in a plurality of ingress queues corresponding to the plurality of ingress buffer memories while the data units are processed by the plurality of ingress packet processors. For example, data units are stored in the plurality of ingress queues 228 while the data units are processed by the plurality of ingress packet processors 232.”, l.51-67 “For example, the ingress arbitration circuitry 220 transfers data units from the plurality of ingress queues 228 to the plurality of egress queues 256. … At block 716, data units transferred at block 712 are stored in a plurality of egress queues while the data units are processed by the plurality of egress processors, the plurality of egress queues corresponding to the plurality of egress buffer memories.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Reisbick to include the features as taught by Kwan above in order to provide a method for enhanced buffering and congestion control of data units within a network device (Kwan “Abstract”, col.1, l.5-7).
Reisbick and Kwan do not expressly teach, however, in the same field of endeavor, XU teaches, “Internet of Things devices” using “QUIC data stream” to send data as recited in the instant claim (XU page 2 “A method of accelerating sensor device data acquisition based on QUIC protocol, the method comprises the following steps: S1: building client (numerical control lOT device supporting the QUIC protocol); … S4: establishing QUIC protocol; S5: the numerical control lOT device adopting the QUIC protocol to send data information to the server end”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Reisbick and Kwan to include the features as taught by XU above in order to provide a method of accelerating sensor device data acquisition based on QUIC protocol, which can overcome long transmission time, low transmission quality, high packet loss rate in the existing technology (XU page 2).
With respect to claim 6, claim recites the identical features of claim 1 for a corresponding data transmission system. Therefore, it is subjected to the same rejection.
Regarding claims 3 and 8, Reisbick, in view of Kwan and XU, teaches the method/system, as outlined in the rejection of claims 1 and 6.
Reisbick and Kwan and XU further teaches, wherein the machine type communication gateway further constructs one data stream queuing queue, which is configured to save QUIC data streams whose to-be-sent queues contain the to-be-sent data, and queue the QUIC data streams in chronological order in which the to-be-sent data is received in the to-be-sent queues for the QUIC data streams; Step 1 further comprises: adding the acquired QUIC data streams into the data stream queuing queue, Step 2 further comprises: newly creating an empty data packet; popping up the to-be-sent data one by one from a to-be-sent queue for each queued QUIC data stream according to a queuing sequence of the QUIC data streams in the data stream queuing queue; encapsulating the popped-up to-be-sent data into one streamframe and then loading the streamframe into the newly created data packet; popping up the QUIC data stream from the data stream queuing queue; and finally sending the data packet loaded with multiple streamframes to the central base station (The claim is understood as queuing the QUIC data streams and transfer the input queued data to the output queue according to a queuing sequence of the QUIC data streams. See the rejection of claims 1 and 6 above. As explained, Kwan teaches queue processing of input and output data, Reisbick inherently teaches that incoming data from IoT devices is processed as they arrive, therefore, processed in sequence, and XU teaches IoT data is QUIC data stream).
Claims 2 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Reisbick in view of Kwan and XU, as outlined in the rejection of claims 1 and 6 above, and further in view of LIANG QIANDENG et al WO 2022179468 A1, hereinafter LIANG.
Regarding claims 2 and 7, Reisbick, in view of Kwan and XU, teaches the method/system, as outlined in the rejection of claims 1 and 6.
Reisbick and Kwan and XU do not expressly teach, however, in the same field of endeavor, LIANG teaches, wherein when the central base station receives the data packet sent by the machine type communication gateway, the method further comprises: by the central base station, disassembling the data packet sent by the machine type communication gateway into multiple streamframes, and reading a Stream ID in header information of each of the streamframes to acquire a corresponding QUIC data stream; then placing valid data read from the streamframe into a buffer area of an Internet of Things device corresponding to the QUIC data stream according to a corresponding relationship between the Internet of Things devices and the QUIC data streams, to wait for being read by an application program, wherein the valid data is referred to data that does not contain the header information in the streamframe of the data packet (The claim is about disassembling or decoding the received aggregated QUIC frame in the receiving side. It is implied in Reisbick. However, LIANG expressly teaches, disassembling the received aggregated QUIC frame as recited in the instant claim.
LIANG [128] “The plurality of QUIC frames may be combined into one QUIC packet. Taking the Stream frame as an example, the plurality of Stream frames may be combined into one QUIC packet”, [131] “The Stream ID field may be used to identify a Stream frame;”, teaches Stream ID in the QUIC frame to identify the stream;
LIANG [145] “The client may transmit the data of the multiple QUIC streams to the server on one connection or unidirectional flow, so as to implement multiplexing in the transport layer.”, [195] “the data processing method provided in this application provides a plurality of packet sending queues for a connection or a unidirectional flow, and the packet sending module may read the QUIC frames from the packet sending queue for combining.”, [117] “As shown in FIG. 2, the client may be a mobile terminal, such as a mobile phone. The mobile phone communicates with the server through the base station …”, teaches a client combines multiple QUIC frames, acting like an aggregator gateway;
LIANG [336] “S1708: receiving and decapsulating a network packet, …”, [337] “After receiving the network packet based on the connection or unidirectional flow established with the client, the server decapsulates the network packet to obtain … the QUIC frame in the network packet. The server may write the QUIC frame into the packet collection queue corresponding to the QUIC frame priority based on the priority of the QUIC frame; or the server may write the priority of the QUIC frame into the description of the QUIC frame in the server cache region.”, teaching server disassembling the aggregated QUIC data stream and placing in a queue or cache region (=buffer)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Reisbick and Kwan and XU to include the features as taught by LIANG above in order to provide a data processing method to minimize the network bandwidth for sending the QUIC packet (LIANG [0005]).
Allowable Subject Matter
Claims 4, 5, and 9 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHBUBUL BAR CHOWDHURY whose telephone number is (571)272-0232. The examiner can normally be reached on Monday-Thursday 9AM-5PM EST; Friday variable.
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, Khaled Kassim can be reached on 571-270-3770. 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 http://pair-direct.uspto.gov. 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.
/MAHBUBUL BAR CHOWDHURY/Primary Examiner, Art Unit 2475