DETAILED ACTION
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 office action is in response to Applicant’s communication filed on 04/30/2026. Claims 1-12,14-26 have been examined. Claims 13, 27 – 32 are cancelled.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 04/30/2026 The submission are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 10-12 filed on 04/30/2026, with respect to the rejection of claims 1,18 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Roberts.
Applicant’s arguments, see Remarks – Pages 10-12 filed on 04/30/2026, with respect to the rejection of claim 9 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Jorasch further in view of Roberts.
With regards to claim objection, Applicant’s amendment overcomes the objection. Therefore, the objection is withdrawn.
With regards to 112 2nd rejection, Applicant’s amendment overcomes the rejection. Therefore, the rejection is withdrawn.
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.
Claims 1-4,7,8,18-23 are rejected under 35 U.S.C. 103 as being unpatentable over Melkote Krishnaprasad et al. Publication No.US 2019/0333263 A1 (Melkote hereinafter) in view of Roberts et al. Publication No. US 2014/0240122 A1 ( Roberts hereinafter)
Regarding claim 1,
Melkote teaches a method comprising:
communicatively coupling a wearable device with a companion device (Fig.2, ¶0003 &¶ 0005 -Split-rendered systems may include at least one host device and at least one client device that communicate over a network, at least one of the client devices may comprise a wearable display device);
receiving, by the companion device from the wearable device, the data received from a peripheral device of wearable device, the data being received within an [..] operation of the companion device and being stored as a representation of the peripheral device and processing the data into processed data [..] (¶ 0006 - a host device renders an image based on the last head pose received from a head tracker of the wearable display device – Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -host device 10 may generate image content information for rendering a frame. For example, host device 10 may generate a compressed video and audio buffer using head pose data indicated by the sensor and/or actuator data);
sending, by the companion device, the processed data to the wearable device (Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -a user may have moved the wearable display device 16 such that the head pose has changed during the time for wearable display device 16 to transmit the eye pose data, for host device 10 to generate the compressed rendered video and audio buffers, and to transmit the compressed rendered video and audio buffers. To account for the change in head pose, wearable display device may perform time and/or space warping to correct for a rotation of a user's head and to correct for a movement of a user's field of view toward (or away from) an object in a scene);
receiving, by the wearable device, the processed data and utilizing the processed data to complete a computing process ( ¶ 0041 -user may have moved the wearable display device 16 such that the head pose has changed during the time for wearable display device 16 to transmit the eye pose data, for host device 10 to generate the compressed rendered video and audio buffers, and to transmit the compressed rendered video and audio buffers. To account for the change in head pose, wearable display device 16 may perform time and/or space warping to correct for a rotation of a user's head and to correct for a movement of a user's field of view toward (or away from) an object in a scene. ¶ 0087 - the display device 16 may receive eye-buffer of a rendered frame and render pose data, such as from the game engine/render side 10. In 508, the display device 16 may receive single depth metadata for a region of interest. The single depth metadata for the ROI may be the single depth approximation z* for the ROI computed from the harmonic mean of the pixel depths within the ROI. In 510, the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays).
However Melkote does not explicitly teach
the data being received within a background operation of the companion device; processing the data into processed data within the background operation
Roberts teaches
data being received within a background operation of the companion device and being stored as a representation of the peripheral device; processing the data into processed data within the background operation (¶ 0080 - an activity monitoring device 400 is configured to upload activity data/metrics to a user device 402 during a synchronization process, which can be a foreground or background synchronization process. The user device 402 in tum is configured to upload the activity data/metrics to a remote server 410 as part of the synchronization process - ¶ 0009 - establishing the wireless connection defines communication between a background executed application on the mobile device and the activity monitoring device – ¶ 0086- The application 530 includes a sync module 532 for handling synchronization operations with the activity monitoring device 500, including receiving activity data/metrics from the activity monitoring device 500. This may occur over the aforementioned wireless connection via the wireless module 524. The application 530 may define a graphical user interface 534 configured to enable the user to comprehend data from the activity monitoring device 500. An activity data processing module is configured to process and analyze activity data/metrics received from the activity monitoring device. This may entail generation of and/or updating of activity metrics – ¶ 0083 - 512.A sync module 504 is configured to handle data synchronization operations, including uploading activity data/metrics from an activity data storage 506 to the mobile device 512. One or more sensors 510 can include any of various environmental or biometric sensors. A sensor data processing module 508 is configured to process data generated by the sensors 510 - Note the data/metrics retrieved from sensor of the wearable device are synchronized and stored in the user device in order to be processed),
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Roberts. The motivation for doing so is to allow the system to improve user experience by processing tasks silently.
Regarding claim 2,
Melkote in view of Roberts teaches
wherein the peripheral device of the wearable device is a first peripheral device and the data is first data, the method further comprising storing, by the companion device, second data obtained from a second peripheral device that is associated with the companion device (Melkote - ¶ 0006 - a host device renders an image based on the last head pose received from a head tracker of the wearable display device – Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -host device 10 may generate image content information for rendering a frame. For example, host device 10 may generate a compressed video and audio buffer using head pose data indicated by the sensor and/or actuator data. ¶ 0045 - wearable display device 16 represents an example wearable display device connected to a host device. The wearable display device may include one or more sensors configured to generate eye pose data indicating which area of a scene the user may be focusing on, head pose data indicating the user's field of view, one or more displays – Roberts – ¶ 0080, ¶ 0083, ¶ 0035, Claim 28).
Regarding claim 3,
Melkote further teaches
wherein the data is inertial measurement unit (IMU) data (¶ 0006 - correcting for camera translation and rotation (e.g., moving the wearable display device towards or away from a virtual object) from a position of the camera used to render a frame to a position of the camera when the rendered frame is displayed to the user on the wearable display device. When a host device renders an image based on the last head pose received from a head tracker of the wearable display device – ¶ 0067 - A head tracker 305 on the display side 16 may generate render pose 304 to indicate the user's field of view. The head tracker 305 may be a sensor, actuator, or other devices that may detect the orientation and position of the head of the user in 6 DOF- See ¶ 0071, ¶ 0087).
the computing process is a head pose operation (¶ 0012 - The method includes transmitting head tracking information of a user. The method also includes receiving a rendered frame and metadata. The rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame. The method further includes warping the rendered frame using the metadata and display pose information - ¶ 0026 -client device may first fully render a frame based on the received content, where the rendered frame is based on earlier head pose, and then the client device may perform an Asynchronous Time Warp (ATW) that corrects for a rotation of a user's head) , and
completing the computing process by the wearable device includes using a result of the head pose operation (¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may
transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Regarding claim 4,
Melkote further teaches
wherein the data is image data, the computing process is a head pose operation, and completing the computing process by the wearable device includes using a result of the head pose operation (¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame - ¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Regarding claim 7,
Melkote further teaches
wherein the wearable device is smart glasses (¶ 0039 - wearable display device 16 may comprise a HMD device formed as glasses that include display screens in one or more of the eye lenses, and also include a nose bridge and temple arms to be worn on a user's – ¶ 0004 - as wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PD As), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs)).
Regarding claim 8,
Melkote further teaches
wherein the companion device is at least one of another wearable device, a mobile device, a smart phone, a tablet, a server, and a device including a processor and an operating system (¶ 0004 - wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PDAs), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs) – See ¶ 0099 – ¶ 0100).
Regarding claim 18,
Melkote teaches a method comprising:
communicatively coupling a wearable device with a companion device(Fig.2, ¶ 0003 &¶ 0005 -Split-rendered systems may include at least one host device and at least one client device that communicate over a network, at least one of the client devices may comprise a wearable display device);
storing, by the companion device, data associated with a peripheral device of the wearable device within [..] an operation of the companion device as a representation of the peripheral device ( ¶ 087- . the display device 16 may receive eye-buffer of a rendered frame and render pose data, such as from the game engine/render side 10. In 508, the display device 16 may receive single depth metadata for a region of interest. The single depth metadata for the ROI may be the single depth approximation z* for the ROI computed from the harmonic mean of the pixel depths within the ROI – ¶ 0096 - the game engine/render side 10 may generate a rendered frame using the render pose data. the game engine/render side 10 may encode and transmit the encoded rendered frame to the display side 16 – ¶ 0071 - module 311 on the display side 16 may perform warping in APR using the single depth approximation z* 314, the eye buffer frame and render pose information 308 received from the game engine/render side 10, and the display pose 306 received from the head tracker 305, ¶ 0100, Claim 16, a memory storing processor readable code to receive a rendered frame and metadata -See Claim 29), including:
generating, within [..] the companion device, a result associated with a completion of a computing process by the companion device, the computing process is configured to use the data; and communicating, by the companion device to the wearable device, the result associated with the completion of the computing process (¶ 0041 -user may have moved the wearable display device 16 such that the head pose has changed during the time for wearable display device 16 to transmit the eye pose data, for host device 10 to generate the compressed rendered video and audio buffers, and to transmit the compressed rendered video and audio buffers. To account for the change in head pose, wearable display device 16 may perform time and/or space warping to correct for a rotation of a user's head and to correct for a movement of a user's field of view toward (or away from) an object in a scene. ¶ 0087 - the display device 16 may receive eye-buffer of a rendered frame and render pose data, such as from the game engine/render side 10. In 508, the display device 16 may receive single depth metadata for a region of interest. The single depth metadata for the ROI may be the single depth approximation z* for the ROI computed from the harmonic mean of the pixel depths within the ROI. In 510, the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays).
However Melkote does not explicitly teach
storing by the companion device , data associated with peripheral device of the wearable device within a background operation of the companion device and generating within the background operation of the companion device a result
Roberts teaches
storing by the companion device , data associated with peripheral device of the wearable device within a background operation of the companion device as a representation of the peripheral device and generating within the background operation of the companion device a result (¶ 0080 - an activity monitoring device 400 is configured to upload activity data/metrics to a user device 402 during a synchronization process, which can be a foreground or background synchronization process. The user device 402 in tum is configured to upload the activity data/metrics to a remote server 410 as part of the synchronization process - ¶ 0009 - establishing the wireless connection defines communication between a background executed application on the mobile device and the activity monitoring device – ¶ 0086- The application 530 includes a sync module 532 for handling synchronization operations with the activity monitoring device 500, including receiving activity data/metrics from the activity monitoring device 500. This may occur over the aforementioned wireless connection via the wireless module 524. The application 530 may define a graphical user interface 534 configured to enable the user to comprehend data from the activity monitoring device 500. An activity data processing module is configured to process and analyze activity data/metrics received from the activity monitoring device. This may entail generation of and/or updating of activity metrics – ¶ 0083 - 512.A sync module 504 is configured to handle data synchronization operations, including uploading activity data/metrics from an activity data storage 506 to the mobile device 512. One or more sensors 510 can include any of various environmental or biometric sensors. A sensor data processing module 508 is configured to process data generated by the sensors 510 - Note the data/metrics retrieved from sensor of the wearable device are synchronized and stored in the user device in order to be processed),
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Roberts. The motivation for doing so is to allow the system to improve user experience by processing tasks silently.
Regarding claim 19,
Melkote further teaches
wherein the wearable device is smart glasses (¶ 0039 - wearable display device 16 may comprise a HMD device formed as glasses that include display screens in one or more of the eye lenses, and also include a nose bridge and temple arms to be worn on a user's – ¶ 0004 - as wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PD As), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs)).
Regarding claim 20.
Melkote further teaches
wherein the companion device is at least one of another wearable device, a mobile device, a smart phone, a tablet, a server, and a device including a processor and an operating system (¶ 0004 - wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PD As), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs) – See ¶ 0099 – ¶ 0100).
Regarding claim 21,
Melkote in view of Roberts teaches
wherein the peripheral device of the wearable device is a first peripheral device and the data is first data, the method further comprising storing, by the companion device, data obtained from a second peripheral device as second data the second peripheral device being associated with the companion device, the storing of the second data includes communicating the second data from the second peripheral device to the companion device. (Melkote - ¶ 0006 - a host device renders an image based on the last head pose received from a head tracker of the wearable display device – Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -host device 10 may generate image content information for rendering a frame. For example, host device 10 may generate a compressed video and audio buffer using head pose data indicated by the sensor and/or actuator data. ¶ 0045 - wearable display device 16 represents an example wearable display device connected to a host device. The wearable display device may include one or more sensors configured to generate eye pose data indicating which area of a scene the user may be focusing on, head pose data indicating the user's field of view, one or more displays – Roberts – ¶ 0080, ¶ 0083, ¶ 0035, Claim 28).
Regarding claim 22.
Melkote further teaches
wherein the data is inertial measurement unit (IMU) data (¶ 0006 - correcting for camera translation and rotation (e.g., moving the wearable display device towards or away from a virtual object) from a position of the camera used to render a frame to a position of the camera when the rendered frame is displayed to the user on the wearable display device. When a host device renders an image based on the last head pose received from a head tracker of the wearable display device – ¶ 0067 - A head tracker 305 on the display side 16 may generate render pose 304 to indicate the user's field of view. The head tracker 305 may be a sensor, actuator, or other devices that may detect the orientation and position of the head of the user in 6 DOF- See ¶ 0071, ¶ 0087);
the computing process is a head pose operation (¶ 0012 - The method includes transmitting head tracking information of a user. The method also includes receiving a rendered frame and metadata. The rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame. The method further includes warping the rendered frame using the metadata and display pose information - ¶ 0026 -client device may first fully render a frame based on the received content, where the rendered frame is based on earlier head pose, and then the client device may perform an Asynchronous Time Warp (ATW) that corrects for a rotation of a user's head) , and
completing the computing process by the wearable device includes using a result of the head pose operation (¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may
transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Regarding claim 23.
Melkote further teaches
wherein the data is image data, the computing process is a head pose operation, and completing the computing process by the wearable device includes using a result of the head pose operation (¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame - ¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Claims 5,24 are rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Roberts further in view of Pusch et al. Patent No. US 11,450,073 B1 ( Pusch hereinafter).
Regarding claim 5,
Melkote further teaches
wherein the data is image data, the computing process is an eye [..]operation, and completing the computing process by the wearable device includes using a result of the eye [..] operation ((¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame – ¶ 0007 - The region of interest may be determined based on eye tracking or content information. For example, a host device of a split-rendered system may generate a single depth plane for a region of interest of a scene to emphasize contribution from the region of interest. The value and parameters for the single depth plane may be determined based on eye-tracking information – Claim 10 & 11 - transmitting head tracking information of a user; receiving a rendered frame and metadata, wherein the rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame -transmitting eye tracking information of the user, wherein the eye tracking information is used to determine the ROI – See Also ¶ 0009, ¶ 0087, ¶ 0089, ¶ 009).
However, Melkote does not explicitly teach that the eye operation is eye gaze position operation.
Pusch teaches
eye gaze position operation (Col.7, lines 1-5 - the local participant computing device 130 performs certain local computational operations with respect to the received sensor/camera/microphone data prior to sending the raw data and/or local processed output (e.g., a determined heart rate, a determined positional gaze, etc.) – Col.15, lines 1-10 - the local computing device determines from the captured video or eye tracking output in whole or in part, for example using tracking software, eye/gaze position data and only transmits said eye/gaze position data to the computing system (e.g., via access to shared networked storage, sent via a data network, etc.) Col.56, lines 18 -40 - an alert/notification from the client software program 216 of the eye/gaze tracking camera 100 pairing and establishes a virtual data communication path between the eye/gaze tracking camera 100 and the master server 200 enabling the master server software program 205 to receive tracking camera 100 output. In this example embodiment, the master server software program 205 receives raw/unprocessed video output. the tracking camera 100 video output is mirrored to client computing device 211 and the master server computing device 220 in order to reduce and/or eliminate display latencies. )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Pusch. The motivation for doing so is to allow the system to reduce and/or eliminate display latencies (Pusch – Col. 56, lines 35-40).
Regarding claim 24.
Melkote further teaches
wherein the data is image data, the computing process is an eye [..] operation, and completing the computing process by the wearable device includes using a result of the eye [..] operation ((¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame – ¶ 0007 - The region of interest may be determined based on eye tracking or content information. For example, a host device of a split-rendered system may generate a single depth plane for a region of interest of a scene to emphasize contribution from the region of interest. The value and parameters for the single depth plane may be determined based on eye-tracking information – Claim 10 & 11 - transmitting head tracking information of a user; receiving a rendered frame and metadata, wherein the rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame -transmitting eye tracking information of the user, wherein the eye tracking information is used to determine the ROI – See Also ¶ 0009, ¶ 0087, ¶ 0089, ¶ 009).
However, Melkote does not explicitly teach that the eye operation is eye gaze position operation.
Pusch teaches
eye gaze position operation (Col.7, lines 1-5 - . the local participant computing device 130 performs certain local computational operations with respect to the received sensor/camera/microphone data prior to sending the raw data and/or local processed output (e.g., a determined heart rate, a determined positional gaze, etc.) – Col.15, lines 1-10 - the local computing device determines from the captured video or eye tracking output in whole or in part, for example using tracking software, eye/gaze position data and only transmits said eye/gaze position data to the computing system (e.g., via access to shared networked storage, sent via a data network, etc.) Col.56, lines 18 -40 - an alert/notification from the client software program 216 of the eye/gaze tracking camera 100 pairing and establishes a virtual data communication path between the eye/gaze tracking camera 100 and the master server 200 enabling the master server software program 205 to receive tracking camera 100 output. In this example embodiment, the master server software program 205 receives raw/unprocessed video output. the tracking camera 100 video output is mirrored to client computing device 211 and the master server computing device 220 in order to reduce and/or eliminate display latencies. )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Pusch. The motivation for doing so is to allow the system to reduce and/or eliminate display latencies (Pusch – Col. 56, lines 35-40).
Claims 6,25 are rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Robert further in view of Boulanger et al. Publication No. US 2020/0394456 A1 ( Boulanger hereinafter)
Regarding claim 6,
Melkote further teaches
wherein the wearable device includes a first interface, the companion device includes a second interface communicatively coupled to the first interface, and storing the data associated with a peripheral device includes communicating the data between the first interface and the second interface (Fig.2 – shows that the wearable display device 15 includes wireless controller and connection processor and host device (companion device) include wireless controller and connection processor – ¶ 0089 - the game engine/render side may transmit the eye-buffer of rendered frame and the render pose data to the display side 16 – ¶ 0096 - the game engine/render side 10 may encode and transmit the encoded rendered frame to the display side 16 – Claim 24).
However, Melkote does not explicitly teach that the first and second interfaces are first and second sockets.
Boulanger teaches
a wearable device includes a first socket, the companion device includes a second socket communicatively coupled to the first socket, and storing the data associated with a peripheral device includes communicating the data between the first socket and the second socket (¶ 0171 - The client data communications endpoint may implement a socket interface, such as local UNIX domain sockets or TCP sockets or, in at least some embodiments, a hybrid socket interface that allows for both local UNIX domain sockets and/or TCP sockets in a single interface – ¶ 0172 - The host data communications endpoint may implement a corresponding socket interface, enabling sockets opened by an application program 724 or proxy service 726 of wearable computing device 710 to have endpoints on wearable computing device 710 and host computing device – ¶ 0162 - servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Boulanger. The motivation for doing so is to allow applications to run across different machines and handle many simultaneous connections.
Regarding claim 25.
Melkote further teaches
wherein the wearable device includes a first interface, the companion device includes a second interface communicatively coupled to the first interface, and storing the data associated with a peripheral device includes communicating the data between the first interface and the second interface (Fig.2 – shows that the wearable display device 15 includes wireless controller and connection processor and host device (companion device) include wireless controller and connection processor – ¶ 0089 - the game engine/render side may transmit the eye-buffer of rendered frame and the render pose data to the display side 16 – ¶ 0096 - the game engine/render side 10 may encode and transmit the encoded rendered frame to the display side 16 – Claim 24).
However, Melkote does not explicitly teach that the first and second interfaces are first and second sockets.
Boulanger teaches
a wearable device includes a first socket, the companion device includes a second socket communicatively coupled to the first socket, and storing the data includes communicating the data between the first socket and the second socket (¶ 0171 - The client data communications endpoint may implement a socket interface, such as local UNIX domain sockets or TCP sockets or, in at least some embodiments, a hybrid socket interface that allows for both local UNIX domain sockets and/or TCP sockets in a single interface – ¶ 0172 - The host data communications endpoint may implement a corresponding socket interface, enabling sockets opened by an application program 724 or proxy service 726 of wearable computing device 710 to have endpoints on wearable computing device 710 and host computing device – ¶ 0162 - servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Boulanger. The motivation for doing so is to allow applications to run across different machines and handle many simultaneous connections.
Claims 9-12,14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Jorasch et al. Publication No. US 2021/0342020 A1 ( Jorasch hereinafter) further in view of Roberts
Regarding claim 9,
Melkote teaches a system comprising:
a wearable device including: a device client, a hardware abstraction layer, an operating system abstraction layer, and, the companion device including a runtime environment associated with the wearable device (¶ 0003 - Split-rendered systems may include at least one host device and at least one client device that communicate over a network ( e.g., a wireless network, wired network, etc.). For example, a Wi-Fi Direct (WFD) system includes multiple devices communicating over a Wi-Fi network. The host device acts as a wireless access point and sends image content information, which may include audio video (AV) data, audio data, and/or video data, to one or more client devices using one or more wireless communication standards, e.g., IEEE 802.11. The image content information may be played back at both a display of the host device and displays at each of the client devices, ¶ 0047 - FIG. 2 is a block diagram illustrating host device 10 and wearable display device 16 – ¶ 0048 - host device 10 includes an application processor 30, a wireless controller 36, a connection processor 38, and a multimedia processor);
obtain, by the wearable device, the data from the peripheral device, and communicate, by the wearable device, the data to the companion device (¶ 0006 -a host device renders an image based on the last head pose received from a head tracker of the wearable display device, by the time the image is rendered and available for display to a user on the wearable display device, the user's head pose may have moved - ¶ 0041 - wearable display device 16 outputs sensor and/or actuator data to host device 10. The sensor and/or actuator data may include data from an eye tracker that generates eye pose data indicating which area of a scene the user may be focusing on. The sensor and/or actuator data may include data from a header tracker that generates head pose data including orientation and/or position information of the user's head position for determining a user's field of view – ¶ 0087 - the display side 16 may output representation of eye pose data indicating user's area of focus from the eye tracker. The eye pose data may be used to indicate a region of a rendered frame that the user may be focusing on or is interested in. In 504, the display side 16 may output render pose data from the head tracker);
receive, by the companion device, the data using the runtime environment operation as an [..] operation on the companion device and being stored on the companion device as a representation of the peripheral device; process the data into processed data within the runtime environment [..] (¶ 0006 - a host device renders an image based on the last head pose received from a head tracker of the wearable display device – Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -host device 10 may generate image content information for rendering a frame. For example, host device 10 may generate a compressed video and audio buffer using head pose data indicated by the sensor and/or actuator data) ;
send, by the companion device, the processed data to the wearable device(Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -a user may have moved the wearable display device 16 such that the head pose has changed during the time for wearable display device 16 to transmit the eye pose data, for host device 10 to generate the compressed rendered video and audio buffers, and to transmit the compressed rendered video and audio buffers. To account for the change in head pose, wearable display device may perform time and/or space warping to correct for a rotation of a user's head and to correct for a movement of a user's field of view toward (or away from) an object in a scene);
receive, by the wearable device, the processed data and utilizing the processed data to complete a computing process( ¶ 0041 -user may have moved the wearable display device 16 such that the head pose has changed during the time for wearable display device 16 to transmit the eye pose data, for host device 10 to generate the compressed rendered video and audio buffers, and to transmit the compressed rendered video and audio buffers. To account for the change in head pose, wearable display device 16 may perform time and/or space warping to correct for a rotation of a user's head and to correct for a movement of a user's field of view toward (or away from) an object in a scene. ¶ 0087 - the display device 16 may receive eye-buffer of a rendered frame and render pose data, such as from the game engine/render side 10. In 508, the display device 16 may receive single depth metadata for a region of interest. The single depth metadata for the ROI may be the single depth approximation z* for the ROI computed from the harmonic mean of the pixel depths within the ROI. In 510, the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays).
However, Melkote does not explicitly teach
a device driver , a peripheral device configured to communicate with the wearable device using the at least one peripheral device driver;
the data using a runtime environment as the background operation of the companion device; processing the data into processed data within the runtime operating as background operation on the companion device.
Jorasch teaches
a device driver , a peripheral device configured to communicate with the wearable device using the at least one peripheral device driver (¶ 0095 - The incoming data may be decoded and then passed to a peripheral driver program on the user device 106 b. In various embodiments, different models or types of peripheral devices may require different drivers. Thus, for example, user device 106 b may include a separate driver for each peripheral device with which it is in communication. A driver program for a given peripheral device may be configured to translate unique or proprietary signals from the peripheral device into standard commands or instructions understood by the operating system on the user device 106 b. Thus, for example, a driver may translate signals received from a mouse into a number of pixels of displacement of the mouse pointer. The peripheral device driver may also store a current state of the peripheral device, such as a position of the device (e.g., mouse) or state of depression of one or more buttons. A driver may pass peripheral device states or instructions to the operating system as generated, as needed, as requested, or under any other circumstances. These may then be used to direct progress in a program, application, process, etc.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Jorasch. The motivation for doing so is to allow the system to translate unique or proprietary signals from the peripheral device into standard commands or instructions understood by the operating system on the user device (Jorasch – ¶ 0095).
Roberts teaches
the data using a runtime environment as the background operation of the companion device; processing the data into processed data within the runtime operating as background operation on the companion device (¶ 0080 - an activity monitoring device 400 is configured to upload activity data/metrics to a user device 402 during a synchronization process, which can be a foreground or background synchronization process. The user device 402 in tum is configured to upload the activity data/metrics to a remote server 410 as part of the synchronization process - ¶ 0009 - establishing the wireless connection defines communication between a background executed application on the mobile device and the activity monitoring device – ¶ 0086- The application 530 includes a sync module 532 for handling synchronization operations with the activity monitoring device 500, including receiving activity data/metrics from the activity monitoring device 500. This may occur over the aforementioned wireless connection via the wireless module 524. The application 530 may define a graphical user interface 534 configured to enable the user to comprehend data from the activity monitoring device 500. An activity data processing module is configured to process and analyze activity data/metrics received from the activity monitoring device. This may entail generation of and/or updating of activity metrics – ¶ 0083 - 512.A sync module 504 is configured to handle data synchronization operations, including uploading activity data/metrics from an activity data storage 506 to the mobile device 512. One or more sensors 510 can include any of various environmental or biometric sensors. A sensor data processing module 508 is configured to process data generated by the sensors 510 - Note the data/metrics retrieved from sensor of the wearable device are synchronized and stored in the user device in order to be processed – Note; the examiner interprets the runtime environment as operating environment of the mobile device that acts as background operation),
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Roberts. The motivation for doing so is to allow the system to improve user experience by processing tasks silently.
Regarding claim 10,
Melkote further teaches
wherein the wearable device is smart glasses (¶ 0039 - wearable display device 16 may comprise a HMD device formed as glasses that include display screens in one or more of the eye lenses, and also include a nose bridge and temple arms to be worn on a user's – ¶ 0004 - as wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PD As), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs)).
Regarding claim 11,
Melkote further teaches
wherein the companion device is at least one of another wearable device, a mobile device, a smart phone, a tablet, a server, and a device including a processor and an operating system (¶ 0004 - wireless devices, one or more of the host device and the client devices may comprise mobile telephones, portable computers with wireless communication cards, personal digital assistants (PD As), portable media players, or other flash memory devices with wireless communication capabilities, including so-called "smart" phones and "smart" pads or tablets, or other types of wireless communication devices (WCDs) – See ¶ 0099 – ¶ 0100).
Regarding claim 12,
Melkote in view of Roberts teaches
wherein the peripheral device of the wearable device is a first peripheral device and the data is first data, the system further configured to store, by the companion device, second data obtained from a second peripheral device that is associated with of the companion device (Melkote - ¶ 0006 - a host device renders an image based on the last head pose received from a head tracker of the wearable display device – Claim 1 - generating the rendered frame based on head tracking information of a user; identifying a region of interest (ROI) of the rendered frame; generating metadata for a warping operation from the ROI; and transmitting the rendered frame and the metadata for a warping operation of the rendered frame – ¶ 0041 -host device 10 may generate image content information for rendering a frame. For example, host device 10 may generate a compressed video and audio buffer using head pose data indicated by the sensor and/or actuator data. ¶ 0045 - wearable display device 16 represents an example wearable display device connected to a host device. The wearable display device may include one or more sensors configured to generate eye pose data indicating which area of a scene the user may be focusing on, head pose data indicating the user's field of view, one or more displays – Roberts – ¶ 0080, ¶ 0083, ¶ 0035, Claim 28).
Regarding claim 14,
Melkote further teaches
wherein the data is inertial measurement unit (IMU) data (¶ 0006 - correcting for camera translation and rotation (e.g., moving the wearable display device towards or away from a virtual object) from a position of the camera used to render a frame to a position of the camera when the rendered frame is displayed to the user on the wearable display device. When a host device renders an image based on the last head pose received from a head tracker of the wearable display device – ¶ 0067 - A head tracker 305 on the display side 16 may generate render pose 304 to indicate the user's field of view. The head tracker 305 may be a sensor, actuator, or other devices that may detect the orientation and position of the head of the user in 6 DOF- See ¶ 0071, ¶ 0087);
the computing process is a head pose operation (¶ 0012 - The method includes transmitting head tracking information of a user. The method also includes receiving a rendered frame and metadata. The rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame. The method further includes warping the rendered frame using the metadata and display pose information - ¶ 0026 -client device may first fully render a frame based on the received content, where the rendered frame is based on earlier head pose, and then the client device may perform an Asynchronous Time Warp (ATW) that corrects for a rotation of a user's head) , and
completing the computing process by the wearable device includes using a result of the head pose operation (¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Regarding claim 15,
Melkote further teaches
wherein the data is image data, the computing process is a head pose operation, and completing the computing process by the wearable device includes using a result generated based on the head pose operation. (¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame - ¶ 0087 -the display side 16 may determine or receive the display pose data from the head tracker. In 512, the display side 16 may modify one or more pixel values of the eye-buffer of the rendered frame using the single depth metadata and display pose data to generate warped rendered frame. In 514, the display device 16 may output the warped rendered frame for display at one or more displays – ¶ 0092 -the game engine/render side 10 may transmit the eye-buffer of rendered frame and the render pose data to the display side 16. In 714, the game engine/ render side 10 may transmit the single depth metadata for the ROI to the display side 16 for the display side 16 to perform the APR warping operation of the eye-buffer using the single depth metadata – See Also Claim 14).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Jorasch further in view of Roberts further in view of Pusch
Regarding claim 16,
Melkote further teaches
wherein the data is image data, the computing process is an eye [..] operation, and completing the computing process by the wearable device includes using a result generated based on the eye [..] operation (¶ 0002 - The disclosure relates to processing of image content information and, more particularly, post-processing of image content information for output to a display - ¶ 0046 - The rendered frame may include an eye-buffer representing the image content of the scene in the rendered frame, and a Z-buffer representing the depth pixels of the scene in the rendered frame – ¶ 0007 - The region of interest may be determined based on eye tracking or content information. For example, a host device of a split-rendered system may generate a single depth plane for a region of interest of a scene to emphasize contribution from the region of interest. The value and parameters for the single depth plane may be determined based on eye-tracking information – Claim 10 & 11 - transmitting head tracking information of a user; receiving a rendered frame and metadata, wherein the rendered frame is based on the head tracking information and the metadata is based on a region of interest (ROI) of the rendered frame -transmitting eye tracking information of the user, wherein the eye tracking information is used to determine the ROI – See Also ¶ 0009, ¶ 0087, ¶ 0089, ¶ 009).
However, Melkote does not explicitly teach that the eye operation is eye gaze position operation.
Pusch teaches
eye gaze position operation (Col.7, lines 1-5 - . the local participant computing device 130 performs certain local computational operations with respect to the received sensor/camera/microphone data prior to sending the raw data and/or local processed output (e.g., a determined heart rate, a determined positional gaze, etc.) – Col.15, lines 1-10 - the local computing device determines from the captured video or eye tracking output in whole or in part, for example using tracking software, eye/gaze position data and only transmits said eye/gaze position data to the computing system (e.g., via access to shared networked storage, sent via a data network, etc.) Col.56, lines 18 -40 - an alert/notification from the client software program 216 of the eye/gaze tracking camera 100 pairing and establishes a virtual data communication path between the eye/gaze tracking camera 100 and the master server 200 enabling the master server software program 205 to receive tracking camera 100 output. In this example embodiment, the master server software program 205 receives raw/unprocessed video output. the tracking camera 100 video output is mirrored to client computing device 211 and the master server computing device 220 in order to reduce and/or eliminate display latencies. )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Pusch. The motivation for doing so is to allow the system to reduce and/or eliminate display latencies (Pusch – Col. 56, lines 35-40).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Jorasch further in view of Robert further in view of Boulanger
Regarding claim 17,
Melkote further teaches
wherein the wearable device includes a first interface, the companion device includes a second interface communicatively coupled to the first interface, and storing the data includes communicating the data between the first interface and the second interface (Fig.2 – shows that the wearable display device 15 includes wireless controller and connection processor and host device (companion device) include wireless controller and connection processor – ¶ 0089 - the game engine/render side may transmit the eye-buffer of rendered frame and the render pose data to the display side 16 – ¶ 0096 - the game engine/render side 10 may encode and transmit the encoded rendered frame to the display side 16 – Claim 24).
However, Melkote does not explicitly teach that the first and second interfaces are first and second sockets.
Boulanger teaches
a wearable device includes a first socket, the companion device includes a second socket communicatively coupled to the first socket, and storing the data associated with a peripheral device includes communicating the peripheral data between the first socket and the second socket (¶ 0171 - The client data communications endpoint may implement a socket interface, such as local UNIX domain sockets or TCP sockets or, in at least some embodiments, a hybrid socket interface that allows for both local UNIX domain sockets and/or TCP sockets in a single interface – ¶ 0172 - The host data communications endpoint may implement a corresponding socket interface, enabling sockets opened by an application program 724 or proxy service 726 of wearable computing device 710 to have endpoints on wearable computing device 710 and host computing device – ¶ 0162 - servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote to include the teachings of Boulanger. The motivation for doing so is to allow applications to run across different machines and handle many simultaneous connections.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Melkote in view of Roberts further in view of O’Hare et al. Publication No. US 2022/0188165 A1 (O’Hare hereinafter)
Regarding claim 26.
Melkote in view of Robert teaches
wherein the companion device includes a [..] runtime environment operating within the background operation, and the storing of the data associated with the peripheral device is included in the [..]runtime environment (Roberts - ¶ 0080, ¶ 0083, ¶ 0086, ¶ 009).
However, Melkote in view of Roberts does not explicitly teach that the runtime environment is a virtual runtime environment.
However, O’ Hare teaches
a virtual runtime environment (¶ 0018 - The IoT device 106 may execute the computing task 104 and return 112 the results 114 to the mobile device 102. The IoT device 106 may include a Java virtual machine (NM) 116 to execute the computing task 104 outsourced 110 from the mobile device – ¶ 0028 -a user of the proximate smart phone 212 may have enabled the device to accept workloads from nearby devices. This may be done in exchange for later processing of offloading computing workloads by the user of the proximate smart phone 212 – ¶ 0035 - The method 400 begins when a user device operating system (OS) 402 polls 404 sensors 406 for new data. The sensor data 408 is returned to the user device OS 402, which may then store 410 the sensor data 408 in a device storage 412. A device application 414 may then read 416 data 418 from the device storage 412 – ¶ 0040 -The OCP stack 422 then obtains 444 the data and code from the device application 414. The data and code from the device application 414 are then sent to the OCP enabled IoT device 106 in a message 446. The OCP enabled IoT device 106 completes the computations, and returns a message 448 to the OCP stack 422 with the processed data – ¶ 0062 -The code in the OCP extensions 530 in an offloading OCP enabled device 500 may create an OCP bundle 534, which includes the information required by the processing device to execute the task. The information may include a return IP address, to which the IP task results should be sent. The code for performing the offload task, such as the Java code to be executed on the JVM in the receiving OCP enabled device 500 )
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Melkote in view of Roberts to include the teachings of O’Hare. The motivation for doing so is to allow applications to run flexibly across different hardware.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 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, Oscar A Louie can be reached at (571) 270-1684. 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
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights