CTFR 17/553,651 CTFR 90164 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 Claims 1-29 are pending. Claims 1-5, 7-8, 11-12, 15, and 21-22, and 28 are amended. Response to Arguments 07-37 AIA Applicant's arguments filed 2/19/2026 have been fully considered but they are not persuasive. Applicant argues – Without conceding to the appropriateness of the rejection, Applicant amends claim 1 to recite, in part, "the seamless cubemap filtering is not applied to one or more other objects created without the flag being set." Applicant respectfully submits that the proposed combination of Kim, Cubemap, and OpenGL does not teach or suggest such subject matter For example, OpenGL describes that "[w]hen sampling from cube map textures, a three- dimensional texture coordinate is used to select one of the cube map faces and generate a two dimensional texture coordinate (s t ), at which a texel is sampled from the determined face of the cube map texture. Each face of the texture is treated as an independent two-dimensional texture, and the generated ( s t) coordinate is subjected to the same clamping and wrapping rules as for any other two dimensional texture fetch." OpenGL at p. 1. Further for example, OpenGL describes that "[s]eamless cube map filtering is enabled or disabled by calling Enable or Disable, respectively, with the symbolic constant TEXTURE_CUBE_MAP_SEAMLESS." OpenGL at p. 2. OpenGL further describes that "[t]he required state is one bit indicating whether seamless cube map filtering is enabled or disabled." OpenGL at p. 2. Thus, while OpenGL describes enabling or disabling a filter, the filter operates according to a global state controlling cube map sampling, rather than according to a per-texture setting. In OpenGL, it appears that seamless cube map filtering is controlled by a single state bit that affects cube map sampling generally and is not described as being associated with an individual texture or set at texture creation. Therefore, OpenGL does not disclose, teach, or suggest "a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call," and "wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set," as recited in claim 1. Kim and Cubemap fail to cure these deficiencies of OpenGL. For at least the reasons discussed above, Applicant respectfully submits that the proposed combination of Kim, Cubemap, and OpenGL, does not teach such subject matter as recited in claim 1. Accordingly, for at least the foregoing reasons, Applicant respectfully submits that claim 1 is allowable under 35 U.S.C. § 103 over Kim in view of Cubemap and OpenGL. Withdrawal of the pending rejection under 35 U.S.C. § 103 is, therefore, respectfully requested. [Underlining added by Examiner] Examiner disagrees with Applicant’s arguments and conclusions drawn therefrom. Applicant asserts that “ OpenGL describes that "[w]hen sampling from cube map textures, a three- dimensional texture coordinate is used to select one of the cube map faces and generate a two dimensional texture coordinate (s t ), at which a texel is sampled from the determined face of the cube map texture. Each face of the texture is treated as an independent two-dimensional texture, and the generated ( s t) coordinate is subjected to the same clamping and wrapping rules as for any other two dimensional texture fetch. ” Therefore, by applicant’s own admission OpenGL indeed discloses enabling or disabling a filter, wherein the filter operates according to a per-texture basis to attain the overall filtering effect. For details see the rejection below . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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 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. 07-20-aia AIA 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 of this title, 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. 07-21-aia AIA Claim s 1-21, 23, 25, 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over et al. (US 20160300381 A1, hereinafter Kim) in view of UnityCubemap (Unity Cubemap API documentation is attached herein, which is retrieved from https://docs.unity3d.com/2020.3/Documentation/ScriptReference/Cubemap.html . Citations are given from version 2020.3 released in 2020) and further in view of OpenGL (OpenGL documentation about CubeMap sampling, published on 7/21/2009, https://registry.khronos.org/OpenGL/extensions/ARB/ARB_seamless_cube_map.txt; hereinafter OpenGL). Regarding claim 1, Kim discloses a non-transitory machine-readable medium having stored thereon instructions that, if performed by one or more processors, causes the one or more processors to (Abstract, ¶0238 ) at least: in response to, an application programming interface ("API") call: generate one or more three-dimensional (3D) graphics objects ( The GPU calls an API 430 with regard to the nodes G1, G3, G4 and G5 of the graphic layer tree 420, and the results from process by the call of the API 430 are respectively loaded to textures T1, T3, T4 and T5 of the video memory 440 , ¶0134. On the other hand, the call of the API 470, rendering of the texture and display of an image are performed by the GPU , ¶0146. Graphics object could be 3D graphics object like Cubemap, ¶210-0213) ; and apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call, wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set. Kim is not found disclosing explicitly the limitation of apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call. However, UnityCubemap discloses scripting API provided by Unity Engine, wherein a cubemap 3D graphics object and/or asset to be instantiated in a graphics application. Cubemap scripting API function allows creating and modifying the features to create, e.g., a seamless cubemap. E.g., see figure 1, where the description reads Class for handling cube maps, Use this to create or modify existing cube map assets . For example, public Method SmoothEdges discloses, p erforms smoothing of near edge regions ( see figure 2 below ). OpenGL on the other hand discloses that a when sampling from cube map textures, a three-dimensional texture coordinate is used to select one of the cube map faces and generate a two dimensional texture coordinate ( s t ), at which a texel is sampled from the determined face of the cube map texture. Each face of the texture is treated as an independent two-dimensional texture, and the generated ( s t ) coordinate is subjected to the same clamping and wrapping rules as for any other two dimensional texture fetch. Although it is unlikely that the generated (s t ) coordinate lies significantly outside the determined cube map face, it is often the case that the locations of the individual elements required during a linear sampling do not lie within the determined face, and their coordinates will therefore be modified by the selected clamping and wrapping rules. This often has the effect of producing seams or other discontinuities in the sampled texture. This extension allows implementations to take samples from adjacent cube map faces, providing the ability to create seamless cube maps . TEXTURE_CUBE_MAP_SEAMLESS functions as a flag, enabling which creates a seamless cubemaps 3d object. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to instantiate and/or implement the cubemap 3D graphics object of Kim ( Kim ¶0210-0213 ), in a graphics application like a game (see ¶0007 of Kim, ‘For example, there is a 3D graphic object generally applied to a game or the like’ ), according to the API support ( see Kim ¶0134 ) using the UnityEngine’s scripting API support provided for Cubemap graphics object such that filtering can be applied on the cubemap object using SmoothEdges scripting API interface available under the public method, and further applying a seamless cubemapping approach to the texture of the 3d graphics object according to TEXTURE_CUBE_MAP_SEAMLESS of OPENGL functioning as a flag, to obtain, apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call, wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set, because, combining prior art elements ready to be improved according to known method to yield predictable results is obvious. Furthermore, such combination would enhance the versatility of the overall system. PNG media_image1.png 724 1028 media_image1.png Greyscale Figure 1 – Cubemap graphic object scripting API interface provided under UnityEngine PNG media_image2.png 416 778 media_image2.png Greyscale Figure 2 – SmoothEdges public method of API interface allows performing smoothing of the near edge regions of cubemap 3D graphics objects instantiated withing a graphics application Regarding claim 2, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein the one or more 3D graphics objects comprises a seamless cubemap and a parameter to the API indicates that one or more filters are to be applied to the seamless cubemap (See OpenGL reference provided above. Also, see smoothEdges method of Unity3d, according to figure 1, where the description reads PNG media_image3.png 472 702 media_image3.png Greyscale Figure 3 – SmoothEdges public method API provides affordances to implement edge smoothening (understood as filtering) up until a gives pixel distances from the cube edges. Class for handling cube maps, Use this to create or modify existing cube map assets . Public method SmoothEdges disclose, Performs smoothing of near edge regions , which is understood as method for creating seamless cubemap having smooth edges. See following figure 2, for Public Methods. Also see fig. 3 below). Regarding claim 3, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein application of the seamless cubemap filtering to the one or more 3D graphics objects is enabled by a Boolean variable value provided as a parameter to the API (See OpenGL documentation provided above. Also see Unity3D documentation for, Boolean variable ‘bool’, != and == are included in an API function which enables creation and modification of the Cubemap object. See fig. 4 ). PNG media_image4.png 157 714 media_image4.png Greyscale Fig. 4 – Unity 3D Operator for cubemap Regarding claim 4, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein one or more filters are applied to the one or more 3D graphics objects created (See OpenGL documentation provided above. Also see Unity3D documentation for, the scripting API provides public method interfaces called “SmoothEdges” which applies smoothing filtering along the seams or edges of the created Cubemap 3D object created by performance of the scripting API provided under UnityEngine. See combination of references in claim 1 rejection above ). Regarding claim 5, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein creation of the one or more 3D graphics objects and an indication of one or more filters occurs in response to an individual invocation of the API (See OpenGL documentation provided above. Also see Unity3D documentation for, this limitation is understood met, since when instantiation of the Cubemap through scripting API is made with proper arguments, the 3D cubemap class is constructed first according to the constructor method and modified as well using the passed on arguments provided in the API interface ). Regarding claim 6, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein the one or more processors are further to apply one or more filters specifically to the one or more 3D graphics objects created (See OpenGL documentation provided above. Also see Unity3D documentation for, since public method “SmoothEdges” is part of Cubemap Class instantiated and later updated by API the smoothening function can be applied to the specific cubemap graphics object and/or asset created under the three-dimensional (3D) graphics objects generated by the scripting API provided under UnityEngine). Regarding claim 7, Kim in view of UnityCubemap and OpenGL discloses the non-transitory machine-readable medium of claim 1, wherein creation of the one or more 3D graphics objects and an indication of one or more filters is enabled by the flag provided as a parameter to the API (See OpenGL documentation provided above. Also see Unity3D documentation for, this limitation is understood met, since when instantiation of the Cubemap API is made with proper arguments, the 3D cubemap class is constructed first according to the constructor and modified as well using the passed on arguments provided in the AP interface - ‘hideflag’ is used as a flag that is contained in API when instantiated with this argument enabled. See fig. 4 for ‘hideflag’ method ). Regarding claim 8 although wording is different, the material is considered significantly similar to claim 1 as discussed above. Regarding claim 9, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, wherein: the one or more 3D graphics objects comprise a seam, and an application of one or more filters makes the seam appear nonexistent ( See OpenGL documentation provided above. Also see Unity3D documentation for, figure 1, where the description reads Class for handling cube maps, Use this to create or modify existing cube map assets . Public method SmoothEdges disclose, Performs smoothing of near edge regions , which is understood as method for creating seamless cubemap having smooth edges. See following figure 2, for Public Methods. Also see fig. 3 below. Since edge seams are smoothed, it is understood that seams appear nonexistent) . Regarding claim 10, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, further comprising: including a Boolean variable within a set of Boolean variables for the API to control creation and modification of features of the one or more 3D graphics objects ( See OpenGL documentation provided above. Also see Unity3D documentation for, Boolean variable ‘bool’, != and == are included in an API function which enables creation and modification of the Cubemap object. See fig. 4 above. A set of Boolean variable is understood met in implementation where multiple cubemaps are instantiated and/or created ). Regarding claim 11, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, wherein: the applying seamless cubemap filtering is not globally applied (since the API call is directed for 3d graphics objects, it is not Globally applied to the entire scene, and rather is applied only to the 3d graphics objects created through the API call). Regarding claim 12, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, further comprising: setting parameters for the one or more objects includes setting parameters for the generating of the one or more 3D graphics objects and the applying of the seamless cubemap filtering ( See OpenGL documentation provided above. Also see Unity3D documentation for, Cubemap AP interface provides multiple parameters [e.g., height, width, wrapmode … etc.] settable for the generating of the one or more 3D graphics Cubemap objects, and “SmoothEdge” public method API indicates that the one or more filters are to be applied to the one or more 3D graphics Cubemap objects features. See figs. 1-3). Regarding claim 13, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, wherein the API enables the application of the seamless cubemap filtering to the one or more 3D graphics objects ( Cubemap API enables the application of the one or more filters to the one or more 3D graphics Cubemap objects through SmoothEdges public method interface). Regarding claim 14, Kim in view of UnityCubemap and OpenGL discloses the method of claim 8, wherein: the applying seamless cubemap filtering is optionally applied on a per texture basis (texture call creates the cubemap object capable of applying cubemap filtering therein, therefore, it is understood that seamless cubemap filtering is optionally applied on a per texture basis). Regarding claim 15, Kim discloses One or more processors (Kim: abstract, ¶0009-0017, fig. 3 CPU and/or GPU), comprising: circuitry to, in response to an application programming interface ("API") call generate a one or more three-dimensional (3D) graphics objects ( The GPU calls an API 430 with regard to the nodes G1, G3, G4 and G5 of the graphic layer tree 420, and the results from process by the call of the API 430 are respectively loaded to textures T1, T3, T4 and T5 of the video memory 440, ¶0134. On the other hand, the call of the API 470, rendering of the texture and display of an image are performed by the GPU, ¶0146. Graphics object could be 3D graphics object like Cubemap, ¶210-0213 )., and apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set. Kim’s disclosure of loading 3d graphics object could possibly be understood as generate a one or more three-dimensional (3D) graphics objects and apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call , however an explicit mention thereof is found withing Kim. However, UnityCubemap discloses scripting API provided by Unity Engine, wherein a cubemap 3D graphics object and/or asset to be instantiated in a graphics application. Cubemap scripting API function allows creating and modifying the features to create, e.g., a seamless cubemap. E.g., see figure 1, where the description reads Class for handling cube maps, Use this to create or modify existing cube map assets . For example, public Method SmoothEdges discloses, p erforms smoothing of near edge regions ( see figure 2 above). OpenGL on the other hand discloses that a when sampling from cube map textures, a three-dimensional texture coordinate is used to select one of the cube map faces and generate a two dimensional texture coordinate ( s t ), at which a texel is sampled from the determined face of the cube map texture. Each face of the texture is treated as an independent two-dimensional texture, and the generated ( s t ) coordinate is subjected to the same clamping and wrapping rules as for any other two dimensional texture fetch. Although it is unlikely that the generated ( s t ) coordinate lies significantly outside the determined cube map face, it is often the case that the locations of the individual elements required during a linear sampling do not lie within the determined face, and their coordinates will therefore be modified by the selected clamping and wrapping rules. This often has the effect of producing seams or other discontinuities in the sampled texture. This extension allows implementations to take samples from adjacent cube map faces, providing the ability to create seamless cube maps . Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to instantiate and/or implement the cubemap 3D graphics object of Kim (Kim ¶0210-0213), in a graphics application like a game (see ¶0007 of Kim, ‘For example, there is a 3D graphic object generally applied to a game or the like’ ), according to the API support (see Kim ¶0134) using the UnityEngine’s scripting API support provided for Cubemap graphics object such that filtering can be applied on the cubemap object using SmoothEdges scripting API interface available under the public method, and further applying a seamless cubemapping approach to the texture of the 3d graphics object, to obtain, apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set , because, combining prior art elements ready to be improved according to known method to yield predictable results is obvious. Furthermore, such combination would enhance the versatility of the overall system. Regarding claim 16, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: the one or more 3D graphics objects comprise texels (See OpenGL documentation provided above. Also see Unity3D documentation for, Cubemap inherits from “Texture” class, and thus all texture elements are understood as texels), one or more features of the one or more 3D graphics objects is a seam (See OpenGL documentation provided above. Also see Unity3D documentation for, as API creates cubemap, the intersection of sides meet in a seam), and creation and modification of the seam uses at least one texel from adjacent faces of texels that meet at the seam (See OpenGL documentation provided above. Also see Unity3D documentation for, ‘smoothEdges’ methods performs smoothing of near edge regions, which is understood as meeting the limitation. See figs. 1-3 above). Regarding claim 17, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: the circuitry reads a variable included in an API function to control creation and modification of one or more features of the one or more 3D graphics objects (See OpenGL documentation provided above. Also see Unity3D documentation for, ‘bool’ variable included in an API function that creates cubemap, can also be used to control the creation and modification of the features). Regarding claim 18, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: the circuitry creates and modifies one or more features for each of the one or more 3D graphics objects (See OpenGL documentation provided above. Also see Unity3D documentation for, each instance of the cubemap creates and modifies features of each of the 3D graphics respectively). Regarding claim 19, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: the API receives parameters for generating one or more features of the one or more 3D graphics objects (See OpenGL documentation provided above. Also see Unity3D documentation for, this limitation is understood met, since when instantiation of the Cubemap API is made with proper arguments/parameters, the 3D cubemap class is constructed first according to the constructor and modified as well using the passed on arguments/parameters provided in the AP interface ). Regarding claim 20, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: the circuitry reads the flag to control a feature indicating that one or more filters are to be applied to features of the one or more 3D graphics object (See OpenGL documentation provided above. Also see Unity3D documentation for, this limitation is understood met, since when instantiation of the Cubemap API is made with proper arguments, the 3D cubemap class is constructed first according to the constructor and modified as well using the passed on arguments provided in the AP interface - ‘hideflag’ is used as a flag that is contained in API when instantiated with this argument enabled. See fig. 4 for ‘hideflag’ method ). Regarding claim 21, Kim discloses a system ( fig. 3 ), comprising: one or more processors to in response to, an application programming interface ("API") call: generate one or more three-dimensional (3D) graphics objects; and apply seamless cubemap filtering on a texture of the one or more 3D graphics objects based, at least in part, on a flag being set in the API, the flag indicating that the seamless cubemap filtering should be applied to the texture of the one or more 3D graphics objects created in response to the API call, wherein the seamless cubemap filtering is not applied to one or more other objects created without the flag being set (see substantively similar claim 1 rejection above). Regarding claim 23, Kim in view of UnityCubemap and OpenGL discloses the system of claim 21, wherein: one of the one or more 3D graphics objects is a mimapped cubemap (see Properties section, e.g. ‘desiredMipmapLevel’ and other properties in fig. 2 above). Regarding claim 25, Kim in view of UnityCubemap discloses the system of claim 21, wherein: an application of one or more filters comprises seamless cubemapping and occurs in response to a flag received by the API (see OpenGL documentation above). Regarding claim 27, Kim in view of UnityCubemap and OpenGl discloses the system of claim 21, wherein: the API causes seamless cubemapping to be performed with a specific graphics object filtering mode set by the API ( specific graphics object filtering mode set in the API is understood implemented in method smoothEdges; that performs seamless cubemapping). Regarding claim 28, Kim in view of UnityCubemap and OpenGL discloses the one or more processors of claim 15, wherein: an application of one or more filters comprises seamless cubemapping and occurs in response to a flag received by the API(See OpenGL documentation provided above. Also see Unity3D documentation for, this limitation is understood met, since when instantiation of the Cubemap API is made with proper arguments, the 3D cubemap class is constructed first according to the constructor and modified as well using the passed on arguments provided in the AP interface - ‘hideflag’ is used as a flag that is contained in API when instantiated with this argument enabled. See fig. 4 for ‘hideflag’ method ) . 07-21-aia AIA Claim s 22 is rejected under 35 U.S.C. 103 as being unpatentable over Kim et in view of UnityCubemap and OpenGL and further in view of Ren et al. (US 20140267346 A1, hereinafter Ren) . Regarding claim 22, Kim in view of UnityCubemap and OpenGL discloses the system of claim 21, wherein: the one or more 3D graphics objects comprise texels (Cubemap inherits from “Texture” class, and thus all texture elements are understood as texels), the one or more 3D graphics objects comprise a seam (As API creates cubemap, the intersection of sides meet in a seam), the generation of the one or more 3D graphics objects and the indication that the one or more filters are to be applied to the one or more 3D graphics objects of uses ( see figure 1, where the description reads Class for handling cube maps, Use this to create or modify existing cube map assets . Public method SmoothEdges disclose, Performs smoothing of near edge regions , which is understood as method for creating seamless cubemap having smooth edges. See following figure 2, for Public Methods. Also see fig. 3 below) an average of at least two texel values from at least adjacent faces of texels that meet at the seam. Kim in view of UnityCubemap is not found disclosing expressly that the smoothening at the edge of the cubemap object is probably done through averaging the pixel or texels around the edge seam ( see fig. 3 above ). However, the operational details of the pixel/texel smoothening is not described expressly the Unity manual. Nevertheless, Ren discloses that the color of this texel is usually the average color of the original texture tile, which introduces the seam artifact as the color is different from the border color of the original texture tile (¶ 0039 ). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to implement the smoothening operation of the seam in UnityEngine using averaging of the texel values around the seam as disclosed by Ren, because, combining prior art elements ready to be improved according to known method to yield predictable results is obvious . 07-21-aia AIA Claim s 26 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Kim et in view of UnityCubemap and OpenGL and further in view of OpenGL and Nordquist et al. (US 7948495 B1, hereinafter Nordquist) . Regarding claim 29, Kim in view of UnityCubemap and OpenGL discloses the processor of claim 21, wherein: except the API is a driver API, and the application of the one or more filters comprises seamless cubemapping and occurs with a graphics object filtering mode of the API set to linear filtering. However, OpenGL discloses that a when sampling from cube map textures, a three-dimensional texture coordinate is used to select one of the cube map faces and generate a two dimensional texture coordinate ( s t ), at which a texel is sampled from the determined face of the cube map texture. Each face of the texture is treated as an independent two-dimensional texture, and the generated ( s t ) coordinate is subjected to the same clamping and wrapping rules as for any other two dimensional texture fetch. Although it is unlikely that the generated ( s t ) coordinate lies significantly outside the determined cube map face, it is often the case that the locations of the individual elements required during a linear sampling do not lie within the determined face, and their coordinates will therefore be modified by the selected clamping and wrapping rules. This often has the effect of producing seams or other discontinuities in the sampled texture. This extension allows implementations to take samples from adjacent cube map faces, providing the ability to create seamless cube maps . OpenGL further discloses – TEXTURE_CUBE_MAP_SEAMLESS functions as a flag, enabling which creates a seamless cubemaps 3d object. OpenGL further discloses, When seamless cube map filtering is enabled, the rules for texel selection in sections 3.8.9 through 3.8.10 are modified so that texture wrap modes are ignored. Instead, * If NEAREST filtering is done within a miplevel, always apply wrap mode CLAMP_TO_EDGE. * If LINEAR filtering is done within a miplevel, always apply wrap mode CLAMP_TO_BORDER. Then, … Nordquist on the other hand discloses that OpenGL graphics API is a driver API (Col. 4, lines 56-59). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention (AIA) to implement the Cubemapping of UnityCubemap using OpenGL graphics driver API, setting the cubemapping in a linear filtering mode, because, simple substitution of one known element for another and/or combining prior art elements ready to be improved according to known method to yield predictable results is obvious. Regarding method claim(s) 26, although wording is different, the material is considered substantively equivalent to the system claim(s) 29 as described above . Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim (s) 24 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. 13-03-01 AIA The following is a statement of reasons for the indication of allowable subject matter: Regarding claim 24, Kim in view of UnityCubemap and OpenGL discloses the system of claim 21, wherein: the one or more 3D graphics objects comprise cubemaps (the asset or 3d object is Cubemap, see fig. 2 above. Also see ¶0210-0213 of Kim), the cubemaps comprise faces and seams (cubemap is a cuboid texture having faces and edges, see e.g., public methods “smoothEdges” and “GetPixelData”. Also see fig. 5 below for Cubemap.GetPixelData, which has face as a parameter). PNG media_image5.png 364 808 media_image5.png Greyscale Figure 5 – face is a parameter of cubemap.GetPixelData public method AnisoLevel property of texture also defines the anisotropic filtering level of the Texture (in this instance, texture is the cubemap object. See figure 6 below). However, Prior arts of record taken alone or in combination fails to reasonably disclose or suggest that, the one or more processors are further to filter the cubemap faces anisotropically and filter the cubemap seams isotropically . PNG media_image6.png 602 818 media_image6.png Greyscale Conclusion 07-40 AIA Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL . See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to NURUN FLORA whose telephone number is (571)272-5742. The examiner can normally be reached M-F 9:30 am -5:00 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jason Chan can be reached at (571) 272-3022. 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. /NURUN FLORA/Primary Examiner, Art Unit 2619 Application/Control Number: 17/553,651 Page 2 Art Unit: 2619 Application/Control Number: 17/553,651 Page 3 Art Unit: 2619 Application/Control Number: 17/553,651 Page 4 Art Unit: 2619 Application/Control Number: 17/553,651 Page 5 Art Unit: 2619 Application/Control Number: 17/553,651 Page 6 Art Unit: 2619 Application/Control Number: 17/553,651 Page 7 Art Unit: 2619 Application/Control Number: 17/553,651 Page 8 Art Unit: 2619 Application/Control Number: 17/553,651 Page 9 Art Unit: 2619 Application/Control Number: 17/553,651 Page 10 Art Unit: 2619 Application/Control Number: 17/553,651 Page 11 Art Unit: 2619 Application/Control Number: 17/553,651 Page 12 Art Unit: 2619 Application/Control Number: 17/553,651 Page 13 Art Unit: 2619 Application/Control Number: 17/553,651 Page 14 Art Unit: 2619 Application/Control Number: 17/553,651 Page 15 Art Unit: 2619 Application/Control Number: 17/553,651 Page 16 Art Unit: 2619 Application/Control Number: 17/553,651 Page 17 Art Unit: 2619 Application/Control Number: 17/553,651 Page 18 Art Unit: 2619 Application/Control Number: 17/553,651 Page 19 Art Unit: 2619 Application/Control Number: 17/553,651 Page 20 Art Unit: 2619 Application/Control Number: 17/553,651 Page 21 Art Unit: 2619
Prosecution Insights