Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because it recites a computer-readable storage medium. The broadest reasonable interpretation of a claim drawn to a computer readable medium (also called machine readable medium and other such variations) typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media, particularly when the specification is silent. See MPEP 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 U.S.C. 101 as covering non-statutory subject matter. The USPTO recognizes that applicants may have claims directed to computer readable media that cover signals per se, which the USPTO must reject under 35 U.S.C. 101 as covering both non-statutory subject matter and statutory subject matter. A claim drawn to such a computer readable medium that covers both transitory and non-transitory embodiments may be amended to narrow the claim to cover only statutory embodiments to avoid a rejection under 35 U.S.C. $ I01 by adding the limitation "non-transitory" to the claim. Such an amendment would typically not raise the issue of new matter, even when the specification is silent because the broadest reasonable interpretation relies on the ordinary and customary meaning that includes signals per se.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 9-14 and 17-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Viggers et al. (Pub. No.: US 2017/0116702 A1), hereinafter Viggers.
Regarding claim 1, Viggers discloses a management method for graphics rendering resources, applied to a central processing unit, wherein the central processing unit is connected to a graphics processing unit, the central processing unit is configured with at least two different rendering programs (Paragraph 15 teaches that FIG. 6 is a flow diagram depicting a method for using an OpenGL API with a Vulkan graphics driver according to one embodiment;), and the graphics processing unit is configured to provide hardware resources of graphics rendering for the rendering programs (Paragraph 19 teaches that the embodiments of the systems and methods described herein may be implemented in hardware or software, or a combination of both. However, preferably, these embodiments are implemented in computer programs executing on programmable computers each comprising at least one processor, a data storage system (including volatile and non-volatile memory and/or other storage elements), at least one input device, and at least one output device.), wherein the management method for graphics rendering resources comprises steps of:
determining, in response to a received management instruction generated in a running process of at least one rendering program, a hardware resource object for calling graphic rendering, based on the management instruction and an interface function conversion relationship and a driving conversion relationship in a rendering resource object of a rendering program corresponding to the management instruction (Paragraph 32 teaches that referring to FIG. 1A and FIG. 1B, the OpenGL driver architecture 100 is designed to operate with a first GPU 127, whereas the Vulkan driver architecture 150 is designed to operate with a second GPU 128. According to some embodiments, the GPU 127 may be optimized for OpenGL, whereas the GPU 128 may be optimized for OpenGL and/or Vulkan. In other words, the GPU 128 may be of the same type as the GPU 127, or it may be of a type that is particularly configured for use with Vulkan. Thus, the OpenGL driver architecture 100 provides the GPU 127 with instructions based on an application making OpenGL API calls, whereas the Vulkan architecture 150 provides the GPU 128 with instructions based on an application making Vulkan API calls. As such, when the GPU 128 is optimized for Vulkan, the OpenGL driver architecture 100 is incapable of providing instructions to the GPU 128 that fully utilize the capabilities of Vulkan. Additionally, paragraph 33 teaches that according to some embodiments, it is possible to achieve a driver architecture that provides the GPU 128 with instructions based on an OpenGL API call (e.g. via dispatch module 116) through the use of a translator module that links the OpenGL render module 120 with the Vulkan render module 124. With the use of a translator module, the dispatch module 116, state tracker 118, render module 120, render module 124, and carddata module 126 can be used to provide the GPU 128 with instructions based on an application making OpenGL API calls.);
and managing, according to the determined hardware resource object and the management instruction, a hardware resource of the graphic rendering required by the management instruction (Paragraph 38 teaches that the translator component 212 comprises a translator module 222. The translator module 222 is responsible for gathering the OpenGL state information and draw commands, and translating those commands into Vulkan commands and state information, as well as generating any Vulkan-specific state/object in order to submit a Vulkan operation.),
wherein each of the rendering programs is separately configured with a corresponding rendering resource object, and each of the rendering resource objects comprises the interface function conversion relationship and the driving conversion relationship (Paragraph 34 teaches that an OpenGL-on-Vulkan driver architecture 200 is shown in FIG. 2. The driver architecture 200 can be described in terms of an OpenGL driver component 210, a translator component 212, and a Vulkan driver component 214. These components are distinguished in order to describe the operability of the driver architecture 200 in terms of the OpenGL components (analogous to OpenGL driver architecture 100), the Vulkan components (analogous to the Vulkan driver architecture 150), and the translator module that links them. This is accomplished by keeping the OpenGL-specific and hardware-agnostic modules of the driver architecture 100, and substituting the hardware-specific modules with the Vulkan equivalent of the low-level and hardware-specific modules from the driver architecture 150. Additionally, paragraph 50 teaches that the translator component 312, using the translator module 322, gathers state information from the OpenGL driver component 310 and translates the state information into Vulkan typed states. The translator module 322 translates the OpenGL operation into a Vulkan operation and calls the Vulkan driver component 314 in order to eventually execute the operation on the GPU 328 and paragraph 51 teaches that the Vulkan driver component 314 gathers the state information and desired operation and uses the Vulkan render module 324 to generate hardware-specific commands to execute the operation. The Vulkan render module 324 then calls the carddata module 326 in order to execute the operation on the GPU 328.);
the interface function conversion relationship comprises a conversion relationship between a pre-set hardware resource interface function and a target interface function of a hardware resource required for calling the graphic rendering; the pre-set hardware resource interface functions in rendering resource objects corresponding to different rendering programs are the same; the target interface functions in the rendering resource objects corresponding to different rendering programs are different, and the target interface function in each of the rendering resource objects is a call interface function of the rendering program corresponding to the rendering resource object to the graphic rendering resource (FIG. 5 and Paragraph 61 teach that referring to FIG. 5, there is shown an OpenGL-on-Vulkan driver architecture 500 that includes a translator to Window System Integration (WSI). Additionally, paragraph 67 teaches that in the example shown in FIG. 5, an OpenGL-on-Vulkan driver architecture 500 uses EGL on WSI. The EGL API provides a list of functions that an application can use to create a graphics context, a render surface, a display, and associate the three as the current render targets.);
and the driving conversion relationship comprises a conversion relationship between the pre-set hardware resource interface function and the hardware resource object, and the hardware resource object is configured to call the hardware resource of the graphics rendering (Paragraph 69 teaches that in order to accomplish the above, and utilize WSI in Vulkan, the translator module 522 can translate the EGL (or GLX or WGL) into an equivalent WSI call. The translator module 522 receives the EGL (or WGL or GLX) function 530, translates it to the equivalent WSI call 532, which is then sent to the GPU 528.).
Regarding claim 2, Viggers discloses everything claimed as applied above (see claim 1), in addition, Viggers discloses wherein the pre-set hardware resource interface function is different from the target interface functions of all the rendering programs configured in the central processing unit (Paragraph 69 teaches that in order to accomplish the above, and utilize WSI in Vulkan, the translator module 522 can translate the EGL (or GLX or WGL) into an equivalent WSI call. The translator module 522 receives the EGL (or WGL or GLX) function 530, translates it to the equivalent WSI call 532, which is then sent to the GPU 528.).
Regarding claim 3, Viggers discloses everything claimed as applied above (see claim 1), in addition, Viggers discloses wherein the central processing unit further comprises a driving layer and driving units respectively corresponding to the different rendering programs (Paragraph 29 teaches that the carddata module 125 is the driver layer that sits directly on top of the GPU. As with the render module 120, the carddata module 125 is hardware specific. The carddata module 125 receives the hardware-specific state, types, and commands from the render module 120, derives hardware-specific GPU operations, and submits them to the GPU.);
the pre-set hardware resource interface function is the same as a target interface function of a pre-set rendering program; the pre-set rendering program is any rendering program in the central processing unit; and the pre-set rendering program corresponds to a pre-set driving unit (Paragraph 36 teaches that the OpenGL driver component 210 also includes a render module 220. According to some embodiments, the render module 220 may be generally the same as the render module 120. However, according to other embodiments, the render module 220 may be a “thin” render module as compared to the render module 120. The thin render module is used to track and allocate resources that will be submitted to the translator module 222. According to some embodiments, the use of a thin render module 220 allows for the render module 220 to be hardware agnostic.);
prior to determining a hardware resource object for calling graphic rendering, based on the management instruction and an interface function conversion relationship and a driving conversion relationship in a rendering resource object of a rendering program corresponding to the management instruction (Paragraph 37 teaches that unlike the render module 120, render module 220 does not need to contribute to providing instructions to a GPU, and, as such, can be designed in order to be hardware agnostic. With this approach, it is possible to achieve an OpenGL-on-Vulkan driver architecture 200 in which the entire OpenGL driver component 210 is hardware-agnostic (i.e. a single OpenGL driver component 210 can be used with any GPU). According to some embodiments, the OpenGL render module 220 is responsible for tracking and allocating resources prior to issuing a call to the translator module 222, as well as invoking the translator module 222.), the method further comprises steps of:
calling, in response to running of another rendering program other than the pre-set rendering program, the pre-set driving unit to create an initial rendering resource object of the rendering program, based on a driving unit of the rendering program, wherein the initial rendering resource object comprises the pre-set hardware resource interface function (Paragraph 27 teaches that the dispatch module 116 is responsible for marshalling OpenGL API calls made by an application, to the corresponding function of the state tracker 118. This allows the state tracker 118 to track all states related to the OpenGL context. The state tracker 118 is specifically designed to be hardware agnostic so that it does not need to be re-written for different hardware (e.g. GPU) specifications.);
and controlling, based on the driving unit of the rendering program, the pre-set driving unit to create an interface function conversion relationship between the pre-set hardware resource interface function and a target interface function of the rendering program in the initial rendering resource object, to obtain the rendering resource object corresponding to the rendering program (Paragraph 28 teaches that conversely, the render module 120 is hardware specific. In other words, the render module 120 is written for a particular type of hardware (e.g. GPU). Thus, for different GPUs. The render module 120 is responsible for taking the OpenGL context and OpenGL commands and converting them to hardware-specific state, types, and commands. Additionally, paragraph 30 teaches that the implementation of the OpenGL driver architecture 100 is such that the render module 120 and the carddata module 125 (as well as the GPU 127) are hardware specific. Thus, for a particular type of GPU 127, it is necessary to write a render module 120 and a carddata module 125 that work with the particular type of GPU 127. However, according to some embodiments, other parts of the driver architecture 100 (e.g. the dispatch module 116, the state tracker 118, etc.) may be common across different types of GPU 127.).
Regarding claim 4, Viggers discloses everything claimed as applied above (see claim 3), in addition, Viggers discloses wherein the rendering resource object further comprises call information on the hardware resource for the rendering program corresponding to the rendering resource object to perform the graphics rendering, wherein the call information comprises at least one of identification information on the hardware resource object and an access address of a hardware resource corresponding to the hardware resource object in the graphics processing unit (Paragraph 53 teaches that OpenGL driver component 310 through the dispatch module 316. The dispatch module 316 converts this into an internal call to the appropriate state-tracker function. The state tracker 316 generates and stores OpenGL state information pertaining to the texture object. This includes dimensions, format, etc. and paragraph 58 teaches that OpenGL is a state machine where most of the APIs are involved in the recording of state information. It is during a draw operation that all of the recorded state will be checked and submitted to the GPU 428 to affect the output of the operation. gIDrawArrays is a common way to submit a draw command to the GPU 428. Additionally, paragraph 59 teaches that as in the example 300, the call is marshalled through the dispatch module 416 and onto the state tracker 418. At this point, relevant state information is stored, and auxiliary operations are performed like loading transformation matrices to a location in system memory to be loaded later as a constant.).
Regarding claim 5, Viggers discloses everything claimed as applied above (see claim 4), in addition, Viggers discloses wherein the step of determining a hardware resource object for calling graphic rendering, based on the management instruction and an interface function conversion relationship and a driving conversion relationship in a rendering resource object of a rendering program corresponding to the management instruction, comprises:
acquiring, in response to the received management instruction, at least one of the access address of and the identification information on the hardware resource required by the rendering program, from the rendering resource object corresponding to the rendering program (Paragraph 54 teaches that from the state tracker 318, the operation proceeds to the render module 320. In the render module 320, the texture is placed on a temporary location accessible by the GPU (if applicable), and the translator module 322 is invoked to load the texture.);
and determining the hardware resource object based on at least one of the access address of and the identification information on the hardware resource (Paragraph 55 teaches that after the translator module 322 is invoked, it is responsible for marshalling the texture object and its OpenGL state into a Vulkan operation. This means translating from OpenGL formats to Vulkan formats. For example, the OpenGL format GL_RGBA can be translated to VK_FORMAT_R8G8B8A8_UNIT, and GL_TEXTURE_2D can be translated to VK_IMAGE_TYPE_2D. Additionally, a Vulkan pipeline, memory, command buffer (indirect buffer), and shader objects can be generated.).
Regarding claim 6, Viggers discloses everything claimed as applied above (see claim 3), in addition, Viggers discloses wherein hardware resources of graphics rendering required by each rendering program are diverse; and the pre-set hardware resource interface function comprises pre-set hardware resource interface sub- functions corresponding to various kinds of hardware resources respectively (Paragraph 60 teaches that the operation proceeds to the render module 420, where a number of important tasks are performed: lower-level state information is stored and tracked (e.g. state flags are dirtied where applicable), vertex data, constants, texture samplers, texture resources are loaded to temporary system memory locations (or compiled in a way that can be presented to the Vulkan translator module 422), SPIR-V shaders are generated and loaded (or compiles in a way that can be presented to the Vulkan translator module 422), and a draw command is generated and submitted to the translator module 422. Subsequently, the translator module 422 is responsible for converting the OpenGL state information, and generating a Vulkan-style draw operation to submit to the Vulkan driver component 414.);
the step of calling the pre-set driving unit to create an initial rendering resource object of the rendering program, based on a driving unit of the rendering program (Paragraph 27 teaches that the dispatch module 116 is responsible for marshalling OpenGL API calls made by an application, to the corresponding function of the state tracker 118. This allows the state tracker 118 to track all states related to the OpenGL context. The state tracker 118 is specifically designed to be hardware agnostic so that it does not need to be re-written for different hardware (e.g. GPU) specifications.), comprises:
acquiring, in response to running of another rendering program other than the pre-set rendering program, various kinds of hardware resources required by the rendering program; and calling the pre-set driving unit based on a driving unit of the rendering program, so as to make the pre-set driving unit create initial rendering resource objects corresponding to various kinds of hardware resources required by the rendering program, respectively, wherein the initial rendering resource objects corresponding to various kinds of hardware resources comprise pre-set hardware resource interface sub-functions corresponding to various kinds of hardware resources (Paragraph 66 teaches that according to some embodiments, the OpenGL-on-Vulkan driver architecture 500 may ensure that an OpenGL application need not be aware that it is running on top of a Vulkan driver. Thus, it follows that an application that uses EGL need not be aware that it is running on top of WSI and FIG. 5 and paragraph 67 teach that in the example shown in FIG. 5, an OpenGL-on-Vulkan driver architecture 500 uses EGL on WSI. The EGL API provides a list of functions that an application can use to create a graphics context, a render surface, a display, and associate the three as the current render targets. Additionally, paragraph 69 teaches that in order to accomplish the above, and utilize WSI in Vulkan, the translator module 522 can translate the EGL (or GLX or WGL) into an equivalent WSI call. The translator module 522 receives the EGL (or WGL or GLX) function 530, translates it to the equivalent WSI call 532, which is then sent to the GPU 528.);
the step of controlling, based on the driving unit of the rendering program, the pre-set driving unit to create an interface function conversion relationship between the pre-set hardware resource interface function and a target interface function of the rendering program in the initial rendering resource object, to obtain the rendering resource object corresponding to the rendering program, comprises:
controlling, for each of the initial rendering resource objects, based on the driving unit of the rendering program, the pre-set driving unit to create an interface function conversion relationship between the pre-set hardware resource interface sub-function and the target interface function of the rendering program, in the initial rendering resource object, to obtain the rendering resource object corresponding to the rendering program (Paragraph 46 teaches that the OpenGL-on-Vulkan driver architecture 200 handles the programmable pipeline version similar to the fixed-function approach. The difference between the two approaches is that the application provides the shader code written in the GLSL language. If a GLSL to ISA compiler is used, then the OpenGL driver component 210 provides the ISA shader to the translator component 212 for the Vulkan driver component 214 to load “as is”. If a GLSL to SPIR-V compiler is provided then SPIR-V will be provided to the translator component 212, which in turn will pass it to the Vulkan driver component 214 to convert to ISA.).
Regarding claim 9, the apparatus steps correspond to and are rejected similarly to the method steps of claim 1 (see claim 1 above). In addition, Viggers discloses a management apparatus for graphics rendering resources (FIG. 2 and paragraph 11 teach that FIG. 2 is a block diagram of an OpenGL-on-Vulkan driver architecture, according to one embodiment;).
Regarding claim 10, the apparatus steps correspond to and are rejected similarly to the method steps of claim 2 (see claim 2 above).
Regarding claim 11, the apparatus steps correspond to and are rejected similarly to the method steps of claim 3 (see claim 3 above).
Regarding claim 12, the apparatus steps correspond to and are rejected similarly to the method steps of claim 4 (see claim 4 above).
Regarding claim 13, the apparatus steps correspond to and are rejected similarly to the method steps of claim 5 (see claim 5 above).
Regarding claim 14, the apparatus steps correspond to and are rejected similarly to the method steps of claim 6 (see claim 6 above).
Regarding claim 17, Viggers discloses a computer-readable storage medium, wherein the readable storage medium stores a computer program, and when the computer program runs on a computer, the computer is made to implement the management method for graphics rendering resources (Paragraph 20 teaches that each program may be implemented in a high level procedural or object oriented programming and/or scripting language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each such computer program is preferably stored on a storage media or a device (e.g. read only memory (ROM) or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.).
Regarding claim 18, the computer-readable storage medium steps correspond to and are rejected similarly to the method steps of claim 2 (see claim 2 above).
Regarding claim 19, the computer-readable storage medium steps correspond to and are rejected similarly to the method steps of claim 3 (see claim 3 above).
Regarding claim 20, the computer-readable storage medium steps correspond to and are rejected similarly to the method steps of claim 4 (see claim 4 above).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 7-8 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Viggers in view of Vax (Pub. No.: US 2023/0185635 A1).
Regarding claim 7, Viggers discloses everything claimed as applied above (see claim 3), however, Viggers fails to disclose wherein after obtaining the rendering resource object corresponding to the rendering program, the method further comprises a step of:
destroying, in response to a stop in running of any other rendering program other than the pre-set rendering program, the rendering resource object corresponding to the stopped rendering program.
Vaz discloses destroying, in response to a stop in running of any other rendering program other than the pre-set rendering program, the rendering resource object corresponding to the stopped rendering program (Paragraph 71 of Vaz teaches that at invalidate operation 320, in at least one embodiment, one or more circuits perform an API to invalidate a timeline semaphore from another API. In at least one embodiment, to invalidate means to delete, release references (e.g., all references in CUDA context), remove, or destroy a timeline semaphore. In at least one embodiment, other operations may still be waiting or using a timeline semaphore and a context that is managing said timeline semaphore does not delete it from shared memory until other operations are completed (e.g., all wait and signal operations). Additionally, paragraph 100 teaches that if process 700 determines that no contexts, functions, or processes are waiting on a timeline semaphore, process 700 destroys a timeline semaphore. In at least one embodiment, a first context released references to a handle for a timeline semaphore, and in decision operation 710, all of contexts (e.g., a second context) determine whether are additional references to said timeline semaphore, if there are, a context must wait or complete operations depending on that timeline semaphore before releasing references to it. For example, if VULKAN created a timeline semaphore, all operations related to said timeline semaphore in CUDA are completed, and no other APIs are using said timeline semaphore (e.g., a video game has ended), process 700 destroys said timeline semaphore, where destroy means that VULKAN API also deletes all references to said timeline semaphore, and a driver deallocates memory for said timeline semaphore so that it is effectively destroyed (e.g., completely removed from a computing platform such as an NVIDIA platform).). Since Viggers teaches the initial method steps for obtaining a rendering resource object corresponding to multiple rendering programs and Vaz teaches steps for having multiple rendering programs and can provide the functions of deleting, releasing, removing, or destroying different types of contexts and operations, it would have been obvious to a person having ordinary skill in the art to have combined the features together so that any rendered resource object that corresponds to a particular rendering program, such as the VULKAN rendering program, could have the functionality that would allow for that function to be destroyed and stopped from being completed entirely.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Viggers to incorporate the teachings of Vaz, so that the combined features together would provide a stopping/destroying function to the rendering programs which would improve rendering efficiency and reduce the amount of wasted resources being unnecessarily applied to a CPU, GPU or memory location.
Regarding claim 8, Viggers discloses everything claimed as applied above (see claim 3), however, Viggers fails to disclose wherein after the step of determining a hardware resource object for calling graphic rendering, based on the management instruction and an interface function conversion relationship and a driving conversion relationship in a rendering resource object of a rendering program corresponding to the management instruction, the method further comprises a step of:
synchronizing, in response to a call of any rendering program to the hardware resource of the graphics rendering, data reading and writing in the central processing unit and the graphics processing unit based on a resource synchronization unit of the pre-set rendering program.
Vaz discloses synchronizing, in response to a call of any rendering program to the hardware resource of the graphics rendering, data reading and writing in the central processing unit and the graphics processing unit based on a resource synchronization unit of the pre-set rendering program (Paragraph 81 of Vaz teaches that after import operation 420, in at least one embodiment, one or more circuits can repeat process 400 or parts of process 400 for other code elements of device code. For example, if an application requests that more than one timeline semaphore be created, then process 400 can be repeated for each timeline semaphore that needs to be imported. Additionally, paragraph 75 teaches that at create operation 405, in at least one embodiment, one or more circuits creates one or more timeline semaphores, which can include a first API creating one or more timeline semaphore in response to an application requesting that said one or more timeline semaphores be created. For example, a VULKAN API creates a timeline semaphore for a video game so that VULKAN API can synchronize frame rendering and graphics operations with other operations performed by CUDA through one or more timeline semaphores, where said video game is run or will be run on an NVIDIA platform with a host processor (e.g., CPU) and a device processor (e.g., GPU) and paragraph 175 teaches that in at least one embodiment, graphics processor 1710 additionally includes one or more MMU(s) 1720A-1720B, cache(s) 1725A-1725B, and circuit interconnect(s) 1730A-1730B. ... In at least one embodiment, one or more MMU(s) 1720A-1720B may be synchronized with other MMUs within a system, including one or more MMUs associated with one or more application processor(s) 1205, image processors 1215, and/or video processors 1220 of FIG. 12, such that each processor 1205-1220 can participate in a shared or unified virtual memory system.). Since Viggers teaches the initial method steps for determining a rendering resource object corresponding to multiple rendering programs and Vaz teaches a function for being able to synchronize different rendering and graphic options between two different rendering programs, it would have been obvious to a person having ordinary skill in the art to have combined the features together so that any of the calls made to any of the rendering programs for reading and writing data between a CPU and a GPU would be able to be synchronized with one another.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Viggers to incorporate the teachings of Vaz, so that the combined features together would allow for synchronization of any related resource and data pertaining to multiple rendering programs, which would improve overall data consistency by keeping all related data with the CPU and the GPU of the rendering programs, to all be in sync with one another.
Regarding claim 15, the apparatus steps correspond to and are rejected similarly to the method steps of claim 7 (see claim 7 above).
Regarding claim 16, the apparatus steps correspond to and are rejected similarly to the method steps of claim 8 (see claim 8 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wen (CN 117724987 A) teaches an OpenGL hierarchical implementation verification method based on texture conversion tracking to see if a GPU can support a Vulkan library.
Kim et al. (KR 20220146863 A) teaches a device and method for receiving a first type of graphics API-based function execution request from an application and translating it into a second type of graphic API-based function execution request for a second application.
Zhang (CN 110136230 A) teaches an animation display method and device for obtaining model data related to a first data type and converting the model data into a second data type across multiple different display platforms.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to George Renze whose telephone number is (703)756-5811. The examiner can normally be reached Monday-Friday 9:00am - 6:00pm EST.
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, Xiao Wu can be reached at (571) 272-7761. 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.
/G.R./Examiner, Art Unit 2613
/XIAO M WU/Supervisory Patent Examiner, Art Unit 2613
Prosecution Insights