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 .
This is in response to communications filed on 11/26/25.
Claims 1-20 are pending.
IDS filed on 2/26/26 has been considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 8-11, 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Waskiewicz et al (US Patent Application Publication 2022/0337682) and further in view of Wengrovitz et al (US Patent Application Publication 2012/0075465)
For claim 1, Waskiewicz et al teach the following limitations: A method, comprising: notifying a kernel of an operating system ([0027] Linux OS with kernel; [0041] kernel mode component of OS 208 loads 206; Fig 3 shows that OS 208 reads binary file 206; thus kernel is notified via binary file 206) executing on a computing device (device 102 in Fig 1; Fig 2-Fig 3; OS 208 is executing on 102; [0025]) that the kernel is to provide network packets received by the kernel ([0017] device loads the binary file, read the section with the offload hints and provide the offloads to NIC 132, which further provides metadata to ebpf program for further processing; thus, kernel is notified via the binary file to provide network packets to NIC and ebpf) via a network interface (via API mentioned in [0027] [0032] [0043] via an API; Fig 3 shows that the driver 216 and NIC 132 also works as the interface to 214) to an extended Berkeley Packet Filter (eBPF) program ([0017] [0027] [0029] [0030] [0032]-[0035][0042]-[0044] mention that network packets are offloaded to NIC and the results are returned to ebpf as metadata; Fig 3 shows that the packets are sent to NIC at 308 which then forwards to 214 at 310; 214 is the ebpf [0027]; Fig 3 further shows 208 sent packets 310 also; the metadata appends the packet [0050][0055]; thus the kernel 208 in Fig 3 sends the packets to ebpf program 214 based on the notification at step 302) executing in an eBPF environment of the kernel ([0027] [0032]; [0035] ebof virtual machine of OS 208); receiving, by the eBPF program from the kernel, a network packet and causing, by the eBPF program, information derived from the network packet to be copied to an buffer ([0030] – forwarding the packet to a device or interface; [0045] forward packet to a queue)
About the limitations “camera network packet originating from a camera”, Waskiewicz et al teach that device includes camera ([0023]). Since devices are connected via network as shown in Fig 1, device 102 can receive the network packets originating from camera of another device 102. Therefore, Waskiewicz et al teach the limitations “receiving camera network packet originating from a camera”.
Waskiewicz et al does not explicitly teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device.
Wengrovitz et al teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device (Fig 6, Fig 8 and [0011]; memory Fig 4 stores the driver for outputting display)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide an image buffer of the display device driver of a display, so that the system can display the camera outputs for the users. As mentioned in Waskiewicz et al, device can have a camera ([0023]). Thus, the camera images can be sent as the network packets to the other device so that the user of the other device can view the images of the camera of another device. That is particularly useful for surveillance camera system where one user remotely monitors the camera images taken by the sensors.
For claim 2, Waskiewicz et al teach operating system includes kernel and ebpf virtual machine ([0032][0041]). The ebpf is loaded later ([0032]) by OS. Thus, kernel and virtual machines are in different memory locations. Fig 2 shows the operating system and the ebpf program executing on VM. Although not mentioned, it is understood that RAM loads the OS kernel and VM as it is typical to load the OS and VM in RAM. [0032] mentions that kernel interacts with ebpf 214. Thus, kernel is provided with the information of the location of ebpf program. Waskiewicz et al does not explicitly mention about the bootloader. To load the OS/bytecode version of the ebpf. These operations are well known in the art. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a bootloader to load OS and bytecode version of ebpf, since that provides the streamlined booting of the system. \
For claim 3, Waskiewicz et al teach receiving metadata by the ebpf ([0050][0055]. The metadata includes hash. Thus, the metadata is an encoded packet. The eBPF program decapsulate the packet and forward to a queue ([0029]-0030] [0038] and [0045]). Thus, after decoding, the packet data is forwarded to queue.
For claim 4, Fig 2 Waskiewicz et al mention that 214 ebpf is the packet processing program and Fig 3 shows OS is forwarding to program 214. Fig 6 608 shows the execution of VM. [0030] mentions packet processing by 214. Thus, eBPF program can invoke functions and attached to kernel network packet tracepoint.
For claim 8, Waskiewicz et al teach the following limitations: A computing device (Fig 1 102 is the device), comprising: a random access memory (126 in Fig 1; can be any volatile memory[0020] thus the memory can be RAM); a network interface operable to interface with a camera ([0023] mentions camera; thus the network interface shown in Fig 1 130 interfaces with camera); and a processor device coupled to the random access memory and the network interface ([0056]), the processor device operable to: notify a kernel of an operating system ([0027] Linux OS with kernel; [0041] kernel mode component of OS 208 loads 206; Fig 3 shows that OS 208 reads binary file 206; thus kernel is notified via binary file 206) executing on a computing device (device 102 in Fig 1; Fig 2-Fig 3; OS 208 is executing on 102; [0025]) that the kernel is to provide network packets received by the kernel ([0017] device loads the binary file, read the section with the offload hints and provide the offloads to NIC 132, which further provides metadata to ebpf program for further processing; thus, kernel is notified via the binary file to provide network packets to NIC and ebpf) via a network interface (via API mentioned in [0027] [0032] [0043] via an API; Fig 3 shows that the driver 216 and NIC 132 also works as the interface to 214) to an extended Berkeley Packet Filter (eBPF) program ([0017] [0027] [0029] [0030] [0032]-[0035][0042]-[0044] mention that network packets are offloaded to NIC and the results are returned to ebpf as metadata; Fig 3 shows that the packets are sent to NIC at 308 which then forwards to 214 at 310; 214 is the ebpf [0027]; Fig 3 further shows 208 sent packets 310 also; the metadata appends the packet [0050][0055]; thus the kernel 208 in Fig 3 sends the packets to ebpf program 214 based on the notification at step 302) executing in an eBPF environment of the kernel ([0027] [0032]; [0035] ebof virtual machine of OS 208); receive, by the eBPF program from the kernel, a network packet and cause, by the eBPF program, information derived from the network packet to be copied to an buffer ([0030] – forwarding the packet to a device or interface; [0045] forward packet to a queue)
About the limitations “camera network packet originating from a camera”, Waskiewicz et al teach that device includes camera ([0023]). Since devices are connected via network as shown in Fig 1, device 102 can receive the network packets originating from camera of another device 102. Therefore, Waskiewicz et al teach the limitations “receiving camera network packet originating from a camera”.
Waskiewicz et al does not explicitly teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device.
Wengrovitz et al teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device (Fig 6, Fig 8 and [0011]; memory Fig 4 stores the driver for outputting display)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide an image buffer of the display device driver of a display, so that the system can display the camera outputs for the users. As mentioned in Waskiewicz et al, device can have a camera. Thus, the camera images can be sent as the network packets to the other device so that the user of the other device can view the images of the camera of another device. That is particularly useful for surveillance camera system where one user remotely monitors the camera images taken by the sensors.
For claim 9, Waskiewicz et al teach operating system includes kernel and ebpf virtual machine ([0032][0041]). The ebpf is loaded later ([0032]) by OS. Thus, kernel and virtual machines are in different memory locations. Fig 2 shows the operating system and the ebpf program executing on VM. Although not mentioned, it is understood that RAM loads the OS kernel and VM as it is typical to load the OS and VM in RAM. [0032] mentions that kernel interacts with ebpf 214. Thus, kernel is provided with the information of the location of ebpf program. Waskiewicz et al does not explicitly mention about the bootloader. To load the OS/bytecode version of the ebpf. These operations are well known in the art. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a bootloader to load OS and bytecode version of ebpf, since that provides the streamlined booting of the system. \
For claim 10, Waskiewicz et al teach receiving metadata by the ebpf ([0050][0055]. The metadata includes hash. Thus, the metadata is an encoded packet. The eBPF program decapsulate the packet and forward to a queue ([0029]-0030] [0038] and [0045]). Thus, after decoding, the packet data is forwarded to queue.
For claim 11, Fig 2 Waskiewicz et al mention that 214 ebpf is the packet processing program and Fig 3 shows OS is forwarding to program 214. Fig 6 608 shows the execution of VM. [0030] mentions packet processing by 214. Thus, eBPF program can invoke functions and attached to kernel network packet tracepoint.
For claim 15, Waskiewicz et al teach the following limitations: A non-transitory computer-readable storage medium that includes executable instructions to cause a processor device ([0056]) to: notify a kernel of an operating system ([0027] Linux OS with kernel; [0041] kernel mode component of OS 208 loads 206; Fig 3 shows that OS 208 reads binary file 206; thus kernel is notified via binary file 206) executing on a computing device (device 102 in Fig 1; Fig 2-Fig 3; OS 208 is executing on 102; [0025]) that the kernel is to provide network packets received by the kernel ([0017] device loads the binary file, read the section with the offload hints and provide the offloads to NIC 132, which further provides metadata to ebpf program for further processing; thus, kernel is notified via the binary file to provide network packets to NIC and ebpf) via a network interface (via API mentioned in [0027] [0032] [0043] via an API; Fig 3 shows that the driver 216 and NIC 132 also works as the interface to 214) to an extended Berkeley Packet Filter (eBPF) program ([0017] [0027] [0029] [0030] [0032]-[0035][0042]-[0044] mention that network packets are offloaded to NIC and the results are returned to ebpf as metadata; Fig 3 shows that the packets are sent to NIC at 308 which then forwards to 214 at 310; 214 is the ebpf [0027]; Fig 3 further shows 208 sent packets 310 also; the metadata appends the packet [0050][0055]; thus the kernel 208 in Fig 3 sends the packets to ebpf program 214 based on the notification at step 302) executing in an eBPF environment of the kernel ([0027] [0032]; [0035] ebof virtual machine of OS 208); receive, by the eBPF program from the kernel, a network packet and cause, by the eBPF program, information derived from the network packet to be copied to an buffer ([0030] – forwarding the packet to a device or interface; [0045] forward packet to a queue)
About the limitations “camera network packet originating from a camera”, Waskiewicz et al teach that device includes camera ([0023]). Since devices are connected via network as shown in Fig 1, device 102 can receive the network packets originating from camera of another device 102. Therefore, Waskiewicz et al teach the limitations “receiving camera network packet originating from a camera”.
Waskiewicz et al does not explicitly teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device.
Wengrovitz et al teach the following limitations:
information derived from the packet to be copied to an image buffer of a display device driver for presentation on a display device (Fig 6, Fig 8 and [0011]; memory Fig 4 stores the driver for outputting display)
It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to provide an image buffer of the display device driver of a display, so that the system can display the camera outputs for the users. As mentioned in Waskiewicz et al, device can have a camera. Thus, the camera images can be sent as the network packets to the other device so that the user of the other device can view the images of the camera of another device. That is particularly useful for surveillance camera system where one user remotely monitors the camera images taken by the sensors.
For claim 16, Waskiewicz et al teach operating system includes kernel and ebpf virtual machine ([0032][0041]). The ebpf is loaded later ([0032]) by OS. Thus, kernel and virtual machines are in different memory locations. Fig 2 shows the operating system and the ebpf program executing on VM. Although not mentioned, it is understood that RAM loads the OS kernel and VM as it is typical to load the OS and VM in RAM. [0032] mentions that kernel interacts with ebpf 214. Thus, kernel is provided with the information of the location of ebpf program. Waskiewicz et al does not explicitly mention about the bootloader. To load the OS/bytecode version of the ebpf. These operations are well known in the art. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use a bootloader to load OS and bytecode version of ebpf, since that provides the streamlined booting of the system. \
For claim 17, Waskiewicz et al teach receiving metadata by the ebpf ([0050][0055]. The metadata includes hash. Thus, the metadata is an encoded packet. The eBPF program decapsulate the packet and forward to a queue ([0029]-0030] [0038] and [0045]). Thus, after decoding, the packet data is forwarded to queue.
For claim 18, Fig 2 Waskiewicz et al mention that 214 ebpf is the packet processing program and Fig 3 shows OS is forwarding to program 214. Fig 6 608 shows the execution of VM. [0030] mentions packet processing by 214. Thus, eBPF program can invoke functions and attached to kernel network packet tracepoint.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Waskiewicz et al (US Patent Application Publication 2022/0337682) and further in view of Wengrovitz et al (US Patent Application Publication 2012/0075465), further in view of Viswambharan et al (US Patent Application Publication 20230198964).
For claims 7 and 14, cited art Waskiewicz et al, in view of Wengrovitz et al does not mention kernel helper function. Viswambharan et al teach kernel helper function used by the eBPF function call ([0046]). Using the helper function called by the eBPF, the program can call kernel space functions. Therefore, the helper function can be used the eBPF to access the queue and buffer so that eBPF can forward the packets to the buffer. It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use the helper function by the ebpf program 214 of Waskiewicz et al, in view of Wengrovitz et al, since that way kernel space functions are accessible by eBPF 214, which further facilitates the processing.
Allowable Subject Matter
Claims 5-6, 12-13 and 19-20 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.
Response to Arguments
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that Waskiewicz does not teach or suggest that computing device can receive the network packets originating from camera of another device 102.
Examiner disagrees. According to para [0023], camera is a device included in the computing device 102. Fig 1 shows that plural compute device 102 communicates with each other, which is further explained in [0024] – compute device 102 may be configured to transmit and receive data with each other and/or other devices in the system 100 over the network 104. Therefore, compute device 102 receives data from camera device over network 104.
[0023] The computing device 102 may further include one or more peripheral devices 134. The peripheral devices 134 may include any number of additional input/output devices, interface devices, and/or other peripheral devices. For example, in some embodiments, the peripheral devices 134 may include a touch screen, graphics circuitry, a graphical processing unit (GPU) and/or processor graphics, an audio device, a microphone, a camera, a keyboard, a mouse, a network interface, and/or other input/output devices, interface devices, and/or peripheral devices.
[0024] The computing devices 102 may be configured to transmit and receive data with each other and/or other devices of the system 100 over the network 104. The network 104 may be embodied as any number of various wired and/or wireless networks. For example, the network 104 may be embodied as, or otherwise include, a wired or wireless local area network (LAN), and/or a wired or wireless wide area network (WAN). As such, the network 104 may include any number of additional devices, such as additional computers, routers, and switches, to facilitate communications among the devices of the system 100.
The following Figure (modified Fig 1) illustrates this clearly.
\
PNG
media_image1.png
525
481
media_image1.png
Greyscale
Therefore, the compute device 102 is configured to receive camera packets through network (i.e., receiving camera network packet).
Applicant further argues that combining Waskiewicz and Wengrovitz is improper as it would not result in the limitations “causing by the eBPF program, information derived from the camera packet to be copied to an image buffer of a display device driver for presentation on a display device”, since neither of them discloses the feature.
Examiner disagrees. The primary reference Waskiewicz teaches causing, by the eBPF program, information derived from the network packet to be copied to a buffer ([0030] – forwarding the packet to a device or interface; [0045] forward packet to a queue). Waskiewicz does not explicitly mention that the buffer is an image buffer. It is agreed by the applicant that Waskiewicz has camera and touch screen and therefore, is configured to display the camera outputs on the display (remarks, page 12). Therefore, although not explicitly mentioned, Waskiewicz is likely to include an image buffer. The system of Waskiewicz forwards to results by the packet processing program 214 ([0027] 214 is eBPF) to queue/device/interface [0030][0045]), which can be a display ([0023] mentions that touch screen is a device; thus, 214 can process the and forward the packet to the display). As display is usually associated with image buffer and display driver (Wengrovitz Fig 4 shows the driver stored in memory and Fig 6 shows the buffer and Fig 8 shows the operation of driver and buffer), the combination sufficiently teaches the limitations causing by the eBPF program, information derived from the camera packet to be copied to an image buffer of a display device driver for presentation on a display device.
Applicant further argues that one ordinary skill would not be motivated to combine Waskiewicz and Wengrovitz because the references address different problems and PHOSITA would not be motivated to combine them.
Examiner disagrees. As explained above, the primary reference is applicable to processing any network packets including camera packets. Examiner agreed with applicant that Waskiewicz addresses improving the performance of the network packet processing. Many applications, such as remote surveillance cameras, use networking for camera outputs (as mentioned in the motivation statements above). The secondary reference Wengrovitz discloses viewing video streams captured by remote surveillance camera (Fig 1) on a display device via a packet network ([0007][0011] Fig 1; Fig 8). Therefore, with the teaching from Wengrovitz, Waskiewicz can be appropriately configured for the camera packets processing to display in the display device through the image buffer and device driver.
Applicant further mentions that modifying Waskiewicz with Wengrovitz would change the principle of the operation of primary reference Waskiewicz because Waskiewicz contains no disclosure about displaying any content on a display, whereas, Wengrovitz addresses the problem of allowing a user to controllably view video streams from surveillance camera.
Examiner disagreed. Waskiewicz provides camera and touch screen throughout the system with plural computing devices ([0023]-[0024]; agreed by applicant on page 12). Therefore, Waskiewicz can be provided with image buffer and display driver for optimized operation of the display device.
Applicant further argues that there is no motivation to combine the teachings of one reference with another reference that already performs the functions. According to applicant, Waskiewicz has camera and touch screen and Waskiewicz is configured to display the camera outputs to the touch screen and therefore, one would not modify Waskiewicz with the teaching of Wengrovitz for the purpose of modifying a feature that Waskiewicz already has – output imagery from camera to the screen.
Examiner disagrees. Examiner agreed that Waskiewicz has camera and touch screen ([0023][0024]). Therefore, although not mentioned, it is likely that Waskiewicz is configured to display the camera outputs to the screen. However, Waskiewicz does not explicitly mention image buffer, display driver and how to display from camera outputs to the display. With the clear and elaborate teachings form Wengrovitz, One ordinary skill would properly configure Waskiewicz so as to display the camera outputs for the users, particularly for surveillance camera system. Therefore, the secondary reference Wengrovitz is able to provide motivation to the ordinary skill to configure the primary reference Waskiewicz.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 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, Andrew Jung can be reached at 571-270-3779. 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.
/FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175