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 .
Response to Amendment
This action is in response to the amendment filed on 22th December, 2025. Claims 1-10 have been amended. Applicant’s amendments to the claims have overcome the 35 USC 112(f), 112(b), and 101 rejections previously set forth in the non-final office action mailed August 20th 2025. Regarding the 35 USC 103 rejection previously set forth, the amended claims limitations have been fully considered, but are not persuasive. Claims 1-15 remain rejected in the application.
Response to Arguments
Applicant's arguments filed 22th December, 2025 have been fully considered but they are not persuasive.
Regarding A, Independent claim 1:
As it relates to 1(a), applicant argues that Urbach fails to disclose “personalization”, described as generating unique layers for each user. However, the examiner respectfully disagrees. Urbach ¶0057, “A viewport state data object (VSDO) contains layers of scene information that are generated from an arbitrary reference point in a 3D scene on a remote render device.” and, Urbach; ¶0064, teaches a user on a client system requests that a novel viewport with specific view and spatial transform (unique/personal) be rendered by a remote render device and sent back to the client for display. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 1(b), applicant argues that Urbach fails to disclose establishing per-user connections. However, Urbach is not relied upon for this teaching. Pichaimurthy column 7, lines 10-15 “the concurrent stream engine, generates, in user space, a subsequent individual socket for each connection request received from the plurality of client devices.”). This teaches establishing an active connection with each of the plurality of user devices. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 1(c), applicant argues that Urbach fails to disclose generating unique layers for each user. However, the examiner respectfully disagrees. Urbach; ¶0057 and 0064, describes generating unique layers for each user, as described above. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 2(a), applicant argues that Pichaimurthy fails to disclose “personalization”. However, Pichaimurthy is not relied upon in the combination for that limitation. Urbach, ¶0057 and 0064, teaches “personalization” as described above. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 2(b), applicant argues that Pichaimurthy fails to disclose rendering 3D scenes, generating draw calls, managing 3D instances or producing render textures. However, Pichaimurthy is not relied upon in the combination for that limitation. (Vrcelj ¶0040, “GPUs may process multiple types of data or data packets in a GPU pipeline. For instance, in some aspects, a GPU may process two types of data or data packets, e.g., context register packets and draw call data.”). Urbach; ¶0030, describing 3D viewports are generated on a remote render device) In the combination, this teaches generating draw calls for rendering instances in the 3D scene. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 2(c), applicant argues that Pichaimurthy fails to disclose creating a unique layer for each user. However, Pichaimurthy is not relied upon in the combination for that limitation. Urbach; ¶0064 teaches generating unique layers for each user, as described above. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 3(a), applicant argues that Vrcelj fails to disclose per-user rendering, unique layers, or draw-call filtering across multiple devices. However, Vrcelj is not relied upon solely for the limitation. Urbach; ¶0057 and 0064, teaches generating, rendering, and filtering (¶0060) unique layers for each user and, Vrcelj; ¶0040, teaches draw call data processed in a GPU pipeline. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 3(b), applicant argues that Vrcelj fails to disclose per-user rendering, unique layers, or draw-call filtering across multiple devices. However, Vrcelj is not relied upon solely for the limitation. Urbach; ¶0057 and 0064, teaches generating, rendering, and filtering (¶0060) unique layers for each user and, Vrcelj; ¶0040, teaches draw call data processed in a GPU pipeline. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 3(c), applicant argues that Vrcelj fails to disclose generating draw calls associated with the unique layer generation. However, Vrcelj is not relied upon solely for the limitation. Urbach; ¶0057, 0060, and 0064, teaches generating, rendering, and filtering unique layers for each user and, Vrcelj; ¶0040, teaches draw call data processed in a GPU pipeline. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding Applicant Remarks 4(a)-4(c), applicant argues that Bhat fails to disclose rendering, draw call processing, or “personalization”. However, Bhat is not relied upon for claim 1. For claims 5, 10, and 15, Bhat is relied upon for device information/database teachings. Therefore, this argument is not persuasive and therefore claim 1 stands rejected as further detailed below.
Regarding B, Independent claim 6:
Regarding Applicant Remarks B, applicant argues that claim 6 recites similar limitations to claim 1 and is similarly allowable. However, as claim 1 stands rejected (see above), this argument is not persuasive and therefore claim 6 stands rejected as further detailed below.
In response to applicant’s arguments regarding dependent claims, applicant’s arguments have been fully considered but are not persuasive. Since the rejection for the independent claims 1 and 6 is maintained, rejections for the dependent claims are maintained.
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, 6-9, and 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Julian Michael Urbach (US Patent Application Publication 2016/0171743), hereinafter “Urbach”, Pichaimurthy et al. (US Patent Publication 11063708), hereinafter “Pichaimurthy" and Bojan Vrcelj et al. (US Patent Application Publication 2021/0312701), hereinafter “Vrcelj”.
Regarding Claim 1, Urbach teaches A server for render streaming an environment to a plurality of user devices, wherein the server comprises: one or more processors; a memory storinq executable instructions that, when executed by the said one or more processors, cause the server to: a server comprising one or more processors and a memory (Urbach Fig. 2 ¶0022 “FIG. 2 illustrates an example computing system architecture, which may be used to implement a physical server. In one embodiment, hardware system 200 comprises a processor 202, a cache memory 204, and one or more software applications and drivers directed to the functions described herein.”) storing executable instructions (Urbach; ¶0026, describes software routines comprising instructions stored and copied into memory for execution by a processor.) for streaming to one or more (plurality) clients (Urbach ¶0032 “…to transmit and transcode a simplified representation of the rendered view (e.g., a compressed video stream) to one or more clients.”) via mobile devices, PCs, and other devices (Urbach ¶0016 “Client nodes 82 and 84 may include personal computers or cell phones, as well as other types of mobile devices such as lap top computers, personal digital assistants (PDAs), etc.” Urbach; Fig. 1 ¶0018 “The one or more physical servers 22 are operably connected to computer network 60 via a router 26. The one or more physical servers 22 host functionality that allows users to interact with the virtual world, such as receiving requests from, and transmitting responsive data to, client nodes 82 and 84.”) obtain a 3D scene corresponding to the environment rendering a viewport that is a representation of a scene or environment and describes obtaining the parameters of the scene such as pitch, yaw, and field of view (Urbach 0028 “A viewport is a rendered representation of a virtual scene or environment from a given spatial location in the virtual environment and according to one or more view transform parameters (such as pitch, yaw, and field of view).”) generate a plurality of unique layers corresponding to the plurality of user Examiner interprets “layer” to be a set of objects corresponding to the scene of the environment. Urbach describes viewport state data objects (VSDOs) contain layer of scene information generated from a reference point in the scene (Urbach ¶0057 “A viewport state data object (VSDO) contains layers of scene information that are generated from an arbitrary reference point in a 3D scene on a remote render device.”) from the perspective of the users as described previously (¶0030, the special location and view being unique to the user). Urbach; ¶0064, teaches a user on a client system requests that a novel viewport with specific view and spatial transform be rendered by a remote render device and sent back to the client for display. generate a set of render textures corresponding to each of the plurality of user devices based on the unique draw call sets associated with the respective user devices Examiner interprets “render textures” to refer to visual detail applied to 3D object surfaces.
As discussed above, Urbach teaches rendering a viewport, which represents a virtual scene or environment from a perspective based on position and viewing angle (Urbach ¶0028) and includes texture maps (render textures) (Urbach ¶0028 “Viewports can be rendered by generating a Viewport State Data Object (VSDO), which, in one implementation, comprises a layered cube map, and using a pixel or fragment shader to generate pixel values for the viewport. A cube map is essentially six texture maps stitched into a cube.”) and can allow for novel (unique) viewports for users (Urbach Fig. 3 ¶0064 “ In a particular implementation, a user on a client system 82 or 84 requests, through a network stream to a world state server, that a novel viewport with a specific view and spatial transform is to be rendered by a remote render device, and that the output is to be sent back to the client for display (302).”) stream the corresponding set of rendered textures to the respective user devices (Urbach ¶0032 “the RRD server has the graphics capabilities required to render a 3D viewport of a virtual world, and also has enough bandwidth to transmit and transcode a simplified representation of the rendered view (e.g., a compressed video stream) to one or more clients.”; describes a server able to stream rendered output and streaming the novel (corresponding) set of viewports (including rendered textures as discussed above) to the multiple users (Urbach ¶0065 “In this manner, an RRD server may utilize the facilities of a GPU, for example, to render complex 3-D scenes and stream novel viewports out to multiple clients, which then do not need client-side rendering engines which consume substantial processing resources.”))
However, Urbach does not explicitly disclose establish an active connection with each of the plurality of user devices in response to receiving a corresponding connection establishment request from the plurality of user devices.
Pichaimurthy describes users using a client device to interact (request) with the server (Pichaimurthy column 5, lines 54-56 “…stored and executed by one or more of the processors and memory of 55 a device or server to deliver content.”) and that each user establishes a connection (active) with the server (Pichaimurthy column 7, lines 10-15 “the concurrent stream engine, generates, in user space, a subsequent individual socket for each connection request received from the plurality of client devices.”). This teaches establishing an active connection with each of the plurality of user devices in response to receiving a corresponding connection establishment request form the plurality of user devices.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the connection framework of Urbach to include the method of Pichaimurthy, to establish active connections upon request in order to individually control data streams, which allows for users to select only the streams they wish to view, further customizing user experience.
Urbach, in view of Pichaimurthy, teaches the server for render streaming an environment to a plurality of user devices, but does not explicitly disclose generate a plurality of draw calls for a plurality of instances in the 3D scene.
Vrcelj teaches that a GPU may process multiple types of data in a pipeline, including draw calls (Vrcelj ¶0040, “GPUs may process multiple types of data or data packets in a GPU pipeline. For instance, in some aspects, a GPU may process two types of data or data packets, e.g., context register packets and draw call data.”). In the combination (Urbach; ¶0030, describing 3D viewpoirts are generated on a remote render device) this teaches generating daw calls for rendering instances in the 3D scene. obtain the plurality of generated draw calls corresponding to the 3D scene; filter the plurality of generated draw calls based on the plurality of unique layers to obtain a plurality of unique draw call sets corresponding to the plurality of user devices Urbach teaches re-rendering overlapping elements (filter) based on depth peeling (layers) to obtain novel (unique) viewports (Urbach 0060 “If the VSDO being generated is intended to allow novel viewports to be created from different spatial reference positions (using Render Method 2, below), then the scene is rendered using depth peeling. These additional cube maps (Depth layer sets) also comprise the elements described above, and are generated for each additional depth layer that is required to re-render overlapping elements within the radial clipping plane range of the viewport state date object (defined as the far clipping plane of the camera used to generate the VSDO)”) and Vrcelj teaches draw call data processed in a GPU pipeline (Vrcelj; ¶0040). In the combination this teaches obtaining draw calls corresponding to the 3D scene and filtering those draw calls based on the layer information to obtain corresponding draw call sets for the respective user devices.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to apply and/or modify the server of Urbach, in view of Pichaimurthy, to include the draw calls of Vrcelj as sending draw calls to a GPU is a well-known implementation in graphics rendering and commonly used in rendering scene geometry. The motivation for such a combination would have been to provide the benefit of using established GPU rendering pipeline techniques to efficiently render scene geometry for streamed output.
Claim 6, has similar limitations as of claim(s) 1, therefore it is rejected under the same rationale as claim(s) 1.
Claim 11, has similar limitations as of claim(s) 1, therefore it is rejected under the same rationale as claim(s) 1.
Regarding Claim 2, Urbach, in view of Pichaimurthy and Vrcelj, teaches the server as claimed in claim 1, wherein the executable instructions further cause: receive a first scene update request and a second scene update request from a first user device and a second user device, from the plurality of user devices, respectively, wherein the scene update request is a request to update one or more instances in the 3D scene. As previously discussed, Urbach describes multiple (first and second user) user devices (Urbach ¶0016 and ¶0032, see claim 1) and further teaches as the user(s) navigate the virtual environment, additional client requests are transmitted (update requests) to update the scene based on the changing spatial position and view transforms (instance update) (Urbach ¶0064 “As a given user navigates within the virtual environment, changing the spatial position or view transform parameters, additional client requests may be transmitted to the world state server, which routes the client requests to the RRD node.”).
Urbach further teaches to update a first unique layer and a second unique layer corresponding to the first device and the second device based on the first scene update request and the second scene update request, respectively. Urbach describes modifying or generating new (updating) VSDOs (unique layers) based on the (respective) user requests (first and second users) (Urbach Fig. 3, ¶0065 “As FIG. 3 illustrates, a given RRD accesses a buffer of pending viewport render requests sent by the world state server and either loads existing cached VSDOs and modifies or generates new VSDO(s) that will be required to fulfill the requests of each client (306). In this step for example, an RRD may regenerate or modify a VSDO if the state of one or more objects has changed.”) and update a first viewport and a second viewport corresponding to the first user device and the second user device, based on the updated first unique layer and the updated second unique layer, respectively, as described above the corresponding first and second VSDOs (layers) corresponding to the first and second users, are modified/regenerated (updated) (Urbach ¶0065 “In this step for example, an RRD may regenerate or modify a VSDO if the state of one or more objects has changed.”).
Urbach further teaches generate a first updated set of render textures and a second updated set of render textures based on the updated first set of viewports and the updated second set of viewports, respectively as previously discussed, the VSDOs contain texture maps (Urbach ¶0028) and that the RRD(Remote Render Device) may regenerate/modify (update) a VSDO upon the update request (Urbach ¶0065).
However, although Urbach describes updating layers, render textures, and modifying/regenerating the viewports, Urbach does not explicitly disclose generating draw calls for each update. As previously discussed in claim 1, it would have been obvious to apply Vrcelj’s method of generating draw calls (Vrcelj ¶0040) for rendering a scene as a well-known and conventional method.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to apply and/or modify the server framework of rendering and generation of Urbach, in view of Pichaimurthy of Vrcelj, in further view of Urbach in order to efficiently update scenes and/or render textures, per-user (as taught by Pichaimurthy ) and generate them using draw calls (as taught by Vrcelj) using common rendering practices.
Claim 7, has similar limitations as of claim(s) 2, therefore it is rejected under the same rationale as claim(s) 2.
Claim 12, has similar limitations as of claim(s) 2, therefore it is rejected under the same rationale as claim(s) 2.
Regarding Claim 3, Urbach in view of Pichaimurthy and Vrcelj, teaches the server as claimed in claim 1 wherein the executable instructions further cause: assign a unique audio channel to each of the plurality of user devices upon receiving the connection establishment request from the plurality of user devices that establishes (assigns) a unique connection (channel) to the plurality of user devices upon receiving the connection (establishment) request from the plurality of user devices (Pichaimurthy column 7, lines 10-15 “the concurrent stream engine, generates, in user space, a subsequent individual socket for each connection request received from the plurality of client devices.”) and transmit/receive audio communication of the corresponding user device with the server over the established unique audio channel that the channel may be used to transmit and receive audio (audio channel) with the corresponding user (Pichaimurthy Fig. 5, column 12, lines 10-12 “An audio component of videos and other content displayed on display 512 may be played through speakers of audio equipment 514.” and also Pichaimurthy column 4, lines 18-19 “…may include a microphone configured to receive audio input such as voice commands or speech.”)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further apply and/or modify the server framework of rendering and generation of Urbach, in view of Pichaimurthy and Vrcelj, with the per-user audio channels of Pichaimurthy to provide increased user experience and privacy as is well-known in the art.
Claim 8, has similar limitations as of claim(s) 3, therefore it is rejected under the same rationale as claim(s) 3.
Claim 13, has similar limitations as of claim(s) 3, therefore it is rejected under the same rationale as claim(s) 3.
Regarding claim 4, Urbach, in view of Pichaimurthy and Vrcelj, teaches the server as claimed in claim 1 wherein the executable instructions further cause: assign a unique data channel to each of the plurality of user devices upon receiving the connection establishment request from the plurality of user devices that establishes (assigns) a unique connection (channel) to the plurality of user devices upon receiving the connection (establishment) request from the plurality of user devices (Pichaimurthy column 7, lines 10-15, see claim 3) and further describes to transmit/receive data communication of the corresponding user device with the server over the established unique data channel transmitting video (data) (Pichaimurthy column 9, lines 28-30 “Device 500 may also work in concert with a server, such as server 402 of FIG. 4, in order to live-stream video by, for example, delivering captured content.”) and receiving content/data (Pichaimurthy column 9, lines 28-30 “Each one of device 500 and equipment 501 may receive content and receive data via 50 input/output (hereinafter "I/0") path 502.”)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further apply and/or modify the server framework of rendering and generation of Urbach, in view of Pichaimurthy and Vrcelj, with the per-user data channels of Pichaimurthy to provide increased user experience and privacy as is well-known in the art.
Claim 9, has similar limitations as of claim(s) 4, therefore it is rejected under the same rationale as claim(s) 4.
Claim 14, has similar limitations as of claim(s) 4, therefore it is rejected under the same rationale as claim(s) 4.
Claims 5, 10, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Julian Michael Urbach (US Patent Application Publication 2016/0171743), hereinafter “Urbach”, Pichaimurthy et al. (US Patent Publication 11063708), hereinafter “Pichaimurthy”, Bojan Vrcelj et al. (US Patent Application Publication 2021/0312701), hereinafter “Vrcelj”, and Karthik Venkatesh Bhat (US Patent Application Publication 2022/0376980), hereinafter “Bhat”.
Regarding Claim 5, Urbach, in view of Pichaimurthy and Vrcelj, teaches the server as claimed in claim 1, but does not explicitly disclose wherein the executable instructions further cause the processor to: obtain user device type information from a database, wherein the user device type information comprises information about a device type of each of the plurality of user devices, wherein the device type is one of: a laptop, a smartphone, a desktop, a Virtual Reality (VR) device, a device supporting Augmented Reality (AR), and a device supporting Mixed Reality (MR);
identify, for each of the plurality of user devices, a respective type of the user device based on the obtained user device type information; and
generate, for each of the plurality of user devices, the set of render textures based on the respective unique draw call set and the respective type of the user device.
However, Bhat describes a server (Bhat ¶0085 “The IoT cloud server 102 referred herein may be a server…“) that obtain user device type information from a database, wherein the user device type information comprises information about a device type of each of the plurality of user devices, wherein the device type is one of: a laptop, a smartphone, a desktop, a Virtual Reality (VR) device, a device supporting Augmented Reality (AR), and a device supporting Mixed Reality (MR). Bhat describes a database that obtains, stores, and manages device information (Bhat ¶0085 “The IoT cloud server 102 referred herein may be a server that obtains, stores, and manages device information mappings, capabilities, manufacturer provided information, and location information of each of the plurality of devices 104 a-104 n present in an IoT environment.”) including the device type (Bhat ¶0085 “ The device information may include information such as, but is not limited to, an identification value (for example, device ID information) of each of the plurality of devices 104 a-104 n, a device type of each of the plurality of devices 104 a-104 n, and so on.”) and the device type is at least one of: a laptop, computer, or smart phone (Bhat ¶0087 “Examples of the plurality of devices 104 a-104 n may be, but are not limited to, a smart phone, a mobile phone, a video phone, a computer, a tablet personal computer (PC), a netbook computer, a laptop, a wearable device, a vehicle infotainment system, a workstation, a server, a personal digital assistant (PDA), a smart plug, a portable multimedia player (PMP), a moving picture experts group (MPEG-1 or MPEG-2) audio layer 3 (MP3) layer, a mobile medical device, a light, a voice assistant device, a camera, a home appliance, one or more sensors, and so on.”). Bhat also discloses to identify, for each of the plurality of user devices, a respective type of the user device based on the obtained user device type information describing the obtained device information including a device type of one of the previously mentioned (Bhat ¶0087 above). Bhat also teaches transmitting commands based on the respective type of the user device the device information including the device type (Bhat ¶0096 “The electronic device 106 also obtains, determines, or generates a control command for controlling each of the plurality of devices 104 a-104 n, by utilizing the device information, the capabilities mappings, the location information, or the like of each device (104 a-104 n).”), but does not explicitly disclose to generate, for each of the plurality of user devices, the set of render textures based on the respective unique draw call set.
However, as previously discussed in claim 1, Urbach, in view of Vrcelj, teaches generating a novel (unique) viewport using texture maps (render textures) (Urbach ¶0028 and 0064, see claim 1) and using draw calls as taught by Vrcelj (¶0040, see claim 1).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to apply and/or modify the server framework of rendering and generation of Urbach, in view of Pichaimurthy of Vrcelj, in further view of Bhat in order to incorporate a database for efficient retrieval of user device information.
Claim 10, has similar limitations as of claim(s) 5, therefore it is rejected under the same rationale as claim(s) 5.
Claim 15, has similar limitations as of claim(s) 5, therefore it is rejected under the same rationale as claim(s) 5.
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 DAN F KALHORI whose telephone number is (571)272-5475. The examiner can normally be reached Mon-Fri 8:30-5:30 ET.
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, DEVONA E FAULK can be reached at (571) 272-7515. 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.
/DAN F KALHORI/Examiner, Art Unit 2618
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights