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 .
Response to Amendment
1. This action is in response to the amendment filed on 3/31/2026. Claims 1, 11, 18 and 36 have been amended. Claims 1-3, 7, 10-11, 17-18, and 26-37 remain rejected in the application. Applicant’s amendment to claim 36 has overcome the objection previously set forth in the Non-Final Office Action mailed 1/7/2026.
Response to Arguments
2. Applicant’s arguments with respect to claim 1, and similarly claims 11 and 18, filed on 12/9/2025, with respect to the rejection under 35 U.S.C. 103 regarding that the prior art does not teach the limitation(s): “the user input selecting either a compute shader process or a graphics shaders process as a three-dimensional rendering process for the three-dimensional image data set” and “processing the three-dimensional image data set on a graphical processing unit (GPU) using the three-dimensional rendering process selected by the user input” have been fully considered, but are moot because of new grounds for rejection. The claims are now disclosed by Westerhoff, Matsumoto, and "Unity Shader Learning 01" (NPL: https://www.cnblogs.com/clf125800/p/17247467.html, March 23, 2023, hereinafter UnityShader23.)
3. Regarding arguments to claims 2-3, 7, 10, 17 and 26-37, they are dependent on independent claims 1, 11, and 18 respectively. Applicant does not argue anything other than independent claim 1, and similarly claims 11 and 18. The limitations in those claims, in conjunction with combination, has previously been established and explained.
Claim Rejections - 35 USC § 103
4. 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.
5. Claims 1-3, 10-11, 17-18, and 28-29, 32-33, and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Westerhoff et al. (US-9904969-B1, hereinafter "Westerhoff") in view of Matsumoto (US-2009/0003668-A1), and further in view of "Unity Shader Learning 01" (NPL: https://www.cnblogs.com/clf125800/p/17247467.html, March 23, 2023, hereinafter "UnityShader23").
6. As per claim 1, Westerhoff discloses: A method comprising:
receiving a three-dimensional image data set for processing on a medical imaging system; (Westerhoff, column 1, lines 14-18, “The invention pertains to digital data processing and, more particularly, by way of example, to the visualization of image data. It has application to areas including medical imaging, atmospheric studies, astrophysics, microscopy, spectroscopy, satellite imaging, and geophysics.” and column 1, lines 38-42, “In medical imaging, for example, Volume Rendering is used to display 3D images from 3D image data sets, where a typical 3D image data set is a large number of 2D slice images acquired by a CT or MRI scanner and stored in a data structure.”)
processing the three-dimensional image data set on a central processing unit (CPU) of the medical imaging system to generate a CPU output [[that includes a volumetric rendering of the three-dimensional image data set;]] (Westerhoff, column 13, lines 57-61, “But, not all render requests need to be executed on the GPUs. Depending on resource use and the type of request, it may also be feasible to use one or more CPU cores on one or more CPUs to process a render request, or a combination of CPU and GPU.”)
processing the three-dimensional image data set on a graphical processing unit (GPU) [[based on the three-dimensional rendering parameter]] to generate a GPU output [[that includes a three-dimensional rendering of the three-dimensional image data set; and]] (Westerhoff, column 13, lines 57-61, “But, not all render requests need to be executed on the GPUs. Depending on resource use and the type of request, it may also be feasible to use one or more CPU cores on one or more CPUs to process a render request, or a combination of CPU and GPU.”)
combining the CPU output and the GPU output to generate a rendered three-dimensional medical volume that depicts various tissue densities. (Westerhoff, Fig. 19; column 13, lines 58-61, “Depending on resource use and the type of request, it may also be feasible to use one or more CPU cores on one or more CPUs to process a render request, or a combination of CPU and GPU.” and column 28, lines 22-24, “FIG. 19 depicts an example study where the rules have created two Sets of Images. One Set of Images consists of a series of CT images forming a 3D volume …” and column 15, lines 22-27, “A typical example would be a Computer Tomographic (CT) image that can comprise data values ranging from −1000 to 3000. When reviewing the soft tissue aspects (such as the inner organs), a user can for example choose an initial Data Window of −200 to 200 ...”)
7. Westerhoff doesn't explicitly disclose but Matsumoto discloses: [[processing the three-dimensional image data set on a central processing unit (CPU) of the medical imaging system to generate a CPU output]] that includes a volumetric rendering of the three-dimensional image data set; (Matsumoto, [0051]-[0052], “In the present embodiment, the CPU 7 executes a volume rendered image generating process using the volume data VD to generate a volume rendered image G1 as shown in FIG. 4 ... Since the volume rendered image G1 can be generated using well known methods such as MIP, raycasting and the like, details of this image generation are omitted.”)
sending the volumetric rendering of the three-dimensional image data set to a client device; (Matsumoto, [0045], “The CPU 7 specifies a region of interest Z from the volume data VD obtained from the CT image data from the database 2 and executes image processing to generate a MIP image G2, by executing programs stored in the program storage 11 of the memory 8. That is, in the present embodiment, the CPU 7 (computer 3) functions as an image processing device by executing image processing programs ...” and [0051]-[0052], “In the present embodiment, the CPU 7 executes a volume rendered image generating process using the volume data VD to generate a volume rendered image G1 as shown in FIG. 4 ... Since the volume rendered image G1 can be generated using well known methods such as MIP, raycasting and the like, details of this image generation are omitted.” and [0035], “The image display device 1 is provided with a computer (computer, workstation, personal computer) 3, monitor 4, and input devices such as a keyboard 5 and mouse 6 or the like. The computer 3 is connected to a database 2.”)
receiving, from the client device, a user input responsive to the volumetric rendering of the three-dimensional image data set, the user input [[selecting either a compute shader process or a graphics shaders process as a three-dimensional rendering process for the three-dimensional image data set;]] (Matsumoto, Fig. 11; [0077], “FIG. 11 shows a flowchart of the image processing. The user first operates the keyboard 5 and mouse 6 to display a volume rendered image G1 on the screen 4a of the monitor 4 (step S10: guide curve setting step and reference direction setting step).”)
[[processing the three-dimensional image data set on a graphical processing unit (GPU)]] using the three-dimensional rendering process [[selected]] by the user input to generate a GPU output that includes a three-dimensional rendering of the three-dimensional image data set; and (Matsumoto, Fig. 11; [0052], “Since the volume rendered image G1 can be generated using well known methods such as MIP, raycasting and the like, details of this image generation are omitted.” and [0083], “The CPU 7 then performs MIP processing of the region of interest Z defined by the front specified plane Sf and the rear specified plane Sr (step S50: MIP image generating process), and the GPU performs the post processing of MIP process to generate a MIP image G2 for observing the part of interest 21a within the region of interest Z. The MIP image G2 which includes the part of interest 21a is then displayed together with the volume rendered image G1 on the screen 4a of the monitor 4 (step S60).” and [0077], “FIG. 11 shows a flowchart of the image processing. The user first operates the keyboard 5 and mouse 6 to display a volume rendered image G1 on the screen 4a of the monitor 4 (step S10: guide curve setting step and reference direction setting step).”)
8. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of Westerhoff to include the disclosure of performing a CPU volume rendering, receiving user input parameters regarding the rendering from a client device, and based on those parameters, performing an additional GPU rendering including the CPU volume rendering to generate a rendered three-dimensional medical volume, of Matsumoto. The motivation for this modification could have been to not only provide a method to enhance a typical volume rendering with a combined GPU rendering, but also provide an opportunity for post processing, such as for color, contrast, and brightness correction.
9. Westerhoff in view of Matsumoto doesn't explicitly disclose but UnityShader23 discloses: [[receiving, from the client device, a user input responsive to the volumetric rendering of the three-dimensional image data set, the user input]] selecting either a compute shader process (UnityShader23, See Figure 1 below; ¶ 6, “Compute Shader A compute shader is a program that runs on the GPU, independent of the regular rendering pipeline. It allows the GPU to be used directly as a parallel processor, giving it not only 3D rendering capabilities but also other computational abilities. It is typically used when a large amount of parallel computing is required.”) or a graphics shaders process as a three-dimensional rendering process for the three-dimensional image data set; (UnityShader23, See Figure 1 below; ¶ 3-4, “Standard Surface Shader A standard surface shader is a physically based shading system. It can be understood as a simple simulation of physical phenomena that can achieve the effects of various objects in life, such as stone, wood, glass, plastic, and metal. Unlit Shader It is the simplest shader. Compared with the Standard Surface Shader, it removes the lengthy lighting formulas and shadow calculations, hence the name Unlit, which means no lighting. As such, it consists only of the most basic Vertex Shader and Fragment Shader, making it the most basic and easy to understand.” and ¶ 19, “The world coordinates and normals are processed in the vertex shader and then passed to the subsequent pixel shader.”; Examiner’s note: One of ordinary skill in the art would identify vertex and fragment (pixel) shaders as graphics shaders.)
PNG
media_image1.png
509
923
media_image1.png
Greyscale
Figure 1 (UnityShader23): Screenshot of the Unity application that allows a user to select a shader process from a menu, such as “Standard Surface Shader” (graphics shader) and “Compute Shader.”
[[processing the three-dimensional image data set on a graphical processing unit (GPU) using the three-dimensional rendering process]] selected [[by the user input to generate a GPU output that includes a three-dimensional rendering of the three-dimensional image data set; and]] (See UnityShader23 Figure 1; ¶ 6, ¶ 3-4, and ¶ 19 above.)
10. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of Westerhoff in view of Matsumoto to include the disclosure of giving a user an ability to select either a compute shader process or a graphics shaders process as a three-dimensional rendering process for the three-dimensional image data set, of UnityShader23. The motivation for this modification could have been to provide the user with different ways to view three-dimensional data. Graphics shaders may provide for a quick rendering process while compute shaders may utilize more complex calculations that aid in the rendering process. In some cases, this may provide a user with a choice between better performance versus higher quality or accurate rendering.
11. As per claim 2, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein processing the three-dimensional image data set on the CPU comprises:
confirming that the three-dimensional image data set is compliant with a DICOM standard. (Westerhoff, column 29, lines 46-47, “In an embodiment of the present invention, the rules can normalize DICOM parameters.”)
12. As per claim 3, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein processing the three-dimensional image data set on the CPU comprises:
normalizing the three-dimensional image data set. (Westerhoff, column 29, lines 46-47, “In an embodiment of the present invention, the rules can normalize DICOM parameters.”)
13. As per claim 10, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein the three-dimensional image data set is generated at least by a MRI system or a CAT system. (Westerhoff, column 26, lines 14-19, “The invention pertains to digital data processing and, more particularly, by way of example, to the visualization of image data. Three dimensional (3D) and four dimensional (4D) image data is routinely acquired with CT, MRI, PET, confocal microscopes, 3D ultrasound devices, and other imaging devices.” and column 1, lines 38-42, “In medical imaging, for example, Volume Rendering is used to display 3D images from 3D image data sets, where a typical 3D image data set is a large number of 2D slice images acquired by a CT or MRI scanner and stored in a data structure.”)
14. Claim 11 is similar in scope to claim 1 except for additional limitations that Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: A computer program product residing on a non-transitory computer readable medium having a plurality of instructions stored thereon which, when executed by a processor of a system, cause the system to perform the following operations: (Matsumoto, [0017], “Another aspect of the present invention is a computer program device including a computer readable recording medium encoded with a program for projecting, on a two-dimensional plane, image data of three or more dimensions in a region of interest and generating an image by executing either one of independent processing or distributed processing with at least one computer. The program when executed by the at least one computer performing a method including ...”)
15. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the computer program product of Westerhoff in view of UnityShader23 to include the disclosure of include a computer program product based on the method of claims 1, of Matsumoto. The motivation for this modification could have been to provide an additional embodiment of claim 1’s proposed method such that the method can be realized as a product, possibly for means of sale and/or distribution.
16. As per claim 17, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The computer program product of claim 11, wherein the three-dimensional image data set includes:
a three-dimensional image data set generated via one or more of a MRI system and CAT system. (Westerhoff, column 26, lines 14-19, “The invention pertains to digital data processing and, more particularly, by way of example, to the visualization of image data. Three dimensional (3D) and four dimensional (4D) image data is routinely acquired with CT, MRI, PET, confocal microscopes, 3D ultrasound devices, and other imaging devices.” and column 1, lines 38-42, “In medical imaging, for example, Volume Rendering is used to display 3D images from 3D image data sets, where a typical 3D image data set is a large number of 2D slice images acquired by a CT or MRI scanner and stored in a data structure.” and column 8, lines 27-32, “The texture (or graphics) memory 36, 38 is normally more limited than host memory 41 and often smaller than the total amount of data to be rendered, specifically for example, as in the case of the illustrated embodiment, if server 11 is used by multiple users concurrently visualizing different data sets.”)
17. Claim 18 is similar in scope to claim 1 except for additional limitations that Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: A system comprising:
one or more processors; and
memory storing programming instructions for execution by the one or more processors, the programming instructions, upon execution by the one or more processors, causing the system to perform the following operations: (Westerhoff, Fig. 1; column 7, lines 30-36, “The make-up of a typical such client computer is shown, by way of example, in the break-out on FIG. 1. As illustrated, client computer 18 includes CPU 18a, dynamic memory (RAM) 18b, ... all configured and operated in the conventional manner known in the art, as adapted in accord with the teachings hereof.” and column 8, lines 35-42, “Instead, in the illustrated embodiment, in order to render an image, the respective portion of the data set is transferred from either an external storage device or, more typically, host memory 41 into the graphics memories 36, 38 via the system bus 42. Once the data is transferred, commands issued to GPUs 35, 37 by Render Server Software (described below) cause it to render an image with the respective rendering parameters.”)
18. As per claim 28, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein the user input further specifies a camera position or orientation of the rendered three-dimensional medical volume. (Westerhoff, column 8, lines 61-65, “The Client Software is responsible for allowing the user to interact, for example, to choose a data set to visualize, to choose render parameters such as color, Data Window, or the view point or camera position when e.g., rotating the data set.” and column 10, lines 2-12, “As an example, we first discuss the MIP rendering mode, though, it will be appreciated that such a methodology can be used with other rendering modes. The 3D data set can be viewed as a cuboid in three-space, consisting of a number of voxels carrying gray values. FIG. 7 depicts that data volume viewed from a certain camera position by way of displaying a bounding box. Referring to FIG. 14 (which illustrates a method for bricking according to one practice of the invention), for a given camera position, each pixel on a computer screen (screen pixel) can be associated with a viewing ray.” and column 34, lines 20-23, “In one embodiment of the present invention, there is a final set of rules that specify the rendering style and other rendering parameters to be used when showing a particular image set.” and column 6, lines 1-4, “The term “Style Rules” will be used to refer to the rules to determine which rendering type, rendering style, and rendering parameters are used for a particular Image Set 1165 in a particular viewer.” and column 34, lines 36-46, “Parameters driven by Style Rules include the following: i) Rendering style (can be 2D, oblique, curved, MIP slab, 3D MIP, VRT, shaded VRT, etc.); ... viii) Camera position and orientation; …”
19. As per claim 29, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein the user input further specifies a scene rendering parameter for the rendered three-dimensional medical volume. (Westerhoff, column 8, lines 61-65, “The Client Software is responsible for allowing the user to interact, for example, to choose a data set to visualize, to choose render parameters such as color, Data Window, or the view point or camera position when e.g., rotating the data set.” and column 52, line 60-column 53, line 3, “Medical image studies can consist of multiple images that can be organized in multiple series. ... The same is true for any other interaction with the scene, such as rotation of a 3D volume rendering.” and column 34, lines 20-26, “In one embodiment of the present invention, there is a final set of rules that specify the rendering style and other rendering parameters to be used when showing a particular image set. For example, for a CT Angiogram study, often a volume rendering style display (VRT) is desired, whereas for a study looking for lung nodules a maximum intensity projection (MIP) of 20 mm slabs may be desired.” and column 6, lines 1-4, “The term “Style Rules” will be used to refer to the rules to determine which rendering type, rendering style, and rendering parameters are used for a particular Image Set 1165 in a particular viewer.” and column 34, lines 36-48, “Parameters driven by Style Rules include the following: i) Rendering style (can be 2D, oblique, curved, MIP slab, 3D MIP, VRT, shaded VRT, etc.); ii) Image alignment (left, right, top, bottom, centered); iii) Inverse display (black on white versus white on black); iv) Colormap or transfer function; v) Window/level (data window); vi) Slice thickness; vii) Zoom factor; viii) Camera position and orientation; and ix) Labels/OverlayDisplay of labels, annotations and other overlay elements.”)
20. Claim 32, which is similar in scope to dependent claim 28 and independent claim 18, is thus rejected under the same rationale as described above.
21. Claim 33, which is similar in scope to dependent claim 29 and independent claim 18, is thus rejected under the same rationale as described above.
22. Claim 36, which is similar in scope to dependent claim 28 and independent claim 11, is thus rejected under the same rationale as described above.
23. Claim 37, which is similar in scope to dependent claim 29 and independent claim 11, is thus rejected under the same rationale as described above.
24. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Westerhoff et al. (US-9904969-B1, hereinafter "Westerhoff") in view of Matsumoto (US-2009/0003668-A1), further in view of "Unity Shader Learning 01" (NPL: https://www.cnblogs.com/clf125800/p/17247467.html, March 23, 2023, hereinafter "UnityShader23"), and further in view of Krieger et al. (US-2020/0194117-A1, hereinafter "Krieger").
25. As per claim 7, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, (See rejection for claim 1.)
26. Westerhoff in view of Matsumoto, and further in view of UnityShader23 doesn't explicitly disclose but Krieger discloses: wherein the three-dimensional image data set includes at least one of a medical volume point cloud data set or a medical volume segmentations point cloud data set. (Krieger, Abstract, “In some embodiments, systems and methods for remote trauma assessment are provided, a system comprising, a robot arm; an ultrasound probe and a depth sensor coupled to the robot arm; and a processor programmed to: cause the depth sensor to acquire depth data indicative of a three dimensional shape of at least a portion of a patient ...” and page 9, paragraph [0098], “After acquiring camera images 240, the flow 234 can include generating a 3D point cloud 242. ... In some embodiments, a point cloud color segmentation can be applied to extract a point cloud corresponding to the patient from the reconstructed scene, for example by removing background items such as a table and a supporting frame.”)
27. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 1 of Westerhoff in view of Matsumoto, and further in view of UnityShader23 to include the disclosure of using a medical volume point cloud data set or a medical volume segmentations point cloud data set, of Krieger. The motivation for this modification could have been to provide additional data set types for visualization purposes.
28. Claims 26, 30, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Westerhoff et al. (US-9904969-B1, hereinafter "Westerhoff") in view of Matsumoto (US-2009/0003668-A1), further in view of "Unity Shader Learning 01" (NPL: https://www.cnblogs.com/clf125800/p/17247467.html, March 23, 2023, hereinafter "UnityShader23"), and further in view of Avila et al. (US-6947584-B1, hereinafter "Avila").
29. As per claim 26, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein the user input … (Westerhoff, column 8, lines 61-65, “The Client Software is responsible for allowing the user to interact, for example, to choose a data set to visualize, to choose render parameters such as color, Data Window, or the view point or camera position when e.g., rotating the data set.”)
30. Westerhoff in view of Matsumoto, and further in view of UnityShader23 doesn't explicitly disclose but Avila discloses: further specifies adding or removing a slice to the rendered three-dimensional medical volume. (Avila, Fig. 10; column 6, lines 11-24, ”The parameters which govern subsystem 52 can be entered by the user prior to acquisition or included in the scan protocol. The parameters may also be locally adjustable during the acquisition. Visualization subsystem 52 supports the real-time display of cross sectional data. This visualization feature is commonly referred to as “Autoview”. “Volume Autoview”, as used herein, refers to an incrementally updated 3D view of the data as the data is being acquired. Volume Autoview attaches to the imaging “stream” from the image reconstructor and is executed at console 40. During data acquisition, Volume Autoview provides a real-time, incrementally updated, 3D view of the data as the data is acquired over time.” and column 6, lines 46-48, “As new images are acquired, visualization subsystem 52 filters the images (if necessary) as they are added to the 3D model.” and column 9, lines 7-11, “It is often desirable to show the last N slices acquired during scanning. This display type is referred to as a sliding window technique. FIG. 10 illustrates that as scanning progresses, slices are added and removed from the model.” and column 9, lines 51-54, “FIG. 11 illustrates a case in which the slice being changed is inside the previously rendered model. If the slice is being added or removed from the model, the hierarchical data structure will need to change to account for the addition.” and column 10, lines 21-25, “Mixed data rendering (MDR) combines both a static, previously acquired, volume model with dynamic data. FIG. 12 illustrates a volume model in which all slices are static except for one. The dynamic slice is continuously changing as the scanner acquires new information on that plane.”)
31. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 1 of Westerhoff in view of Matsumoto, and further in view of UnityShader23 to include the disclosure of specifying as a rendering parameter the addition or removal of a slice of a rendered three-dimensional medical volume, of Avila. The motivation for this modification could have been to allow for dynamic addition and/or removal of slices in order to filter or update the volume rendering.
32. Claim 30, which is similar in scope to dependent claim 26 and independent claim 18, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 26.
33. Claim 34, which is similar in scope to dependent claim 26 and independent claim 11, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 26.
34. Claims 27, 31, and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Westerhoff et al. (US-9904969-B1, hereinafter "Westerhoff") in view of Matsumoto (US-2009/0003668-A1), further in view of "Unity Shader Learning 01" (NPL: https://www.cnblogs.com/clf125800/p/17247467.html, March 23, 2023, hereinafter "UnityShader23"), and further in view of Le Berre et al. (US-2021/0150811-A1, hereinafter "Le Berre").
35. As per claim 27, Westerhoff in view of Matsumoto, and further in view of UnityShader23 discloses: The method of claim 1, wherein the user input … (Westerhoff, column 8, lines 61-65, “The Client Software is responsible for allowing the user to interact, for example, to choose a data set to visualize, to choose render parameters such as color, Data Window, or the view point or camera position when e.g., rotating the data set.”)
36. Westerhoff in view of Matsumoto, and further in view of UnityShader23 doesn't explicitly disclose but Le Berre discloses: further specifies a color segmentation of the rendered three-dimensional medical volume. (Le Berre, [0040], “At step 408, 3D masks 228 are generated from the volume rendering view 202, 310 by segmenting 222, 224, 226 the objects in the view 202, 310. For example, a combined model and color generation processor 220 of the medical imaging system 110 or computer system 160 may perform segmentation processing 222 to generate a 3D mask 228 from the volume rendering input 202. The combined model and color generation processor 220 of the medical imaging system 110 or computer system 160 may perform segmentation processing 222 to generate a 3D mask based on the volumetric data image series 206, rendering options 208, segmentation information (if any), and the opacity transfer function 214.” and [0042], “At step 412, mesh colors may be computed 240, 242 from the volume rendering view 202, 310 for each object. ... The mesh coloring 240 may include color computation 242 based on the opacity transfer function 214, color transfer function 216, and any segmentation information 210 from the volume rendering input 202.”)
37. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 1 of Westerhoff in view of Matsumoto, and further in view of UnityShader23 to include the disclosure of specifying a color segmentation of a rendered three-dimensional medical volume, of Le Berre. The motivation for this modification could have been to allow segmented three-dimensional volumes to be assigned individual colors as a visual aid to help distinguish different object volumes.
38. Claim 31, which is similar in scope to dependent claim 27 and independent claim 18, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 27.
39. Claim 35, which is similar in scope to dependent claim 27 and independent claim 11, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 27.
Conclusion
40. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Documentation from Unity Manual Version 5.2 (July 2022) has been provided to further disclose the features of surface shaders and compute shaders .
41. 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.
42. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW CLOTHIER whose telephone number is (571)272-4667. The examiner can normally be reached Mon-Fri 8:00am-4:00pm.
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, Kent Chang can be reached on (571)272-7667. 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.
/MATTHEW CLOTHIER/Examiner, Art Unit 2614
/KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614
Prosecution Insights