Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate para. s of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 – 25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Parikh et al. (US Pub. No. 20210132769), hereinafter referred to as Parikh.
Referring to claim 8, Parikh discloses an apparatus comprising:
a universal serial bus (USB) camera (camera 270, Fig. 2);
a controller hub comprising (Lid Controller Hub LCH 260, Fig. 2):
USB host controller circuitry (USB 580, Fig. 5) to interface with the USB camera (a USB module 580 that communicates with the USB module 344 in the SoC 340, Fig. 5);
controller hub USB device controller circuitry (USB 580, Fig. 5) to connect to a USB host controller circuitry of a host system (host module 362, Fig. 5);
USB video class function circuitry (frame router 267 streaming image data from image preprocessor 278 to USB 580, Fig. 2) to provide one or more images from the USB camera to the USB host controller circuitry of the host system (vision module 263 receives images from camera 270, processes them, and forwards them via frame router and USB, Fig. 2); and
vision controller circuitry (vision/imaging module 263, Fig. 2) to process the one or more images from the USB camera (processes image sensor data to enable Wake on Face, Face ID, head orientation detection, and facial landmark detection, para. [0099]).
As to claim 9, Parikh discloses the apparatus of claim 8, wherein the controller hub is to:
receive an instruction from the USB host controller circuitry (controller receives host-initiated command to manage peripherals, USB 580, Fig. 5)
of the host system connected to the controller hub USB device controller circuitry, wherein the instruction indicates that the USB host controller circuitry is to control the USB camera (instruction from host indicates camera control action such as stream start/stop or settings, host module 362 issuing control to USB camera, Fig. 5); and
provide, by the USB video class function circuitry, one or more commands (video class function layer transmits control protocol commands, USB module 394, Fig. 2) from the USB host controller circuitry of the host system to the USB camera (command path through USB connection linking host SoC to LCH USB controller, USB connection 223 between USB module 394 and security/host module 261, Fig. 2).
As to claim 10, Parikh discloses the apparatus of claim 8, wherein the vision controller circuitry is to process raw images from the USB camera (vision/imaging module 263, Fig. 2),
wherein the USB video class function circuitry is to process the raw images from the USB camera before sending corresponding processed images to the USB host controller circuitry of the host system (USB module 394 transmitting via USB connection 223, Fig. 2).
As to claim 11, Parikh discloses the apparatus of claim 8, wherein the USB video class function circuitry is to provide the one or more images from the USB camera to the USB host controller circuitry of the host system at a first frame rate (USB module 394 and USB connection 223, Fig. 2),
wherein the vision controller circuitry is to receive the one or more images from the USB camera at a second frame rate, wherein the second frame rate is less than the first frame rate (vision/imaging module 263, Fig. 2).
As to claim 12, Parikh discloses the apparatus of claim 8, further comprising:
a base comprising a processor (main processing unit 362, Fig. 5); and
a lid connected to the base by one or more hinges, wherein the lid comprises a display, the controller hub, and the USB camera (display 380, LCH 260, and USB camera 270 in lid 301, Fig. 2).
As to claim 13, Parikh discloses a computing device comprising:
a universal serial bus (USB) camera (camera 270, Fig. 2);
a host system comprising USB host controller circuitry (USB 580 in host module 362, Fig. 5);
a controller hub comprising: vision controller circuitry and USB host controller circuitry to interface with the USB camera, wherein the vision controller circuitry and the USB host controller circuitry of the host system are to receive one or more images generated by the USB camera contemporaneously (vision/imaging module 263 processes image data locally on the LCH while USB module 580 in the host system simultaneously receives a copy for host-based processing or display, Fig. 2 and Fig. 5).
As to claim 14, Parikh discloses the computing device of claim 13, wherein the host system comprises a camera ownership policy, wherein the camera ownership policy comprises one or more rules indicating when the host system should control the USB camera (camera access and routing decisions are managed by the security/host module 261, which controls whether the USB camera data is directed to the host or retained by the vision module based on policy rules or device state, Fig. 2).
As to claim 15, Parikh discloses the computing device of claim 13, wherein the controller hub further comprises:
a USB hub connected to the USB host controller circuitry of the host system (USB hub within LCH 260 routing to USB 580, Fig. 2 and 5); and
a USB multiplexer, wherein the USB multiplexer has one input and at least two outputs, wherein a first output of the USB multiplexer is connected to the USB hub and a second output of the USB multiplexer is connected to the vision controller circuitry, wherein the USB camera is connected to the one input of the USB multiplexer (multiplexing data paths between USB camera 270, USB hub, and vision module 263, Fig. 2).
As to claim 16, Parikh discloses the computing device of claim 15, wherein the vision controller circuitry is to:
receive an instruction from the USB host controller circuitry of the host system (USB 580, Fig. 5), wherein the instruction indicates that the USB host controller circuitry of the host system is to control the USB camera; and
control, in response to the instruction, the USB multiplexer to provide input from the USB camera to the first output (camera switching via security/host module 261 and USB module 394, Fig. 2).
As to claim 17, Parikh discloses the computing device of claim 15, wherein the vision controller circuitry is able to control the one output of the USB multiplexer to:
(1) provide the input to the USB multiplexer to only the first output, (2) provide the input to the USB multiplexer to only the second output, or (3) provide the input to the USB multiplexer to both the first output and the second output (multiplexer routing logic between camera 270, USB 394, and vision module 263, Fig. 2).
As to claim 18, Parikh discloses the computing device of claim 15, wherein the second output of the USB multiplexer is connected to the vision controller circuitry through the USB host controller circuitry of the controller hub (data path through USB 394 to vision/imaging module 263, Fig. 2).
As to claim 19, Parikh discloses the computing device of claim 15, wherein the USB host controller circuitry of the host system controls the USB camera through the USB multiplexer (USB 580 controlling camera via USB module 394 and connection 223, Fig. 5 and Fig. 2),
wherein images from the USB camera are provided to the vision controller circuitry through the second output of the USB multiplexer while the USB host controller circuitry of the host system controls the USB camera (camera 270 to vision module 263 through USB 394, Fig. 2).
As to claim 20, Parikh discloses the computing device of claim 15, further comprising:
a base comprising a processor (main processor in base, Fig. 5); and
a lid connected to the base by one or more hinges, wherein the lid comprises a display, the controller hub, and the USB camera (display 380, USB camera 270, and LCH 260 in lid 301, Fig. 2).
As to claim 21, Parikh discloses the computing device of claim 13, wherein the controller hub further comprises:
controller hub USB device controller circuitry to connect to the USB host controller circuitry of the host system (USB module 394 interfacing with USB 580 via USB connection 223, Fig. 2 and 5); and
USB video class function circuitry to provide the one or more images from the USB camera to the USB host controller circuitry of the host system (USB module 394 transmitting to USB 580 via USB connection 223, Fig. 2).
As to claim 22, Parikh discloses the computing device of claim 21, wherein the controller hub is to:
receive an instruction from the USB host controller circuitry of the host system connected to the controller hub USB device controller circuitry, wherein the instruction indicates that the USB host controller circuitry is to control the USB camera (USB 580 issuing instruction over USB connection 223 to USB module 394, Fig. 5 and Fig. 2); and
provide, by the USB video class function circuitry, one or more commands from the USB host controller circuitry of the host system to the USB camera (USB module 394 routing control to camera 270, Fig. 2).
As to claim 23, Parikh discloses the computing device of claim 21, wherein the vision controller circuitry is to process raw images from the USB camera (vision/imaging module 263 receiving from camera 270, Fig. 2),
wherein the USB video class function circuitry is to process the raw images from the USB camera before sending corresponding processed images to the USB host controller circuitry of the host system (USB module 394 outputting processed images via USB connection 223, Fig. 2).
As to claim 24, Parikh discloses the computing device of claim 21, wherein the USB video class function circuitry is to provide the one or more images from the USB camera to the USB host controller circuitry of the host system at a first frame rate (USB module 394 in the LCH transmits high-frame-rate video streams to the host via USB 223, Fig. 2),
wherein the vision controller circuitry is to receive the one or more images from the USB camera at a second frame rate, wherein the second frame rate is less than the first frame rate (vision/imaging module 263 processes a downsampled or selectively filtered version of the video stream for tasks like face detection or gesture recognition, reducing internal processing load, Fig. 2).
As to claim 25, Parikh discloses the computing device of claim 21, further comprising:
a base comprising a processor (host processor in base housing, Fig. 5); and
a lid connected to the base by one or more hinges, wherein the lid comprises a display, the controller hub, and the USB camera (display 380, USB camera 270, and LCH 260 in lid 301, Fig. 2).
Claims 2 - 7 recite the corresponding limitation of claims 13 - 20. Therefore, they are rejected accordingly.
As to claim 1, Parikh discloses an apparatus comprising: a controller hub (lid controller hub, 260, Fig. 2) comprising: vision controller circuitry (vision/imaging module, 263, Fig. 2); a universal serial bus (USB) hub (USB module 394, para. 0095) and a USB multiplexer (multiplexer/selector, MUX/SEL 684, Fig. 6), wherein the USB multiplexer has one input and at least two outputs (selectable routing paths controlled by selection logic, 684, Fig. 6), wherein a first output of the USB multiplexer is connected to the USB hub (USB data path to USB module 394, paras. 0101 - 0103) and a second output of the USB multiplexer is connected to the vision controller circuitry (camera data path to vision/imaging module 263, Fig. 2; Fig. 6).
Response to Arguments
Applicant's arguments filed 12/3/2025 have been fully considered but they are not persuasive.
Examiner’s Response to Applicant’s Arguments
Applicant’s arguments have been fully considered but are not persuasive for the reasons set forth below. The rejection of Claims 1–25 under 35 U.S.C. § 102(a)(1) over Parikh et al. (US 2021/0132769 A1) is maintained.
At the outset, Applicant correctly recites the legal standard for anticipation. However, Applicant’s arguments repeatedly misconstrue the claims, mischaracterize Parikh, and improperly impose extraneous limitations not recited in the claims. When the claims are interpreted under the broadest reasonable interpretation (BRI) consistent with the specification, Parikh discloses each limitation, either expressly or inherently, arranged as claimed.
I. Independent Claim 8
A. “USB Camera” Limitation
Applicant argues that Parikh does not disclose a “USB camera” because camera 270 is shown connected via CSI2 and I2C/I3C interfaces rather than directly via a USB physical connection.
This argument is not persuasive.
Claim 8 does not require that the USB camera be physically connected via a USB cable or that the camera itself natively implements a USB PHY. The claim merely recites “a universal serial bus (USB) camera.” Under the broadest reasonable interpretation, this encompasses a camera logically presented, enumerated, and controlled as a USB device, including through an intermediary controller or bridge that exposes the camera using USB protocols.
Parikh expressly discloses such an architecture. As shown in Fig. 2 and Fig. 5, camera 270 is interfaced with the LCH, and image data is routed through the LCH’s USB infrastructure to the host system. The LCH includes USB controller circuitry (USB 394 / USB 580), which provides the camera’s image data to the host via USB. This configuration is sufficient to constitute a “USB camera” under BRI, as the camera is controlled by USB host controller circuitry and provides image data over a USB path, regardless of the internal sensor interface.
The Federal Circuit has repeatedly held that functional identity controls over physical implementation when claim language does not specify a particular physical interface. Applicant’s attempt to limit “USB camera” to a camera with a native USB sensor interface is an unsupported narrowing of the claim.
Accordingly, the rejection properly identifies camera 270 as meeting the “USB camera” limitation.
II. Independent Claim 13
A. “USB Camera” Argument
Applicant reiterates the same argument regarding the “USB camera” limitation. For the reasons discussed above with respect to claim 8, this argument is not persuasive and is incorporated herein by reference.
B. “Contemporaneously” Receiving Images
Applicant argues that Parikh does not disclose that the vision controller circuitry and the USB host controller circuitry receive images “contemporaneously.”
This argument is also not persuasive.
Claim 13 does not require synchronized clock-level simultaneity or receipt of identical image frames at the same instant. Under BRI, “contemporaneously” reasonably encompasses overlapping or concurrent receipt during system operation, as opposed to mutually exclusive or temporally separated modes.
Parikh expressly discloses that:
The vision/imaging module 263 processes image sensor data locally (para. [0099]); and
Image data is also routed via the USB path to the host system (Figs. 2 and 5).
Nothing in Parikh suggests that these operations are mutually exclusive. To the contrary, Parikh’s LCH architecture is expressly designed to allow local vision processing while concurrently providing image data to the host, thereby reducing latency and enabling advanced features.
Applicant’s argument improperly demands an explicit narrative sentence stating “both receive the same images at the same time.” Anticipation does not require verbatim recitation of claim language. Where the architecture necessarily operates in the claimed manner, the limitation is met.
III. Independent Claim 1 (USB Hub and USB Multiplexer)
Applicant argues that Parikh does not disclose a USB hub and a USB multiplexer within the controller hub and challenges the alleged structural arrangement of those components.
This argument is not persuasive.
Claim 1 does not require that components be labeled using Applicant’s preferred terminology, nor does it require that the USB hub or USB multiplexer be disclosed as discrete blocks bearing those exact names. Rather, claim 1 requires circuitry that performs the recited functions, and anticipation is satisfied where the prior art discloses structures that are functionally and structurally equivalent under the broadest reasonable interpretation.
Parikh expressly discloses such structure. Parikh describes that the lid controller hub (LCH 260) includes USB circuitry configured to route camera image data to the host system via USB, including USB module 394, which provides image data from the LCH to the host over a USB connection (paras. [0101]–[0103]). This circuitry performs the claimed USB hub function of routing image data received from the camera toward USB host controller circuitry of the host system.
In addition, Parikh expressly discloses multiplexer/selector circuitry within the controller hub. As described in para. [0118], a multiplexer/selector block 684 receives image sensor data from the camera and selectively routes that data either (i) through a frame router processing stack for local vision processing, (ii) directly to a CSI2 transmitter for delivery to the SoC image processing module, or (iii) to both destinations. The multiplexer/selector block 684 therefore performs controlled selection and routing of camera data paths under system control logic.
Further, multiplexer/selector block 684 necessarily has one input and at least two outputs, as it receives image sensor data from the camera and selectively provides that data to multiple downstream paths, including internal vision processing circuitry and circuitry that delivers image data to the host system (paras. [0117]–[0118]). This corresponds to the claimed configuration in which a first output of the USB multiplexer is connected to the USB hub (via USB circuitry that forwards image data to the host) and a second output of the USB multiplexer is connected to the vision controller circuitry (via the frame router processing stack and vision/imaging module). Claim 1 does not require that the multiplexer operate exclusively at a USB PHY level, nor does it exclude implementation as part of broader image-data selection logic within the controller hub.
Accordingly, Parikh does not merely imply multiplexing through abstract routing concepts, but expressly discloses selection circuitry (multiplexer/selector block 684) within the controller hub that provides the claimed routing functionality. Applicant’s argument improperly focuses on the absence of identical labels rather than on the presence of disclosed structure performing the claimed functions, which is contrary to established claim construction and anticipation principles.
For these reasons, Parikh discloses the USB hub and USB multiplexer arranged as required by claim 1, and the rejection of claim 1 under 35 U.S.C. § 102(a)(1) is maintained.
IV. Dependent Claim 3
Applicant argues that the Office Action failed to identify vision controller circuitry receiving instructions from the host USB controller.
This argument is not persuasive.
Parikh discloses host-issued control instructions delivered via USB control paths to the LCH, where the security/host module and associated logic manage camera routing and control. The vision controller circuitry operates within this control framework and responds to host-issued commands. The claim does not require that the vision controller circuitry be the exclusive recipient of the instruction, only that it receive and act in response.
Applicant’s argument again attempts to impose an overly narrow, literal interpretation unsupported by the claim language.
V. Dependent Claim 4
Applicant argues that Parikh does not disclose all three routing modes controlled by the vision controller circuitry.
This argument is not persuasive.
Parikh’s disclosed routing logic allows camera data to be:
Routed to the host,
Routed to local vision processing, or
Routed to both,
depending on system state and policy. The presence of selectable routing paths inherently supports these modes. Claim 4 does not require an explicit enumeration of all three modes in a single paragraph of the reference.
Applicant’s argument improperly demands express disclosure of every permutation, which is not required where the architecture necessarily enables them.
VI. Dependent Claims 10 and 11 (Raw Images, Processed Images, Frame Rates)
Applicant argues that Parikh does not disclose raw image processing or differing frame rates.
These arguments are not persuasive.
Parikh discloses:
Image sensor data processing by the vision/imaging module (para. [0099]);
Image preprocessing and routing via frame router and USB modules; and
Different processing paths optimized for different purposes.
It is well understood by those of ordinary skill that local vision tasks (e.g., face detection) commonly operate on downsampled or reduced-frame-rate data, while host video streaming operates at higher frame rates. Parikh’s architecture necessarily supports this distinction. Applicant’s argument improperly dismisses technical inevitability recognized by persons of ordinary skill.
VII. Dependent Claim 14 (Camera Ownership Policy)
Applicant argues that Parikh does not disclose a “camera ownership policy.”
This argument is not persuasive.
Claim 14 does not require a software object explicitly labeled “camera ownership policy.” It requires rules indicating when the host system controls the camera. Parikh discloses that camera access and routing decisions are managed by the security/host module based on system state, privacy, and usage context. These are rules governing control—i.e., a camera ownership policy under BRI.
Applicant again attempts to limit the claim to a specific implementation described in the specification, which is improper.
Amendment recommendation to move this case forward:
In view of the foregoing, the presently pending independent claims are directed primarily to a generic USB-based routing architecture comprising vision circuitry, USB hub functionality, and selection/multiplexing of camera data paths. As presently written, the independent claims recite structural USB architecture and data routing arrangements that are broadly implemented in conventional camera subsystems and are disclosed in Parikh. The claims do not presently require, at the independent level, a particularized camera ownership abstraction, rule-based transfer of control, or policy-driven dynamic allocation of camera control between the controller hub and the host system. To the extent Applicant views such ownership-based control logic as the inventive aspect of the disclosure, amendment of the independent claims to more clearly and affirmatively recite that concept may assist in advancing prosecution.
In summary:
Applicant’s arguments rely on:
Improper narrowing of claim terms,
Demands for explicit textual disclosure where functional disclosure suffices, and
Mischaracterization of Parikh’s architecture.
When the claims are given their broadest reasonable interpretation, Parikh discloses each limitation of Claims 1–25, arranged as claimed. Accordingly, the rejection under 35 U.S.C. § 102(a)(1) is maintained.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUANITO C BORROMEO whose telephone number is (571)270-1720. The examiner can normally be reached on Monday - Friday 9 - 5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Henry Tsai can be reached on 5712724176. 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.
/J.C.B/ Assistant Examiner, Art Unit 2184
/HENRY TSAI/ Supervisory Patent Examiner, Art Unit 2184