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
The instant application having Application No. 18/732,672 is presented for examination by the examiner.
Claims 1-20 have been examined.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) use generic placeholders that are coupled with functional language without reciting sufficient structure to perform the recited functions, and the generic placeholders are not preceded by a structural modifier. Such claim limitation(s) include: “receiver module,” “connection identifier module,” “connection state maintenance module,” “content analysis module,” “buffer management module,” and “blocking module,” as recited in claims 1–8 (i.e., generic placeholders “module” are coupled with functional language such as receiving, identifying, maintaining, analyzing, managing, and blocking). Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 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.
Claims 1, 2, 6, 9, 10, 14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Useckas (US 2024/0333756 A1), in view of Rivera (US 2024/0340271 A1).
Regarding Claim 1
Useckas discloses:
A system of blocking malicious connections based on application layer state into extended Berkeley Packet Filter (eBPF) program, the system comprising:
a receiver module to receive one or more Hypertext Transfer Protocol (HTTP) requests from one or more user devices, wherein the one or more HTTP requests are associated with one or more connections (Useckas ¶12, 14: teaches receiving HTTP requests from user devices by capturing IP packets and reassembling them into Layer-7 application flows, explicitly including HTTP flows that are received as network connections to a protected application.);
a content analysis module to analyze content associated with the received one or more HTTP requests to detect malicious content, wherein the analysis is performed by inspecting at least one of: headers, payloads, and relevant request parts of corresponding HTTP request via the eBPF program to identify potentially harmful and unauthorized requests (Useckas ¶8: teaches a content analysis module that analyzes HTTP request content to detect malicious activity via an eBPF-based inspection pipeline. Specifically, Useckas discloses capturing network traffic using an eBPF subsystem, reassembling the traffic into Layer-7 HTTP flows, and applying dynamic contextual rules to determine malicious intent. Useckas ¶40: further teaches parsing HTTP traffic to extract protocol-specific data such as URIs, headers, and request bodies, thereby inspecting headers, payloads, and relevant request parts. Additionally, Useckas ¶62: explains that the system captures flows at the eBPF level, applies contextual rules to the reassembled Layer-7 data, and decides whether to allow or block communications based on whether the traffic is malicious.); and
a blocking module to block the one or more connections associated with the detected malicious content based on the assigned unique identifier of the one or more connections (Useckas ¶31: teaches a blocking module that blocks one or more connections associated with detected malicious content by applying dynamic contextual rules to reassembled Layer 7 protocol flows. When malicious intent is identified, the sensor module blocks further communications from the source of the IP network flow by dropping or rejecting requests, thereby preventing continued communication on that flow. Because blocking is performed on specific Layer 7 flows corresponding to individual IP network flows, the blocking is connection specific and would be obvious to a person skilled in the art to be based on identification of the connection being blocked.).
Useckas teaches performing application-layer inspection and blocking of malicious communications on a per-flow basis using an eBPF subsystem (Useckas ¶8, 12, 031). However, Useckas does not explicitly disclose the particular mechanisms used to uniquely identify and persistently track individual TLS and non-TLS connections using process-level and library-level identifiers, nor does Useckas disclose maintaining per-connection application-layer state derived from intercepted kernel or library function calls. Rivera teaches intercepting network-related kernel and user-space function calls using an eBPF-based traffic inspection subsystem and uniquely identifying and tracking individual connections using kernel-visible identifiers. For non-TLS connections, Rivera discloses extracting and storing socket file descriptors and associated process information from network system calls and associating that information with individual sessions or connections (Rivera ¶18, 32–34, 45). For TLS connections, Rivera further teaches identifying and tracking encrypted sessions based on the SSL/TLS context passed to encryption and decryption library functions, which corresponds to a memory-resident SSL structure uniquely identifying a TLS session (Rivera ¶37–41). Rivera also teaches a socket information maintenance module that stores, updates, and deletes per-connection state over time by intercepting repeated kernel and library function calls and correlating extracted application-layer data to the corresponding connection (Rivera ¶31–34, 43, 54). This constitutes maintaining application-layer state for each connection within an eBPF-based inspection framework.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Useckas to incorporate Rivera’s eBPF-based connection identification and state maintenance techniques in order to reliably distinguish, track, and maintain state for individual TLS and non-TLS connections while performing application-layer inspection and blocking. Both references are directed to kernel-level traffic inspection using eBPF, and Rivera’s use of file descriptors, process-level identifiers, and SSL/TLS context structures represents a known and predictable way to uniquely identify and maintain per-connection application-layer state in such systems, thereby improving the accuracy and robustness of the connection-based malicious traffic detection and blocking taught by Useckas.
Regarding Claim 2
Useckas teaches performing application-layer inspection and blocking of malicious communications on a per-flow basis using an eBPF-based traffic inspection subsystem (Useckas ¶8, 12, 31). However, Useckas does not explicitly disclose maintaining per-connection state using a combination of a unique connection identifier, data associated with successive kernel or library function calls, and previously stored state information. Rivera teaches maintaining connection state by combining a connection identifier with data extracted from intercepted kernel and library function calls and updating that information over time. Specifically, Rivera discloses intercepting kernel and user-space library calls using an eBPF-based traffic inspection subsystem and extracting socket file descriptors and associated process or protocol information, which are associated with individual sessions or connections (Rivera ¶18). Rivera further teaches a socket information maintenance module that stores, updates, and deletes saved socket information for each connection over time as additional function calls are intercepted (Rivera ¶31–34). Rivera additionally discloses gathering and storing per-connection event information, including session data, socket details, event type, and extracted data, for subsequent processing, thereby relying on previously stored state information when processing later events associated with the same connection (Rivera ¶43–47).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Useckas to incorporate Rivera’s per-connection state maintenance techniques in order to reliably maintain application-layer state for each connection across multiple kernel and library function calls. Both references operate in the context of eBPF-based traffic inspection, and Rivera’s use of stored socket and session information updated over time represents a known and predictable technique for maintaining per-connection state, thereby improving the accuracy and continuity of the malicious traffic detection and blocking taught by Useckas.
Regarding Claim 6
Useckas discloses:
The system of claim 1, wherein the content identifier module to perform string matching using eBPF maps for specific content in the one or more HTTP requests (Useckas ¶12, 31: teaches receiving HTTP requests by reassembling captured IP packets into Layer-7 application flows and performing application-layer inspection using an eBPF-based traffic inspection subsystem to match HTTP request content against predefined malicious patterns stored in data structures accessible to the eBPF program.).
Regarding Claim 9
Claim 9 is directed to a method corresponding to the system in claim 1. Claim 9 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 10
Claim 10 is directed to a method corresponding to the system in claim 2. Claim 10 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a method corresponding to the system in claim 6. Claim 14 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to computer-readable medium storing instruction corresponding to the system in claim 1. Claim 17 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claims 3-5, 11-13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Useckas (US 2024/0333756 A1), in view of Rivera (US 2024/0340271 A1) as applied to claims 1, 9 and 17 above, and in further view of Jain (US 2021/0216369 A1).
Regarding Claim 3
Useckas teaches performing application-layer inspection and blocking of malicious communications using eBPF programs attached to kernel code paths, enabling per-flow security analysis in kernel space (Useckas ¶8, 12, 31). Rivera further teaches maintaining per-connection and protocol-related state by associating connection identifiers with data extracted from successive kernel and library function calls and updating that state over time, such that later events associated with the same connection rely on previously stored state information (Rivera ¶18, 31–34, 43–47). However, while Useckas and Rivera together teach stateful per-connection analysis across multiple events, they do not explicitly disclose persisting protocol state in a manner that allows subsequent executions of an eBPF program to resume processing from a prior state so as to overcome execution or instruction limits inherent to eBPF programs. Jain teaches persisting execution or process state outside of a single eBPF execution and restoring that state during a subsequent execution, thereby allowing processing to resume from a previously stored state rather than restarting from an initial condition (Jain ¶24–27, 29, 34). Jain further teaches using eBPF as a lightweight trigger while offloading extended or state-intensive processing to user space to overcome eBPF execution constraints.
It would have been obvious to one of ordinary skill in the art to modify the stateful eBPF inspection system of Useckas and Rivera to incorporate Jain’s state persistence and restoration techniques in order to maintain protocol state across multiple eBPF executions and overcome known instruction and execution limits of eBPF programs. Such a modification represents a predictable use of known checkpointing and state-restoration techniques to extend stateful processing across constrained execution contexts, yielding the expected benefit of continuous protocol analysis without restarting processing from an initial state.
Regarding Claim 4
Useckas teaches performing application-layer inspection and blocking of malicious communications using eBPF programs attached to kernel code paths, enabling per-flow security analysis in kernel space (Useckas ¶8, 12, 31). Rivera further teaches maintaining per-connection and protocol-related state by associating connection identifiers with data extracted from successive kernel and library function calls and updating that state over time, such that later events associated with the same connection rely on previously stored state information (Rivera ¶18, 31–34, 43–47). However, while Useckas and Rivera together teach stateful per-connection analysis across multiple events, they do not explicitly disclose maintaining state by deliberately attaching an eBPF program multiple times to a function using a predefined, user-configurable number of probes in order to scale execution and overcome known eBPF instruction or processing limits. Jain teaches overcoming execution and processing limitations of kernel-attached programs by coordinating repeated executions of eBPF programs with user-space control and persistent state storage, such that processing can be distributed across multiple executions while preserving continuity of state (Jain ¶18–24, 27, 29–31). Jain therefore teaches dividing processing across multiple eBPF executions under user-space control to address execution constraints of kernel environments.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the stateful eBPF inspection system of Useckas and Rivera to incorporate Jain’s technique of distributing processing across multiple eBPF executions under user-space control in order to overcome known instruction and execution limits of eBPF programs. Configuring a predefined number (N) of probe attachments from user space to a function to scale effective processing capacity represents a predictable and routine design choice for addressing such known constraints, and would have yielded no more than predictable results.
Regarding Claim 5
Useckas teaches performing application-layer inspection of network traffic using eBPF programs attached to kernel code paths (Useckas ¶8, 12, 31), and Rivera teaches maintaining per-connection state information by storing and updating data associated with successive kernel and library function calls over time (Rivera ¶18, 31–34, 43–47). While Useckas and Rivera do not explicitly enumerate buffer structures, their per-connection processing necessarily involves reading incoming data associated with a connection across multiple read and write events. Jain teaches capturing and handling kernel-level TCP connection structures, including transmission (Tx) and receiver (Rx) buffer data, using an eBPF-triggered CRIU mechanism (Jain ¶29). Tx and Rx buffers are fixed-size kernel-managed buffers that are read from, written to, and advanced or moved as data is received and transmitted, thereby performing buffer management functions.
It would have been obvious to one of ordinary skill in the art to incorporate Jain’s handling of TCP Tx/Rx buffers into the stateful eBPF inspection systems of Useckas and Rivera in order to manage per-connection fixed-size buffers while reading and accommodating incoming data, representing a predictable use of known kernel buffer management techniques in an eBPF-based monitoring environment.
Regarding Claim 11
Claim 11 is directed to a method corresponding to the system in claim 3. Claim 11 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 12
Claim 12 is directed to a method corresponding to the system in claim 4. Claim 12 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a method corresponding to the system in claim 5. Claim 13 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 18
Useckas teaches an eBPF-based traffic inspection system that performs application-layer inspection of network traffic, including HTTP requests, by capturing and reassembling IP packets into Layer-7 flows and applying dynamic contextual rules to inspect request content and block malicious communications (Useckas ¶¶[0008], [0012], [0031], [0046]). However, Useckas does not explicitly disclose maintaining detailed per-connection state using kernel function call data and prior state information, persisting protocol state across multiple eBPF executions to overcome instruction limits, scaling execution via multiple probe attachments, or capturing detailed workload and buffer state. Rivera teaches maintaining per-connection and protocol-related state by intercepting kernel and user-space library function calls using an eBPF-based inspection subsystem, associating connection identifiers (e.g., socket file descriptors and SSL/TLS context structures) with extracted data, and storing, updating, and deleting per-connection state over time, such that later events rely on previously stored state information (Rivera ¶¶[0018], [0031]–[0034], [0043]–[0047]). Rivera further teaches correlating application-layer data, including HTTP request content, to maintained connection state for inspection. Jain teaches persisting execution and process state outside of a single eBPF execution and restoring that state in subsequent executions, thereby enabling processing to resume from a prior state to overcome execution and instruction limits inherent to eBPF programs (Jain ¶¶[0024]–[0027], [0029], [0034]). Jain further teaches capturing detailed workload process state, including kernel structures and TCP connection structures such as transmission (Tx) and receiver (Rx) buffer data, under user-space control using an eBPF-triggered mechanism.
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the eBPF-based inspection system of Useckas, as supplemented by Rivera’s per-connection state maintenance techniques, to incorporate Jain’s state persistence, restoration, and workload capture mechanisms in order to maintain connection and protocol state across multiple eBPF executions, distribute processing across repeated probe executions under user-space control to overcome known eBPF instruction limits, and preserve detailed connection and buffer state. Such a combination represents a predictable use of known eBPF, kernel-tracing, and checkpointing techniques to improve continuity, scalability, and robustness of stateful application-layer inspection, yielding no more than expected results.
Claims 7-8, 15-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Useckas (US 2024/0333756 A1), in view of Rivera (US 2024/0340271 A1) as applied to claims 1, 9 and 17 above, and in further view of Kim (US 20230376591 A1).
Regarding Claim 7
Useckas teaches performing application-layer inspection and blocking of malicious communications using eBPF programs attached to kernel code paths, enabling real-time security analysis and enforcement on network traffic associated with an application (Useckas ¶8, 12, 31). Rivera further teaches maintaining per-connection and protocol-related state by associating connection identifiers with data extracted from successive kernel and library function calls and updating that state over time, such that later events associated with the same connection rely on previously stored state information (Rivera ¶31–34, 43–47). Rivera thus teaches maintaining and updating connection state within an eBPF-based inspection framework. However, Useckas and Rivera do not explicitly disclose attaching an eBPF program to Linux Security Module (LSM) hooks to synchronously prevent a kernel operation from succeeding by returning an error code such as EPERM, nor explicitly marking a connection as blocked in internal state to force termination. Kim teaches attaching eBPF programs directly to LSM hooks to control kernel operations and synchronously block execution when malicious behavior is detected. Specifically, Kim discloses that eBPF programs are attached to LSM hooks and may allow or block kernel operations according to predefined security policies (Kim ¶12, 77). Kim further teaches returning an error code such as EPERM or EACCES from the LSM hook to prevent the call from succeeding, thereby stopping execution of the offending process (Kim ¶89–96). Kim additionally teaches storing process state information in eBPF maps and using that state to enforce security decisions across events (Kim ¶74–75, 85–86).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the stateful eBPF inspection system of Useckas and Rivera to incorporate Kim’s LSM-hook-based enforcement techniques in order to synchronously block malicious read or write operations at the kernel level and return EPERM to the application, while marking the associated connection state as blocked. Such a combination represents a predictable use of known eBPF and LSM mechanisms to strengthen enforcement capabilities in a kernel-level security monitoring system, thereby improving the effectiveness of malicious traffic detection and prevention taught by Useckas and Rivera.
Regarding Claim 8
Useckas teaches performing application-layer inspection and blocking of malicious communications using eBPF programs attached to kernel code paths, enabling real-time security analysis and enforcement on network traffic associated with an application (Useckas ¶8, 12, 31). Rivera further teaches maintaining per-connection and protocol-related state by associating connection identifiers with data extracted from successive kernel and library function calls and updating that state over time, such that later events associated with the same connection rely on previously stored state information (Rivera ¶31–34, 43–47). Rivera thus teaches maintaining and updating connection state within an eBPF-based inspection framework. However, Useckas and Rivera do not explicitly disclose synchronously preventing a probed kernel call from succeeding by overriding the return value of the probed function such that the application receives an EPERM return code. Kim teaches attaching eBPF programs to Linux Security Module (LSM) hooks to synchronously control kernel execution and block malicious operations by returning an error code. Specifically, Kim discloses that when malicious behavior is detected, an eBPF program attached to an LSM hook “returns an error such as EACCES or EPERM to the monitoring target process,” thereby preventing the call from succeeding (Kim ¶89). Kim further teaches that “a return value other than 0 may be transferred to the target container process, whereby execution of the target container process may be stopped” (Kim ¶16). Kim also discloses maintaining enforcement state using eBPF maps and task local storage to track blocked processes (Kim ¶74).
It would have been obvious to one of ordinary skill in the art to modify the stateful eBPF inspection system of Useckas and Rivera to incorporate Kim’s known eBPF-based return-value override techniques in order to synchronously prevent malicious read or write calls, return EPERM to the application, and mark the associated connection state as blocked. Such a modification represents a predictable use of known eBPF enforcement mechanisms to improve kernel-level blocking behavior in a stateful connection inspection system.
Regarding Claim 15
Claim 15 is directed to a method corresponding to the system in claim 7. Claim 15 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to a method corresponding to the system in claim 8. Claim 16 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to computer-readable medium storing instruction corresponding to the system in claim 7. Claim 19 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 is directed to computer-readable medium storing instruction corresponding to the system in claim 8. Claim 20 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 9:30am - 5:30pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431