DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
2. 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.
3. 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.
4. The factual inquiries 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.
5. 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.
6. Claims 1-4, 6-8, 10-12, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Nádas et al. (US 2018/0109503 A1, hereinafter “Nádas”) in view of Choong et al. (WO 2008/015379 A1, hereinafter “Choong”).
Regarding claims 1, 11 and 14, Nádas teaches a discrimination method comprising: discriminating a first message concerning a first flow among a set of messages concerning a plurality of flows, transmitted by a terminal equipment (figs. 1, 3, 4, 9-11, 13, ¶ [0090]) to a data server (figs. 1, 9-11, ¶ [0041], ¶ [0042], ¶ [0043], ¶ [0042], In case the connection comprises multiplexed flows, the connection specific encryption may be represented by a flow specific encryption (e.g. some parameters of the flow will render the encryption a connection-specific encryption, ¶ [0048]) by way of a routing device, which is configured to apply a processing to an attribute relating to the first message (e.g., Network Entity/Middlebox 130 in figs. 1, 9-11, 13, ¶ [0045], ¶ [0077]), said discriminating being implemented by the terminal equipment (figs. 1, 9-11, 13, ¶ [0045], ¶ [0077]) and comprising: adding the attribute relating to the first message to an information packet (figs. 6, 9-11, ¶ [0042], The receiver entity (110) is configured to further send to the sender entity (120) at least one encrypted meta-information for said connection (noting that the request and the encrypted meta-information could be send together or separately, physically and/or logically, and any combination thereof). Said meta-information may be a marker which indicates a specific treatment of the requested data along the network path. ¶ [0044], the meta-information (in FIG. 6 exemplified by a marker) might be inserted in the header (either in the encrypted header or in the un-encrypted header), it may be attached at the head or at the tail of the packet, or it may be inserted in any position of the header or payload, or interposed between header and payload, ¶ [0045], ¶ [0047]), said packet comprising an attribute corresponding to a first flow, applying a tag for the information packet comprising the added attribute, and transmitting the information packet comprising the applied tag to the data server (figs. 6, 9-11, ¶ [0044], the meta-information (in FIG. 6 exemplified by a marker) might be inserted in the header (either in the encrypted header or in the un-encrypted header), it may be attached at the head or at the tail of the packet, or it may be inserted in any position of the header or payload, or interposed between header and payload, ¶ [0045], ¶ [0070], In step 6 of FIG. 10, the sender may encrypt the packet (e.g. the TCID (Traffic Characteristics identifier) and the payload) and transmit it to the sender. The packet is forwarded by network entities through the network until it reaches the sender; the middlebox is an example of the network entity forwarding the packet and applying a treatment on the packet on the basis of the meta-information. In step 7 of FIG. 10, the middlebox decrypts the packet, in particular it decrypts the TCID in order to apply the treatment corresponding to the TCID (decrypted) value so that the packet can be forwarded according to the intended treatment. ¶ [0072]).
Nádas does not explicitly teach discriminating a first message concerning a first application among a set of messages concerning a plurality of applications, wherein attributes concerning the applications are grouped into information packets, and the attribute indicates that the first message corresponds to the first application.
Choong teaches discriminating a first message concerning a first application among a set of messages concerning a plurality of applications (figs. 3A-5, 7-9. Page 10, tables 2-5), wherein attributes concerning the applications are grouped into information packets, and the attribute indicates that the first message corresponds to the first application (Page 10, table 2. Page 11: “…The incoming packets are associated with a network priority parameter (X= 1-6) and/or a user defined priority index (Y= 1-6). Where included, the user defined priority index (Y) may be provided in an IP Options header field built by the API 112 of a user device 110 or a server 130, or in any other suitable manner. The network priority parameter (X) may be provided in the same or a different IP Options header field built by the user device 110 or server 130, by mapping from the contents of the TOS field, or any other Suitable manner. Thus the two priority measures (X and Y) may be determined simply by extracting the contents of the App Type 260 and U.QoS 265 fields from an appropriate IP Options field 200 of the header 152 of the respective packet 150…” Page 12: “…Where received packets are only associated with or contain a network priority parameter (X) and no user defined priority index (Y), they are prioritised according to their network priority parameter (X) only. Table 2 above shows the types of user applications assigned the different network priority parameters (X), for example a voice call application such as Skype is allocated a network priority parameter (X) of 1, whereas e-mail and paging applications are assigned a network priority parameter (X) of 4. In the arrangement shown, incoming packets having a network priority level X=I or X=2 are input into the highest priority queue Ql 330.sub.ql. … Where the received packets are associated with or contain a user defined priority index (Y), any associated network priority parameter (X) is ignored in this embodiment; and then prioritisation for transmission is based solely on the user defined priority index (Y). Table 2 shows a user defined priority index (Y=l-6) for each application type” In other words, attributes/types of applications, e.g., e-mail and paging applications, are grouped into network priority of 4 and inserted into information packets. Page 13 )
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to discriminate a first message concerning a first application among a set of messages concerning a plurality of applications, and group attributes, indicating that a specific message corresponds to a specific application, concerning the applications into information packets, in the system of Nádas to utilize conventional techniques of prioritizing/discriminating traffic per application.
Regarding claim 2, Nádas in view of Choong teaches the discrimination method, as claimed in claim 1, wherein the terminal equipment transmits the plurality of messages to the data server in a secure session between the terminal equipment and the data server (Nádas: figs. 7-11).
Regarding claim 3, Nádas in view of Choong teaches the discrimination method, as claimed in claim 1, wherein the information packet is a packet of a secure stream multiplexing protocol (Nádas: figs. 7-11, ¶ [0042]).
Regarding claim 4, Nádas in view of Choong teaches the discrimination method, as claimed in claim 3, wherein the secure stream multiplexing protocol is a protocol from among the following protocols: the MPTCP protocol, the SCTP protocol, the QUIC protocol, the HTTP2 protocol, the SPDY protocol, the HTTP3 protocol (Nádas: ¶ [0055], ¶ [0002]).
Regarding claim 6, Nádas in view of Choong teaches the discrimination method, as claimed in claim 1, wherein the terminal equipment is an equipment configured to access a local area network routing the plurality of messages from and to terminals of the local area network (Nádas: fig. 1, ¶ [0041], The network entity (also referred herein in some examples as middlebox) is interposed between the sender entity and the receiver entity. Examples of network entities or middleboxes are: Policy Decision Points, DPI/SPI boxes, edge routers, etc. ¶ [0042]-¶ [0045]. Choong: fig. 1).
Regarding claim 7, Nádas in view of Choong teaches the discrimination method, as claimed in claim 1.
Nádas does not explicitly teach moreover further comprising, prior to adding the attribute, selecting said first message according to one or more criteria consisting of: the first application is included in a list of applications that is managed by the terminal equipment, the first message is received from a terminal for which an identifier is included in a list of identifiers that is managed by the terminal equipment, the first message comprises a datum relating to a quality of service, said datum being included in a set of data managed by the terminal.
Choong teaches selecting said first message according the first application is included in a list of applications that is managed by the terminal equipment (pages 8 and 10).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to select said first message according the first application is included in a list of applications that is managed by the terminal equipment in the system of Nádas in view of Choong to utilize conventional techniques of prioritizing/discriminating traffic per application.
Regarding claims 8, 12 and 15, Nádas teaches a processing method comprising: processing an attribute relating to a first message concerning a first application, said first message being transmitted by a terminal equipment to a data server (figs. 1, 9-11, ¶ [0042], ¶ [0043]), the method being implemented by a device (e.g., Network Entity/Middlebox 130 in figs. 1, 9-11, 13, ¶ [0045], ¶ [0077]) routing the first message (figs. 9-11, ¶ [0045], The network entity (130) is configured to decrypt the at least one meta-information and to process the at least one packet on the basis of the decrypted at least one meta-information. To process the packet refers to apply, to the at least one packet on the basis of the decrypted at least one meta-information, a packet forwarding treatment when processing the forwarding or relaying of the packet on the network. The packet forwarding treatment includes policing, shaping, possible remarking (i.e. changing the marker with another one, or changing its value), queuing treatment, or scheduling treatment), and comprising: detecting a received information packet comprising the attribute added by the terminal equipment, according to a tag applied to the received information packet, and processing the attribute included in the received information packet (figs. 6, 9-11, ¶ [0042], ¶ [0044], the meta-information (in FIG. 6 exemplified by a marker) might be inserted in the header (either in the encrypted header or in the un-encrypted header), it may be attached at the head or at the tail of the packet, or it may be inserted in any position of the header or payload, or interposed between header and payload, ¶ [0045], ¶ [0047[, ¶ [0070], In step 6 of FIG. 10, the sender may encrypt the packet (e.g. the TCID and the payload) and transmit it to the sender. The packet is forwarded by network entities through the network until it reaches the sender; the middlebox is an example of the network entity forwarding the packet and applying a treatment on the packet on the basis of the meta-information. In step 7 of FIG. 10, the middlebox decrypts the packet, in particular it decrypts the TCID in order to apply the treatment corresponding to the TCID (decrypted) value so that the packet can be forwarded according to the intended treatment. ¶ [0072]).
Nadas does not explicitly teach wherein attributes concerning different applications are grouped into information packets, and the attribute indicates that the first message corresponds to the first application.
Choong teaches attributes concerning the applications are grouped into information packets, and the attribute indicates that the first message corresponds to the first application (Page 10, table 2. Page 11: “…The incoming packets are associated with a network priority parameter (X= 1-6) and/or a user defined priority index (Y= 1-6). Where included, the user defined priority index (Y) may be provided in an IP Options header field built by the API 112 of a user device 110 or a server 130, or in any other suitable manner. The network priority parameter (X) may be provided in the same or a different IP Options header field built by the user device 110 or server 130, by mapping from the contents of the TOS field, or any other Suitable manner. Thus the two priority measures (X and Y) may be determined simply by extracting the contents of the App Type 260 and U.QoS 265 fields from an appropriate IP Options field 200 of the header 152 of the respective packet 150…” Page 12: “…Where received packets are only associated with or contain a network priority parameter (X) and no user defined priority index (Y), they are prioritised according to their network priority parameter (X) only. Table 2 above shows the types of user applications assigned the different network priority parameters (X), for example a voice call application such as Skype is allocated a network priority parameter (X) of 1, whereas e-mail and paging applications are assigned a network priority parameter (X) of 4. In the arrangement shown, incoming packets having a network priority level X=I or X=2 are input into the highest priority queue Ql 330.sub.ql. … Where the received packets are associated with or contain a user defined priority index (Y), any associated network priority parameter (X) is ignored in this embodiment; and then prioritisation for transmission is based solely on the user defined priority index (Y). Table 2 shows a user defined priority index (Y=l-6) for each application type” In other words, attributes/types of applications, e.g., e-mail and paging applications, are grouped into network priority of 4 and inserted into information packets. Page 13 )
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to group attributes, indicating that a specific message corresponds to a specific application, concerning the applications into information packets, in the system of Nádas to utilize conventional techniques of prioritizing/discriminating traffic per application.
Regarding claim 10, Nádas in view of Choong teaches the processing method, as claimed in claim 8, further comprising receiving and applying a processing relating to a second message concerning the first application, on the basis of an attribute included in a second information packet having an applied tag, said second information packet being received from the data server and to the terminal (Nadas: figs. 9-11, ¶ [0042], ¶ [0044], ¶ [0045], ¶ [0048], ¶ [0050], ¶ [0070]).
7. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Nádas in view of Choong as applied to claim 3 above, and further in view of He et al. (US 2021/0006642 A1, hereinafter “He”).
Regarding claim 5, Nádas in view of Choong teaches the discrimination method, as claimed in claim 3, wherein the secure stream multiplexing protocol is the QUIC protocol (Nádas: ¶ [0055]).
Nádas does not explicitly teach the application of the tag comprises modifying binary elements among a “spin bit” and/or “reserved bits”.
He teaches the spin bit of the QUIC protocol may be utilized to calculate the RTT which can be used as a metric to determine whether or not there is an issue in the network. The QUIC protocol is built on top of the UDP protocol. In the QUIC protocol, all signaling data is encrypted with the exception of the QUIC spin bit (¶ [0154]).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to utilize the unencrypted QUIC spin bit for application of tag in the system of Nádas in view of Choong. The motivation for doing this is a matter of design choice.
8. Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Nádas in view of Ma et al. (US 9,083,740 B1, hereinafter “Ma”).
Regarding claim 9, Nádas teaches the processing method, as claimed in claim 8.
Nádas does not explicitly teach wherein the processing comprises counting at least one datum relating to the application on the basis of the processed attribute.
Ma teaches wherein the processing comprises counting at least one datum relating to the application on the basis of the processed attribute (col. 6, lines 43-46, col. 16, line 63-col. 17, line 8).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to count at least one datum relating to the application on the basis of the processed attribute in the system of Nádas to detect malicious attack (col. 2, lines 34-42 of Ma).
Response to Arguments
9. Applicant's arguments filed on September 30, 2025 have been fully considered but they are not persuasive.
10. Applicant argues “…In addition, the solution of Choong does not disclose the relationship between the message, the packet, the attribute and the tag. Choong does not specially design the format of the packet to be transmitted for each message. Therefore, those of ordinary skill in the art would not think of adding the attribute relating to the first message to an information packet, and applying a tag to the information packet comprising the added attribute based on Choong… Besides, the meta-information in Nadas only relates to a specific treatment of the packet, which does not relate to the application. On this basis, the meta-information cannot be used for discriminate a first message concerning a first application among a set of messages concerning a plurality of applications… Thus, Choong only refers to assigning a priority level to a user application. It does not refer to how to discriminate a first message concerning a first application among a set of messages concerning a plurality of applications (the discrimination of a message meaning identification of a message among other messages)…”
Examiner respectfully disagrees and submits that during patent examination, claims are given the broadest reasonable interpretation consistent with the specification and limitations in the specification are not read into the claims (In re Yamamoto, 740 F.2d 1569, 222 USPQ 934 (Fed. Cir. 1984)).
Further, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091,231 USPQ 375 (Fed. Cir. 1986).
In this case: claims merely requires “adding an attribute relating to the first message to an information packet…”
The information packet and the first message being separate packets/messages or the attribute not being added to the first message is not a claim requirement.
Nadas, using the broadest reasonable interpretation, teaches adding an attribute relating to the first message to an information packet, as the first message with added attribute/tag can be interpreted as an information packet.
Further, Nadas teaches at least one encrypted meta-information for said connection (noting that the request and the encrypted meta-information could be send together or separately, physically and/or logically, and any combination thereof)( ¶ [0042]).
Choong teaches discriminating a first message concerning a first application among a set of messages concerning a plurality of applications (figs. 3A-5, 7-9, Page 10, table 2. Pages 11-13).
Therefore, Nadas in view of Choong render obvious the amended claims, as set forth above.
Conclusion
11 Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached on 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477