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 .
DETAILED ACTION
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), filed on 1/9/2026 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 12/31/2025 has been entered. Claims 28-52 are pending.
Response to Arguments
2. Applicant's arguments been fully considered but they are not persuasive. The applicant argues the following issues.
(A) Rejection under 35 U.S.C. 102/103
Issue 1: Applicant states that “Each of the independent claims has been amended to recite the feature of a conditioning apparatus configured to normalize protocol-specific POU identifier formats and to generate a search vector including at least: (i) the POU identifier, (ii) information characterizing the input interfaces, and (iii) information characterizing a remote receive bus. In contrast, nowhere does Tu disclose or suggest this feature. In view of all of the foregoing, withdrawal of this rejection is respectfully requested.”
Examiner respectfully disagrees.
First of all, on the contrary to the Applicant’s statement, only one of the independent claims, i.e., claim 28 has been amended to reflect the new limitation as cited by the Applicant. Other independent claims have not been amended at all.
Secondly, regarding the amended limitations of claim 28, Applicant’s argument are moot in light of the new ground of rejections set forth in the corresponding rejection section below. Please also see Examiner’s interpretation stated in the rejection sections.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 28-52 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). This judicial exception is not integrated into a practical application because of the reasons indicated below. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the reasons indicated below. As to claim 28,
Step 1: Statutory Category? Yes, subject to 101 rejections set forth above, claim 28 is a method /system/medium claims therefore belong to the four Categories of Invention.
Step 2A, prong ONE, Judicial Exception Recited? Yes. The claim recites the limitation of providing information items based on collected/received information item. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of a hardware component. That is, other than reciting of a hardware component, nothing in the claim element precludes the step from practically being performed in the mind or on paper. For example, but for the recited hardware component language, the claim encompasses a user simply receiving information and deciding to provide information in his/her mind or on paper. The mere nominal recitation of a generic hardware component or a network does not take the claim limitation out of the mental processes grouping. Thus, the claim recites a mental process.
Step 2A, prong TWO, Integrated into a practical application? No. The collecting/receiving step is recited at a high level of generality (i.e., as a general means of gathering information for use in the providing step), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. The hardware component or a network that is involved is also recited at a high level of generality. Each of the additional limitations is no more than mere instructions to apply the exception in a generic network.
Step 2B, Claim provides an Inventive Concept? No. As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic hardware/network. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The background of the claim does not provide any indication that the network is anything other than generic, and the Symantec, TLI, and OIP Techs. court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Accordingly, a conclusion that the collecting/receiving steps are well-understood, routine, conventional activity is supported under Berkheimer Option 2. Claims 29-52 are similarly rejected.
For the foregoing reasons, claims 28-52 are considered nonstatutory.
Claim Rejections - 35 USC § 112
5. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
6. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
7. Claims 28-44 and 52 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 28 recites “a conditioning apparatus configured to normalize protocol-specific PDU identifier formats.” However, the originally filed application, merely recites “normalize, a PDU identifier associated with a received protocol data unit”. Claims 29-44 and 52 are similarly rejected.
8. 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.
9. 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.
10. Claims 28-44 and 52 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. Claim 28 recites “a conditioning apparatus configured to normalize protocol-specific PDU identifier formats.” However, the originally filed application, merely recites “normalize, a PDU identifier associated with a received protocol data unit”. For the sake of the examination, Examiner presumes in light of the specification that the claimed limitation reads “configured to normalize a PDU identifier associated with a received protocol data unit”. Claims 29-44 and 52 are similarly rejected.
Claim Rejections - 35 USC § 103
11. 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.
12. 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 of this title, 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.
13. 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.
14. Claims 28-30, 32-52 are rejected under 35 U.S.C. 103 as being unpatentable over Tu (US 20190379606, submitted by IDS).
As to claim 28, Tu discloses a device for processing data units including protocol data units, comprising:
a first number of input interfaces configured to receive protocol data units (Figure 5; [0043], “network interface controllers (NICs) 530 and 535 of the host computer”, wherein any subset of the NICs are a first number of input interfaces);
a second number of output interfaces configured to output protocol data units (Figure 5; [0043], “network interface controllers (NICs) 530 and 535 of the host computer”, wherein any subset of the NICs are a second number of output interfaces); and
a processing apparatus comprising at least one hardware component configured to perform a search, based on a PDU identifier associated with a received protocol data unit, in at least a first search tree, which has an allocation of in each case one PDU identifier to a connection identifier characterizing at least one data connection (Tu, Figure 3; [0023], "Upon receiving a packet, a forwarding element using the tuple space search classifier 100 extracts all packet header field values used by any of the subtables 105-115 (these packet header field values are often referred to as the flow key). The forwarding element computes hashes for each subtable using the different combinations of packet header fields and uses these hashes to search each of the subtables for matching flow entries (though certain optimizations can be used to allow certain searches to skip some of the subtables). In some embodiments, the classifier identifies a matching flow entry in a particular subtable by matching the hash value of the packet header fields for the particular subtable with a hash value for the flow entry, then verifying that the packet header field values do actually match those required by the flow entry match conditions”; [0024], “Each node in the decision tree narrows down the possible matches until the search reaches a leaf node that represents a single matching flow entry (or if all possible matches are eliminated). In some embodiments, each level of the search tree examines a specific bit or set of bits (e.g., a packet header field or portion of a packet header field) of the flow key"; [0041], "an exact-match cache that searches on a single set of packet headers for all packets such that each flow entry is only matched by a single data flow". Here, the packet field values as expressed in its hash is equivalent to a PDU identifier, and the corresponding "flow key" value in the matching flow entry is a connection identifier); and
a conditioning apparatus configured to normalize protocol-specific PDU identifier formats (see 112 rejection and Examiner’s interpretation therein. See citation above, wherein the hash is a normalized/standardized identifier in order to be compared with at the receiver end).
As cited above, Tu not only uses the generated PDU identifier (hash) as a search vector element, but also discloses “then verifying that the packet header field values do actually match those required by the flow entry match conditions” (see citation above e.g., [0023]), wherein the fields used for said verifying can be considered additional search vector elements.
However, Tu at [0023] does not expressly disclose that the fields used for verifying comprises at least (ii) information characterizing the input interfaces, and (iii) information characterizing a remote receive bus. Tu further discloses that further verification/searching can comprises at least (ii) information characterizing the input interfaces, and (iii) information characterizing a remote receive bus (see Figure 2; [0025], wherein the destination address and port are information characterizing a remote receive bus. See [0046], “For instance, a logical switch might have an ingress mapping stage, an ingress ACL stage, a logical forwarding stage, an egress ACL stage, etc.). For a forwarding element implementing multiple logical networks, each of the logical networks has several stages of flow tables in some embodiments”, wherein the ingress mapping stage per the respective flow table indicates information characterizing the input interfaces. It is to be noted that the claimed limitation merely recites a search vector without requiring a specific format or how the elements in the search vector are used for searching. As a result, Examiner interprets under broadest reasonable interpretation that the elements in the search vector are in any format and are used in any way/timing related to a search).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tu’s disclosures. The suggestion/motivation would have been to enable verification of search results and/or performing additional search in sub-tables (Tu, [0023]-[0025]).
As to claim 45, see similar rejection to claim 28, without the last limitation of claim 28.
As to claim 49, see similar rejection to claim 28, without the last limitation of claim 28.
As to claim 50, see similar rejection to claim 28, without the last limitation of claim 28.
As to claim 51, see similar rejection to claim 28. It is to be noted that the automotive gateway as recited in the preamble is not recited to be part of the limitations therefore the scope is interpreted using the limitations.
As to claim 29, Tu discloses the device according to claim 28, wherein the device is configured to ascertain, based on the received protocol data unit, a connection identifier associated with the received
protocol data unit (see citation in rejection to claim 28, last limitation).
As to claim 46, see similar rejection to claim 29.
As to claim 30, Tu discloses the device according to claim 29, wherein the at least one hardware component is configured to perform the search in the first search tree and/or to ascertain the connection identifier associated with the received protocol data unit (Figure 5; [0043], it is to be noted that the claim does not require that the at least one hardware component be the only component alone configured to perform the search).
As to claim 47, see similar rejection to claim 30.
As to claim 32, Tu discloses the device according to claim 29, wherein the device is configured to output, based on the connection identifier associated with the received protocol data unit, the received
protocol data unit to at least one particular output interface of the second number of output
interfaces ([0020], “outputting the packet to a particular port” where a port is a particular interface of the NICs).
As to claim 33, Tu discloses the device according to claim 30, wherein the processing apparatus has at least one software component which is configured to at least temporarily a) form the first search tree and/or b) modify the first search tree ([0043]; [0019]).
As to claim 48, Tu discloses the method according to claim 45, wherein the processing apparatus has at least one software component, and wherein the method further comprises:
a) at least temporarily forming the first search tree using the at least one software component, and/or
b) at least temporarily balancing the first search tree using the at least one software component (see similar rejection to claim 33, e.g., [0043]; [0019]).
As to claim 34, Tu discloses the device according to claim 33, wherein the at least one software component is configured to perform a predeterminable response when no connection identifier associated with the received protocol data unit can be ascertained for the received protocol data unit, wherein the predeterminable response has at least one of the following elements: a) discarding the received protocol data unit, b) assigning a connection identifier to the received protocol data unit (since this limitation is conditional on the “when…” condition which does not necessarily happen, the limitations are not given patentable weight. Alternatively, see [0019], wherein in the case of a cache miss, a connection identifier matched by the secondary cache is assigned to the packet), c) setting or inserting a first piece of information for the received protocol data unit, wherein the
first piece of information indicates that the received protocol data unit is to be subjected to a
check using a firewall apparatus.
As to claim 35, Tu discloses the device according to claim 33, wherein the at least one software component is configured to: (i) generate, based on the first search tree, a second search tree, and/or (ii) to modify the second search tree ([0037]; [0039]).
As to claim 36, Tu discloses the device according to claim 35, wherein: a) the first search tree and/or the second search tree is a red-black tree, and/or b) the device is configured to organize the first
search tree and/or the second search tree at least temporarily in the form of at least one table (claim 5).
As to claim 37, Tu discloses the device according to claim 35, wherein the device is configured to, in a manner at least partially overlapping in time ([0043], hardware and software work together to carry out the functions), a) ascertain, based on the received protocol data unit, a connection identifier associated with the received protocol data unit using the at least one hardware component by performing the search in the first search tree using the at least one hardware component (see citation in rejecting to claims 28-30), and b) generate, using the at least one software component the second search tree based on the first search tree, and/or modify the second search tree (see citation in rejection to claim 33).
As to claim 38, Tu discloses the device according to claim 35, wherein the device is configured to perform at least one of the following elements: a) using the first search tree or the second search tree
selectively to ascertain the connection identifier associated with the received protocol data unit ([0019]), b) transmitting a content of the second search tree and/ or a structure of the second search tree to the first search tree, c) transmitting a content of the first search tree and/ or a structure of the first search tree, to the second search tree.
As to claim 39, Tu discloses the device according to claim 35, wherein the at least one software component is configured to signal to the at least one hardware component ([0043], software to signal hardware to perform functions is implied), at least one of the following elements using a second piece of information: a) the first search tree is to be used for performing the search, b) the second search tree is to be used for performing the search ([0019]), c) a modification of the first search tree and/or of the second search tree including an insertion of at least one node and/or a balancing of the first search tree and/or of the second search tree, has been completed.
As to claim 40, Tu discloses the device according to claim 39, wherein the at least one hardware component is configured to use, based on the signaling, the first search tree or the second search tree or performing the search ([0019]; [0043]).
As to claim 41, Tu discloses the device according to claim 40, wherein the at least one hardware component is configured to activate one of the first search tree or the second search tree between two search operations thereby specifying which search tree will be used for the next search ([0019]), by specifying which of the first search tree and the second search tree is to be used from then on for performing the search or searches ([0019]; [0035]).
As to claim 42, Tu discloses the device according to claim 28, wherein the device is configured to control or regulate a rate at which protocol data units are output via at least one output interface of the second number of output interfaces ([0020], “These actions can include outputting the packet to a particular port, dropping the packet”, wherein outputting some packet(s) and dropping some packet(s) is equivalent to control or regulate a rate at which the packets are output to the port).
As to claim 43, Tu discloses the device according to claim 28, further comprising at least one memory for at least temporarily storing one or more protocol data units or parts of one or more protocol data units (see citation in rejection to claim 28, wherein memory for storing the packets to extract headers from).
As to claim 44, Tu discloses the device according to claim 28, further comprising a conditioning apparatus, which is configured to change a PDU identifier associated with a received protocol data unit (see citation in rejection to claim 28 above, wherein an PDU identifier is determined by the packet headers, see [0020], “modifying certain packet header fields” which indicates change a PDU identifier).
As to claim 51, Tu discloses the device according to claim 28, wherein the device is used for at least one of the following elements:
a) processing protocol data units of a motor vehicle,
b) searching for, using a hardware component, a connection identifier associated with a received protocol data unit,
c) managing at least one search tree ([0003], “The caches are updated such that the secondary cache is guaranteed to have the most up-to-date flow entries, while the primary decision tree cache (which is generally faster to search but involves more resources and time to update) is only updated at certain intervals”),
d) performing a hardware-based search of a connection identifier of a gateway for a protocol data unit for an automotive application,
e) routing or forwarding protocol data units of a motor vehicle, wherein, the protocol data units can be of different types,
f) assigning a connection identifier independent of a protocol,
g) performing multicast transmissions,
h) ascertaining whether no connection identifier is provided for a predeterminable received protocol data unit (Figure 3, “Decision Tree Miss”),
i) software-based processing of a received protocol data unit for which no connection identifier is provided.
15. Claims 31 are rejected under 35 U.S.C. 103 as being unpatentable over Tu, as applied to claim 28 above and further in view of Oy (WO 01/63852, submitted by IDS).
As to claim 31, Tu discloses the claimed invention substantially as discussed in claim 28, but does not expressly disclose that the first search tree is a binary tree. Oy discloses a concept of a search tree to be a binary tree (page 2, paragraph 3).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Tu with Oy. The suggestion/motivation of the combination would have been to utilize binary tree model (Oy, page 2, paragraph 3).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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 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.
/HUA FAN/Primary Examiner, Art Unit 2458
Prosecution Insights