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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-6, 9-10 and 14-15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kokkevis et al1 (“Kokkevis”) in view of McKegney et al2 (“McKegney”).
Regarding claim 1, Kokkevis teaches a computer implemented method of simulating a three-dimensional (3D) object for display in a browser on a client’s device (note that method steps below address the simulating of the 3D object for display as well as a browser and client’s device as functioning below and thus the limitations of the preamble are addressed in the body of the claim below), the method comprising the initial steps of:
generating a 3D object and storing the 3D object in memory (note that the claim does not define that the memory is necessarily of the client’s device or any other specific device and thus any storing of such data in any memory which allows the loading recited below is such storing in memory – furthermore note that this memory is not considered to necessarily be the same “memory” as the “physics libraries in memory” as it is not recited as “a memory” and the following “memory” is also not ever referred to more specifically as “the memory” such that recitation of such “memory” is a broad limitation that storage in memory must occur in some manner at least; see Kokkevis, paragraphs 0052-0056 and figure 3 teaching “3D application 302 may provide an input file that describes a graphics model to graphics plugin 306. Alternatively, 3D application 302 may make a set of method calls that describe the graphics model to graphics plugin 306. The graphics model may then be loaded into the internal memory of graphics plugin 306” such that here the “graphics model” is a 3D object which has been generated at this time or previously in order for it to be “loaded” from somewhere and is stored in the “internal memory” after being loaded from elsewhere meaning that it was unloaded from some other memory as well);
storing a plurality of physics libraries in memory (note that a physics library in the context of the claims is a library in the sense that it is a collection of something to be referenced and in which that thing to be refenced deals with the subject of physic in some way, and in the context of the claims this may take a more narrow form such as for example any collection of code, scripting or the like which can be used for physics calculations; see Kokkevis, paragraphs 0052-0058 teaching “3D application 302 coordinates the joint execution of physics engine 310 and rendering engine 312” and “may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310” such that here a “physics” model that corresponds to the 3D graphic model is stored through such loading into the internal memory as well and thus all such collections of physics parameters and related data correspond to a plurality of physics libraries in memory as for example “To animate the graphics model, physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model. Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data” such that here for any given objects or its interaction of the multiple objects and interactions disclosed, physics libraries are stored in memory which allow the proper calculations by the physics engine);
storing an in-browser simulation application programming interface (API) linking an in-browser physics engine and an in-browser rendering engine, and a simulation computer program code, in memory (here a simulation API is a set of rules or code or even an arrangement of elements as an interworking architecture that allows different components to communicate through facilitating communication in some manner; see Kokkevis, paragraphs 0052-0058 teaching such simulation application programming interface as the “3D Application 302” as configured to interact and communication with the physics and rendering engines as in figure 3 for example as “3D application 302 may correspond to a web application that executes in a web browser 300” and “3D application 302 may provide 3D graphics rendering and animation capabilities to a user of 3D application” where this may further comprise “CAD system, and/or a scientific modeling and/or simulation application” according to the particular application 302 where such arrangement as described with respect to figure 3 is a stored simulation API linking a physics engine “physics engine 310” and a rendering engine “rendering engine 312” and for example this is stored at the user device upon downloading from the internet where “physics engine 310 corresponds to a native code module that is executed within a secure runtime environment provided by plugin 304. Physics engine 310 may be provided by 3D application 302 (e.g., downloaded over the Internet) and validated prior to execution in plugin 304” such that here the API and linked engines and code are stored in the memory of the user device as well as from the internet where they were stored in some functional memory in order to be downloaded ); and
on a web page load request issued through the browser on the client’s device (see Kokkevis, paragraphs 0059-0062 teaching “Initially, a web application is loaded into a web browser (operation 402). The web application may be obtained from a server by the web browser. Furthermore, the web application may be used to provide computationally intensive features, such as financial modeling, computational math or science, and/or AI, to a user. To implement such features in a practical manner, a native code module associated with the web application may be obtained (operation 404). For example, the native code module may be downloaded from a source specified by the web application” such that here a web page load request issued through a browser on the client’s device is considered to have taken place which is a request which lead to loading of the API as explained above; see also paragraphs 0052-0056 teaching a web page load request issued through the browser on the client’s device where the “web-based 3D application 302” is so loaded to execute on the client’s device on the browser):
loading the an in-browser simulation application programming interface (API) and the simulation computer program code onto the client’s device (see Kokkevis, paragraphs 0052-0058 teaching such loading in connection with the storing explained above teaching such simulation application programming interface as the “3D Application 302” as configured to interact and communication with the physics and rendering engines as in figure 3 for example as “3D application 302 may correspond to a web application that executes in a web browser 300” and “3D application 302 may provide 3D graphics rendering and animation capabilities to a user of 3D application” where this may further comprise “CAD system, and/or a scientific modeling and/or simulation application” according to the particular application 302 where such arrangement as described with respect to figure 3 is a stored simulation API linking a physics engine “physics engine 310” and a rendering engine “rendering engine 312” and for example this is stored at the user device upon loading from the internet where “physics engine 310 corresponds to a native code module that is executed within a secure runtime environment provided by plugin 304. Physics engine 310 may be provided by 3D application 302 (e.g., downloaded over the Internet) and validated prior to execution in plugin 304” such that here the API and application 302 which may be for “scientific modeling and/or simulation” is loaded to the client’s device in order that they might run the simulation through the browser of the client device);
importing the 3D object and at least one of the physics libraries to the client’s device (see Kokkevis, paragraphs 0052-0058 where the 3D object model is imported to the client’s device as explained above teaching “3D application 302 may provide an input file that describes a graphics model to graphics plugin 306. Alternatively, 3D application 302 may make a set of method calls that describe the graphics model to graphics plugin 306. The graphics model may then be loaded into the internal memory of graphics plugin 306” such that here the “graphics model” is a 3D object imported to the device where it will then be operated on in connection with the imported physics library such as the “physics model” where “3D application 302 coordinates the joint execution of physics engine 310 and rendering engine 312” and “may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310” such that here a “corresponding physics model” is a physics library particular to the simulation of the model being performed and is thus imported to the client’s device and for example such libraries are also imported to the client’s device as well where “Graphics plugin 306 may then load data relevant to physics simulation into IMC buffers 314-316. For example, graphics plugin 306 may copy vertex positions, normals, triangle indices, and/or transformation matrices into IMC buffers 314-316” and “physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model”);
simulating the 3D object wholly in-browser using the in-browser simulation API, the in-browser rendering engine, and the in-browser physics engine having access to the imported physics library (see Kokkevis, paragraphs 0052-0058 as explained above teaching “3D application 302 may provide an input file that describes a graphics model to graphics plugin 306. Alternatively, 3D application 302 may make a set of method calls that describe the graphics model to graphics plugin 306. The graphics model may then be loaded into the internal memory of graphics plugin 306” such that here the “graphics model” is a 3D object imported to the device where it will then be operated on in connection with the imported physics library such as the “physics model” where “3D application 302 coordinates the joint execution of physics engine 310 and rendering engine 312” and “may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310” and “physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model” such that here simulating the 3D object is done using the simulation API, and both engines with the physics engine accessing the physics library imported so that “physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model. Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data”);
rendering the 3D object wholly in-browser in the client’s browser (see Kokkevis, paragraphs 0052-0058 where of course the purpose of such simulation is to view a rendering of the simulated object in the client’s browser as where “Rendering engine 312 may then pass the updated graphics model to GPU 320 for rendering” where this is all occurring in the client’s browser which is executing the application) , and, for each subsequent frame (see Kokkevis, paragraphs 0052-0058 as explained above where this process updates continuously and for each subsequent frame as “Graphics rendering and animation may continue to be provided by rendering engine 312 and physics engine 310 during execution of 3D application 302. For example, physics engine 310 may continue to update the graphics model as long as forces are felt by objects in the graphics model. Additional objects and/or forces may also be introduced into the graphics model and/or physics model by 3D application 302. Similarly, rendering engine 312 may render the graphics model at a frame rate specified by 3D application 302 and/or supported by GPU 320. As a result, physics engine 310 and rendering engine 312 may run at different frequencies. For example, physics engine 310 may run four times faster than rendering engine 312. As a result, the graphics model may be rendered once by rendering engine 312 for every four updates to the graphics model made by physics engine 310”):
updating the in-browser rendered 3D object by using the physics engine in-browser to generate position and rotation data for the 3D object and sending that position and rotation data to the in-browser rendering engine (see Kokkevis, paragraphs 0052-0058 teaching “Graphics rendering and animation may continue to be provided by rendering engine 312 and physics engine 310 during execution of 3D application 302. For example, physics engine 310 may continue to update the graphics model as long as forces are felt by objects in the graphics model. Additional objects and/or forces may also be introduced into the graphics model and/or physics model by 3D application 302” and such updating of the rendered objects to feel “forces” is in line with the physics model and simulation provided by the engine where “To animate the graphics model, physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model. Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data. Finally, the new data is read from IMC buffers 314-316 by graphics plugin 306 and used to update the graphics model” such that this also shows sending such position and rotation data describing the position and rotation of an object in the simulation to the rendering engine in order to properly update the rendered object);
the in-browser rendering engine updating wholly in-browser the rendered 3D object based on the position and rotation data received from the physics engine and displaying the updated rendered 3D object (see Kokkevis, paragraphs 0052-0058 as explained above teaching “Graphics rendering and animation may continue to be provided by rendering engine 312 and physics engine 310 during execution of 3D application 302. For example, physics engine 310 may continue to update the graphics model as long as forces are felt by objects in the graphics model. Additional objects and/or forces may also be introduced into the graphics model and/or physics model by 3D application 302” and such updating of the rendered objects to feel “forces” is in line with the physics model and simulation provided by the engine where “To animate the graphics model, physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model. Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data. Finally, the new data is read from IMC buffers 314-316 by graphics plugin 306 and used to update the graphics model” such that this passing of the information to the rendering engine allows the rendering engine to update the model and for example “Rendering engine 312 may then pass the updated graphics model to GPU 320 for rendering” such that this is an updated and rendered 3D object which is rendered for display to the browser which comprises a display of course in order to view the content which is being browsed and for example note paragraph 0026 also makes clear that rendered objects are rendered for the purpose of display as the “web application may be loaded in a web browser and executed on a computing system such as a personal computer (PC), a mobile phone, a personal digital assistant (PDA), a graphing calculator, a portable media player, a global positioning system (GPS) receiver, and/or another electronic computing device” such that here of course a web browser for such use includes a display for display on such devices as computing system 102 of paragraphs 0028-0032 teaching that “web application 116 may function as an email client, document editor, media player, computer-aided design (CAD) system, and/or computer game. Web application 116 may also include dynamic user interface elements such as menus, buttons, windows, sub-windows, icons, animations, and/or other graphical objects that emulate analogous user interface elements in native applications. In other words, web application 116 may correspond to a rich Internet application (RIA)” where all of such applications thus involve use of display of such objects being generated/simulated/rendered).
Kokkevis teaches all that is required as explained above, but fails to specifically teach that the operations above are specifically performed “in-browser” as rather while Kokkevis clearly teaches the technique as browser based and locally executed such that a user would experience the operation and control the method wholly in-browser, the performance of calculations could be seen as offloaded to a plugin to the browser such that the operations are not performed “in-browser” and “wholly in-browser”. Thus Kokkevis stands as a base device upon which the claimed invention can be seen as an improvement through providing complex calculations to a user through engines operating wholly in-browser allowing for greater ease of use for a user that does not have to install a plugin while still allowing for local wholly in-browser execution, which additionally would give the benefits of in-browser or native execution such as avoiding compatibility and support issues of plugging in to different browser types as well as enhanced security given that plug-ins can represent a security risk to users.
In the same field of endeavor relating to techniques for performing complex calculations/simulations for rendering of 3D objects simulated using a browser, McKegney teaches techniques for storing an in-browser simulation application programming interface (API) linking an in-browser physics engine and an in-browser rendering engine, and a simulation computer program code, in memory (see McKegney, paragraphs 0035-0037 teaching “3D scene browser interaction editing technique 100 and the herein disclosed techniques can provide a “Web-based 3D Framework” layer to the web designer 105 1, as shown, to bridge the gap between the web design environment and the 3D capabilities of the browser and device graphics hardware, without demanding that the web designer 105 1 learn and/or write low order 3D drawing and/or rendering code” such that this framework constitutes an API that links in-browser 3D engines and a simulation computer program code for simulating how some 3D asset appears based on the interactive scene definitions and inputs where “the 3D scene browser interaction editing technique 100 can be implemented in a web application (e.g., visual editor 106 1) operating in a browser 104 1 or operating in a web agent that is accessible to the web designer 105 1 (e.g., from a user device)” and as in paragraphs 0039-0043 the “the 3D runtime engine 210 1 can be an instance of certain 3D runtime engines 210 (e.g., various versions of the engine) stored in an external storage 246” and such engines are in-browser engines as the “visual editor” is running in the “browser 104” as seen in figures 1-2B and the 3D runtime engines are operating wholly in-browser as “rendering of, and interaction with, the embedded 3D project 268 in the web page 206 is enabled, in part, by an instance of the 3D runtime engines 210 (e.g., 3D runtime engine 210 2) running in the browser or web agent 204 1” and for example “the output of the 3D asset processor 242 can be composed to enable loading by the 3D runtime engine 210 1 for rendering in the browser 104 2” such that again it is clear that operations are occurring wholly in browser); and on a web page load request issued through the browser on the client's device (see McKegney, paragraphs 0044-0051 teaching “the 3D runtime engine 210 1 comprising the web-based 3D framework 230 that operates on certain backbone entities (e.g., 3D web project data 144) loaded at initialization of the 3D runtime engine 210 1 (e.g., at page load)”): loading the in-browser simulation application programming interface (API) and the simulation computer program code onto the client's device and importing the 3D object and at least one of the physics libraries to the client's device (see McKegney, paragraphs 0044-0051 teaching “3D runtime engine 210 1 handles the loading, rendering, and execution of web-based interactive 3D scenes” and “the 3D runtime engine 210 1 can include an asset load manager 232. The asset load manager 232 can help simplify loading of 3D assets for web designers. For example, many 3D assets comprise large volumes of data (e.g., for textures, models, animations, etc.)” and “When the 3D runtime engine 210 1 is initialized with a reference to a 3D project, the 3D runtime engine 210 1 can load the 3D project data (e.g., entity data, component data, etc.) associated with the 3D project into an asset registry 238” such that here this loads the simulation API and simulation code onto the clients device and imports the 3D objects being worked on); simulating the 3D object wholly in-browser using the in-browser simulation API, the in-browser rendering engine, and the in-browser physics engine having access to the imported physics library (see McKegney, paragraph 0043 teaching wholly in-browser execution of the relevant operations on the 3D object where the engines have access to the appropriate libraries to perform their functions as where “The rendering of, and interaction with, the embedded 3D project 268 in the web page 206 is enabled, in part, by an instance of the 3D runtime engines 210 (e.g., 3D runtime engine 210 2) running in the browser” and paragraph 0042 teaching “entity data 262 represents the building blocks of a 3D project and instances correspond to objects such as rendering library objects, textures, meshes, scenes, shots, cameras, events, etc. For example, in the “Three.js” rendering library, entity objects might include THREE.Texture, THREE.Object3D, etc. Entities can contains certain persisted settings, a loading state, and a reference to an underlying rendering library object.”); rendering the 3D object wholly in-browser in the client's browser (see McKegney, paragraph 0043 again teaching wholly in-browser execution of the rendering where “The rendering of, and interaction with, the embedded 3D project 268 in the web page 206 is enabled, in part, by an instance of the 3D runtime engines 210 (e.g., 3D runtime engine 210 2) running in the browser” ), and, for each subsequent frame: updating the in-browser rendered 3D object by using the physics engine in-browser to generate position and rotation data for the 3D object and sending that position and rotation data to the in-browser rendering engine (see McKegney, paragraph 0045 teaching “3D runtime engine 210 1 operates the main update and render loops of the interactive 3D scene and processes web page events (e.g., button clicks, object picks, etc.) associated with the 3D scene. For example, the 3D runtime engine 210 1 can process events that trigger object resize, focus, blur, etc”); the in-browser rendering engine updating wholly in-browser the rendered 3D object based on the position and rotation data received from the in-browser physics engine and displaying the updated rendered 3D object (see McKegney, paragraph 0045 teaching “3D runtime engine 210 1 operates the main update and render loops of the interactive 3D scene and processes web page events (e.g., button clicks, object picks, etc.) associated with the 3D scene. For example, the 3D runtime engine 210 1 can process events that trigger object resize, focus, blur, etc” and for example note paragraph 0048 teaching “Each component in the component library can listen to predefined events (e.g., specified by the web designer 105 1 in the visual editor 106 1), such as frame updates, window resizing, viewer input, etc. The component library 236 can further include built in components (e.g., a rotate component, an explode component, a translate/rotate/scale component, an animate component, etc.) to provide common functionality without demanding that the web designer write any code” such that again here the updates take place within the browser to render an updated rendered 3D object). Thus McKegney teaches the above applicable techniques showing that performing complex operations on 3D objects may be done wholly in-browser with in-browser rendering engines which is applicable to the Kokkevis system which also seeks to render and perform complex operations on a local computer under the control of a browser.
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify Kokkevis with the techniques of McKegney such that instead of performing the complex physics and rendering calculations utilizing a plugin, the operations of such engines can be done wholly in-browser as in McKegney where an in-browser 3D engine is utilized. Such a modification would be no more than applying a known technique to a known device ready for improvement to yield predictable results. Here one of ordinary skill in the art would have recognized that applying the known technique would yield the predictable result that instead of accessing a physics plugin that runs in a secure runtime environment locally as in Kokkevis the relevant libraries and rendering and physics engines would be obtained to execute at the behest of a 3D engine executing these in-browser components wholly in-browser. This would result in an improved system as it would eliminate installation needs and issues associated with plugin, eliminate a need to maintain compatibility with multiple browser plugin installation requirements and increase security by removing the known risks associated with the download and installation of plugins. Additionally, as suggested by McKegney, such web-based operation allows for “enabling a web designer to specify camera shots and interaction events of a web-based 3D scene without demanding 3D graphics programming” (see paragraph 0006) such that one of ordinary skill in the art would be motivated to modify Kokkevis to enable the same specification of physics, rendering or other simulation without demanding 3D graphics programming, instead taking advantage of such engines and API to perform such calculations.
With regard to the remaining limitations, McKegney as modified as explained above further teaches and in which the method comprises the steps of:
simulating wholly in-browser the 3D object using a multi- threading technique in the in-browser physics engine (note that multi-threading is interpreted as any technique in which multiple threads or sets of instructions or units of processing work are sharing the same processing resource; see Kokkevis, paragraphs 0052-0056 teaching such multi-threading being described where “physics engine 310 may include native code that executes directly on CPU 318 within the constraints set by the secure runtime environment. The execution of physics engine 310 on CPU 318 may thus provide 3D application 302 with real-time animation of objects within 3D application 302” and “3D application 302 coordinates the joint execution of physics engine 310 and rendering engine 312” and “specifically, 3D application 302 may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310. 3D application 302 may also facilitate the passing of data between plugin 304 and graphics plugin 306 using shared memory 308, as described below. On the other hand, plugin 304 and graphics plugin 306 may interface directly with one another to synchronize the animation and rendering of the graphics model” where “Graphics rendering and animation may continue to be provided by rendering engine 312 and physics engine 310 during execution of 3D application 302” and “3D application 302 may request the allocation of one or more IMC buffers 314-316 in a region of shared memory 308 by an IMC runtime provided by plugin 304 and/or graphics plugin 306. Graphics plugin 306 may then load data relevant to physics simulation into IMC buffers 314-316. For example, graphics plugin 306 may copy vertex positions, normals, triangle indices, and/or transformation matrices into IMC buffers 314-316” such that here threads for the physics simulation are run concurrently with threads of the rendering engine with both sharing memory and CPU resources while the physics engine also runs at the same time as rendering engine through the coordination of the 3D Application 302 facilitating this multi-threading of the work threads of the physics engine and rendering engine; additionally as modified by McKegney to utilize the wholly in-browser technique above McKegney’s in-browser operation of engines such as the physics engine uses a multi-threading technique in which input calls to the engine cause different threads of execution to be run such that invoking some call to change rendering or physics simulation triggers such multiple threads to be run concurrently as taught in paragraphs 0070-0078 further detailing the in-browser execution taught above where “one example of web page code 512 that can be included in a web page comprising an interactive 3D scene composed according to the herein disclosed techniques. Specifically, the web page code 512 can comprise certain loader scripts 272 2 (e.g., 3D.loader.js) that can be loaded from a server extStorage.com at page load. A project load call 274 2 (e.g., 3D.load) can further load project.json to the project canvas 276 2 (e.g., 3Dcanvas) in the body element of the page. The 3D runtime engine 210 3 (e.g., 3D-runtime-0.7.6.min.js) can also be included in the web page code 512 to render and enable interaction with the 3D scene. Specifically, the 3D runtime engine 210 3 can use the built-in selector code 534 and the custom button code 532 associated with the built-in shot selectors 434 2 and the custom button 432 2, respectively, to enable web page interaction with the 3D scene 506. As an example, when the “Reset” button (e.g., custom button 432 2) is clicked, the API call 3DAPI.events.trigger (‘resetScene’) is sent to the 3D runtime engine 210 3 to invoke a certain response corresponding to the event handler component having a resetScene listener. In some cases, the web page may want to listen to an event from the 3D runtime engine 210 3 using an API command such as 3DAPI.globalEvents.on(‘MyCustomEvent’,function( ){/*action*/})” such that any calls would be made in the same way including those as in paragraphs 0064-0065 teaching “the visual editor 106 3 can comprise a 3D scene setup window 402, a 3D component specification window 404, a 3D object selection window 406, and a scene shot window 408 that can receive interactions from the web designer 105 3 to define the shots and events. More specifically, the user interface view 4A00 exemplifies the web designer 105 3 specifying a first camera shot for a 3D scene by dragging and dropping a 3D object 410 from the 3D object selection window 406 to the 3D scene setup window 402. The web designer 105 3 can then select a camera (e.g., default camera “camera1”) for the first shot from certain cameras provided by the visual editor 106 3. Certain shot and/or camera attributes can then be specified. For example, the web designer 105 3 can use a mouse to adjust the position and/or orientation of the shot (see position “1”), and/or use the sliders in the 3D component specification window 404 to adjust other camera attributes (e.g., FOV, near plane, far plane, etc.) and set parameters. The web designer 105 3 might add further shots. Parameters are mapped into a shot template 405, as shown” such that each respect function corresponds to a thread carried out by the appropriate engine) and of compiling a version for each of a plurality of thread configurations, and on start of simulation, determining the version of thread configuration that is most suited to the client computer and running that version on the client computer (note that “compiling” as broadly recited here is interpreted to refer to any process whereby some source code is translated to another programming language; thus see Kokkevis, paragraphs 0052-0056 teaching “Physics engine 310 may be provided by 3D application 302 (e.g., downloaded over the Internet) and validated prior to execution in plugin 304” and “may include native code that executes directly on CPU 318 within the constraints set by the secure runtime environment” and “plugin 306 may then load data relevant to physics simulation into IMC buffers 314-316. For example, graphics plugin 306 may copy vertex positions, normals, triangle indices, and/or transformation matrices into IMC buffers 314-316” and “To animate the graphics model, physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306” and “Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data. Finally, the new data is read from IMC buffers 314-316 by graphics plugin 306 and used to update the graphics model. Rendering engine 312 may then pass the updated graphics model to GPU 320 for rendering” and “rendering engine 312 may render the graphics model at a frame rate specified by 3D application 302 and/or supported by GPU 320. As a result, physics engine 310 and rendering engine 312 may run at different frequencies. For example, physics engine 310 may run four times faster than rendering engine 312. As a result, the graphics model may be rendered once by rendering engine 312 for every four updates to the graphics model made by physics engine 310” such that here compiling for each of a plurality of thread configurations occurs when the 3D application 302 has commands translated to the native code module by the respective plugin to cause the plug to for example “load data relevant to physics simulation into IMC buffers 314-316” such that this is a plurality of thread configurations being compiled as the original command from the 3D application 302 is performed by the plugin instead and the thread version that is most suited to the client computer is chosen and run for that computer such as for example shown where “rendering engine 312 may render the graphics model at a frame rate specified by 3D application 302 and/or supported by GPU 320. As a result, physics engine 310 and rendering engine 312 may run at different frequencies. For example, physics engine 310 may run four times faster than rendering engine 312. As a result, the graphics model may be rendered once by rendering engine 312 for every four updates to the graphics model made by physics engine 310” such that here the system requirements are used to determine the most suitable arrangement of threads such as running certain threads on the GPU and certain threads on the CPU for rendering and physics for example; see also paragraph 0048 teaching “plugin 108 and/or native code module 118 may also include mechanisms for executing on a variety of instruction set architectures, including the use of “fat binaries” and binary translators” such that as explained above, the plugin is able to translate a variety of instructions from the 3D application 302; furthermore note that again as already modified Kokkevis in view of McKegney already teaches such a limitation in the combination above as in paragraphs 0045-0047 which specifically teach such a concept where “3D runtime engine 210 1 also contains a reference to the current renderer (e.g., browser) and device (e.g., desktop computer, tablet, smart phone, etc.) capabilities” and “when the 3D runtime engine 210 1 invokes the loading of the 3D project data for a given embedded 3D project, the hardware detector 234 can detect the capabilities of the current platform and load the appropriate version of the data. For example, certain texture sizes, compression formats, and/or shader features might be selected based on the current platform detected”).
Regarding claim 2, Kokkevis as modified teaches all that is required as applied to claim 1 above and further teaches in which the step of importing the physics library to the client’s device comprises importing a subset of the available physics libraries to the client’s device (see Kokkevis as modified, with Kokkevis already at paragraphs 0052-0058 teaching “3D application 302 may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310” and “Graphics plugin 306 may then load data relevant to physics simulation into IMC buffers 314-316” such that this “data relevant to physics simulation” is a subset of relevant (for example as opposed to the irrelevant unloaded models) physics libraries which is imported to the IMC buffer 204 as they are fetched in accordance with their use with an object and furthermore for example “To animate the graphics model, physics engine 310 may read from IMC buffers 314-316 to create a physics model corresponding to the graphics model in graphics plugin 306. Additional information related to the physics model, such as parameters, may be obtained from 3D application 302 by plugin 304. Next, physics engine 310 may perform a series of physics simulation calculations that update the physics model. For example, physics engine 310 may calculate vertex positions and velocities based on a set of forces acting on objects in the physics model. Plugin 304 may then update IMC buffers 314-316 with new vertex positions, velocities, and/or other data. Finally, the new data is read from IMC buffers 314-316 by graphics plugin 306 and used to update the graphics model” such that here again the libraries imported are a subset of the physics simulation information as only the relevant simulation information is updated and where McKegney has already been combined and shown to teach such importing of the relevant libraries when running the 3D engine wholly in-browser).
Regarding claim 3, Kokkevis as modified teaches all that is required as applied to claim 2 above and further teaches in which the method comprises the step of determining which of the physics libraries is required for simulation of the 3D object and importing only those physics libraries required for the simulation of that 3D object (see Kokkevis, paragraphs 0052-0058 where as explained above a subset of the libraries is determined corresponding to the data relevant to the physics simulation which is imported to the IMC buffers as the objects is updated in the simulation as “3D application 302 may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310” and “Graphics plugin 306 may then load data relevant to physics simulation into IMC buffers 314-316” such that this “data relevant to physics simulation” is that required for the simulation and is the only collection of data imported and again Kokkevis has already been modified in respect to this limitation as McKegney also teaches to import the relevant libraries required for rendering and simulating the 3D object as in paragraph 0042 teaching “entity data 262 represents the building blocks of a 3D project and instances correspond to objects such as rendering library objects, textures, meshes, scenes, shots, cameras, events, etc. For example, in the “Three.js” rendering library, entity objects might include THREE.Texture, THREE.Object3D, etc. Entities can contains certain persisted settings, a loading state, and a reference to an underlying rendering library object”).
Regarding claim 4, Kokkevis as modified teaches all that is required as applied to claim 1 above and further teaches storing the 3D object and the physics libraries on a content provider’s web server (see Kokkevis, paragraph 0026 teaching “the web application may be downloaded over the Internet from a website” and paragraphs 0029-0031 teaching “computing system 102 may obtain web application 116 from one or more servers (e.g., server 1 104, server x 106) using a network connection with the server(s) and load web application 116 in web browser 110. For example, web application 116 may be downloaded from an application server over the Internet by web browser 110” and “To provide computationally intensive features to the user, a native code module 118 associated with web application 116 may be used to execute computationally intensive code on behalf of web application 116. Like web application 116, native code module 118 may be obtained from one or more servers (e.g., server 1 104, server x 106) by web browser 110. For example, web application 116 may provide a hyperlink to native code module 118 on the Internet. Web browser 110 may then download native code module 118 from the Uniform Resource Locator (URL) specified in the hyperlink” such that here the content which includes the web application 3D modeling program and associated files and the physics libraries is from the “servers” which are web servers providing content ).
Regarding claim 5, Kokkevis as modified teaches all that is required as applied to claim 1 above and further teaches the method comprises the step of storing the in-browser simulation application programming interface (API) and the simulation computer program code in a content delivery network (CDN) (see Kokkevis, paragraph 0026 teaching “the web application may be downloaded over the Internet from a website” and paragraphs 0029-0031 teaching “computing system 102 may obtain web application 116 from one or more servers (e.g., server 1 104, server x 106) using a network connection with the server(s) and load web application 116 in web browser 110. For example, web application 116 may be downloaded from an application server over the Internet by web browser 110” and “To provide computationally intensive features to the user, a native code module 118 associated with web application 116 may be used to execute computationally intensive code on behalf of web application 116. Like web application 116, native code module 118 may be obtained from one or more servers (e.g., server 1 104, server x 106) by web browser 110. For example, web application 116 may provide a hyperlink to native code module 118 on the Internet. Web browser 110 may then download native code module 118 from the Uniform Resource Locator (URL) specified in the hyperlink” and as in paragraph 0052 and figure 3 the “3D application 302 may correspond to a web application that executes in a web browser 300. In addition, 3D application 302 may provide 3D graphics rendering and animation capabilities to a user of 3D application. For example, 3D application 302 may be a 3D computer game, CAD system, and/or a scientific modeling and/or simulation application” such that again the simulation API and the simulation computer program code come from the server network providing content delivery services such that these function as a content delivery network and note that Kokkevis as modified by McKegney is compatible with such storing and also teaches such storing of the API and simulation code in a CDN as in paragraphs 0045-0049 teaching “the 3D runtime engine 210 1 comprising the web-based 3D framework 230 that operates on certain backbone entities (e.g., 3D web project data 144) loaded at initialization of the 3D runtime engine 210 1 (e.g., at page load). The 3D runtime engine 210 1 handles the loading, rendering, and execution of web-based interactive 3D scenes” and “the 3D runtime engine 210 1 can include an asset load manager 232. The asset load manager 232 can help simplify loading of 3D assets for web designers. For example, many 3D assets comprise large volumes of data (e.g., for textures, models, animations, etc.)”).
Regarding claim 6, Kokkevis teaches all that is required as applied to claim 1 above and further teaches the step of running the in-browser physics engine in a web worker (note that a web worker can be recognized as a term of art that corresponds to some javascript element that runs in the background independently of other scripts in a manner that does not affect the page viewing performance for example and essentially may be interpreted as a worker for the web site; thus see Kokkevis, paragraphs 0052-0058 teaching “3D application 302 may be written in a web-based scripting language such as Javascript” and “Physics engine 310 may be provided by 3D application 302 (e.g., downloaded over the Internet) and validated prior to execution in plugin 304. Moreover, physics engine 310 may include native code that executes directly on CPU 318 within the constraints set by the secure runtime environment. The execution of physics engine 310 on CPU 318 may thus provide 3D application 302 with real-time animation of objects within 3D application 302” and “3D application 302 coordinates the joint execution of physics engine 310 and rendering engine 312” and “specifically, 3D application 302 may make method calls to both plugin 304 and graphics plugin 306 for loading a graphics model into rendering engine 312 and a corresponding physics model into physics engine 310. 3D application 302 may also facilitate the passing of data between plugin 304 and graphics plugin 306 using shared memory 308, as described below. On the other hand, plugin 304 and graphics plugin 306 may interface directly with one another to synchronize the animation and rendering of the graphics model” where “Graphics rendering and animation may continue to be provided by rendering engine 312 and physics engine 310 during execution of 3D application 302” such that as already combined with McKegney above the physics engine of Kokkevis is operating in-browser as in McKegney and as such is running as a web worker as the in-browser 3D operations operate as web workers as paragraphs 0057-0070 teaching “the web pages associated with the web application have been built (see step 318) and the 3D embed code included, certain 3D interface controls in one or more web pages can be connected to the embedded 3D project (see step 320). Such connections