DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
With respect to the Applicant’s argued rejection under 35 § U.S.C. 101 in “Pre-Appeal Brief Conference Request,”
Applicant argues:
All claims stand rejected under § 101 as purportedly being directed to abstract ideas. Appellant respectfully disagrees because the claims are directed to improvements in computer-based technology.
Streamlined Eligibility Analysis
A streamlined eligibility analysis can be used "when the eligibility of the claim is self-
evident, e.g., because the claim clearly improves a technology or computer functionality." MPEP 2106.06. Here, the claims are directed to a clear improvement in the inherently computer-based technology of computer aided design (CAD) exchange. As explained in Appellant's originally filed specification, it is generally known that "a CAD design can represent a mechanical design as one or more CAD bodies," but "[e]xchanging these bodies between different systems has traditionally challenged CAD" as a field. [0003]. "For example, to generate a physical prototype of [an] item, or to manufacture the item, the corresponding CAD body/bodies can be exchanged with a 3-D printer or computer numerical control (CNC) machine … How CAD bodies are exchanged is an important process for accurate building of parts, particularly for downstream applications along the design to manufacturing process. The goal is to have a compatible CAD file format for downstream use in other programs." [0004]. "Unfortunately, due to nuanced differences in geometry representations," the transfer of the geometry from one system to another "is inherently unreliable." [0005]. Furthermore, "due to differences in the semantics of the programs that produce the geometry output, it is not possible to reliably transfer the various steps used to generate a given CAD body, according to conventional approaches." Id. See also [0006]-[0007].
Taking independent claim 1 as an example, the claimed method addresses these
computer-based problems in CAD technology with steps such as determining one or more implicit equations/functions for one or more CAD bodies; expressing the one or more implicit
equations/functions as code; and providing the code to a target system. The claimed method
enables CAD exchange to be accomplished with a smaller data transfer than in conventional
methods, increases precision by avoiding the need for making approximations, enables easy
consumption and use at the target system by using code as the exchange medium rather than
"an unwieldly and/or poorly structured data format," and "allow[s] for increased editability at a
target [system], including allowing for replayability and parametric editing with respect to the
exchanged CAD body." 1 [0009]. See also [0055]-[0056].
Additionally, because sharing code "can introduce the potential for malicious behavior," [0047], the provided code of claim 1 includes at least some graphics processing unit (GPU) code
implemented with at least one security feature selected from the group consisting of (A) all logic
of the GPU code is first order; (B) the memory requirements for the GPU code are known at
compile time; and (C) the GPU code stipulates that it run on the target system in a sandboxed
execution environment that disallows operating system access. As explained at [0047], these
security features protect against specific computer-based risks, such as out-of-bounds memory
addressing or overflowing the stack.
Notably, these benefits are not improvements to a mental process, mathematical concept, or other abstract idea. Instead, the benefits - e.g., reduced data transfer, increased editability at the target system, increased precision, avoiding unwieldy data structures, avoiding the risk of overflowing the stack - are computer-related improvements to a computer-related technology. For at least this reason, the streamlined patent eligibility analysis is appropriate and is satisfied.
(see Response filed 10/28/2025 [pages 1-2]).
The examiner respectfully disagrees with applicant's argument that the streamlined eligibility analysis is appropriate and is satisfied.
As explained in MPEP § 2106.06, “a streamlined eligibility analysis (Pathway A) when the eligibility of the claim is self-evident, e.g., because the claim clearly improves a technology or computer functionality. However, if there is doubt as to whether the applicant is effectively seeking coverage for a judicial exception itself, the full eligibility analysis (the Alice/Mayo test described in MPEP § 2106, subsection III) should be conducted to determine whether the claim integrates the judicial exception into a practical application or recites significantly more than the judicial exception.”
In this case, the claims recite limitations such as determining, …, one or more implicit equations/functions for one or more CAD bodies; expressing, …, the implicit equations/functions as code. Under the broadest reasonable interpretation in light of specification, these limitations can be considered as mental process and mathematical concepts (mathematical relationships and equations). Therefore, the clams recite a judicial exception.
The additional limitations do not integrated the judicial exception into a practical application. For example, recitations of source computing system or target system merely implement the abstract idea on a generic computer, which mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP § 2106.05(f)). Further, the recitations of “providing, by the source computing system to a target system, the code” and “displaying, based on the provided code, the one or more CAD bodies at the target system” merely add insignificant extra-solution activity, such as data transmission and output presentation, which do not meaningfully limit the judicial exception (see MPEP § 2106.05(g)). Further, the recitations of the provided code allows for import of the one or more CAD bodies at the target system and the code includes CPU code implemented with at least one security feature, which are merely adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer. The claim recites these features at a high level of generality and do not recite any specific technical mechanism for performing the import, enforcing sandboxing, constraining memory at compile time, or structurally limiting logic to first order constructs, and do not recite any particular modification to GPU architecture, compilation techniques, memory management, or execution controls. Therefore, the recited security features mere instructions to apply the abstract idea using generic computer and GPU functionality, which do not integrated judicial exception into practical application (see MPEP § 2106.05(f)). Implementing the abstract idea using GPU code executed in a constrained programing or sandboxed execution environment merely limits the judicial exception to a particular technological environment or field of use. Therefore, limiting an abstract idea to a specific programming model or execution environment does not integrate the exception into a practical application. See MPEP § 2106.05(h).
Although applicant asserts benefits such as reduced data transfer, increased editability, and increased precision. However, these advantages are related to represent CAD bodies using mathematical equations and code. In other words, the asserted improvement reflect improvements to the abstract idea itself, rather than an improvement to the functioning of computers or an improvement to other technology or technical field. (See MPEP 2106.05(a), II. "it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology.")
Therefore, eligibility is not self-evident, and the streamlined path is not applicable. The examiner properly applied the full eligibility analysis to determine whether the claims integrate a judicial exception into a practical application or recite additional elements amounting to significantly more than the exception.
With respect to the Applicant’s argued rejection under 35 § U.S.C. 101 in “Applicant Arguments/Remarks Made in an Amendment,”
Applicant argues:
Full Eligibility Analysis (Step 2A, Prong 2)
Although the streamlined eligibility analysis is sufficient for claims that are plainly directed to improvements in computer functionality, proceeding with the full analysis anyway also shows that the claims are patent eligible. The Office action asserts that the claims recite judicial exceptions at Step 2A, Prong 1. Taking claim 1 as an example, the Office action identifies the one or more implicit equations/functions following elements as abstract ideas: "determining, …, for one or more CAD bodies; expressing, …, the one or more implicit equations/functions as code." Appellant respectfully traverses the Prong 1 finding, but for brevity's sake, focuses on the Prong 2 analysis.
At Prong 2, even assuming (without admitting) that these elements are abstract ideas, the "additional" elements of the claim integrate them into a practical application, making the claim patent eligible. As the MPEP explains, "[o]ne way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field … Such claims are eligible at Step 2A." MPEP at 2106.04(d)(1). To evaluate this technical field consideration, the MPEP instructs that "first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement." Id. "Second … the claim must be evaluated includes the components or steps of the invention that provide the to ensure that the claim … includes the components or steps of the invention that provide the improvement." Id. Notably, "the improvement can be provided by the additional element(s) in combination with the recited judicial exception …Thus, it is important for examiners to analyze the claim as a whole" in this analysis. MPEP at 2106.05(a), emphasis added.
Following the MPEP's instruction, evaluating the specification shows that the disclosure does provide sufficient details for a person of ordinary skill in the art to recognize that the claimed subject matter provides an improvement to computer technology. As explained above with reference to the streamlined analysis, the specification sets forth several improvements to computer technology (namely, CAD exchange) at least at [0009], [0047], and [0055]-[0056]. The first step of the MPEP's analysis is therefore satisfied.
Next, evaluating the claims shows that they do reflect one or more of the improvements disclosed in the specification. For example, exchanging code rather than meshes, voxels, or boundary representations provides the advantages of accomplishing CAD exchange with a smaller amount of data than is conventional. [0009]. Paragraphs [0055]-[0056] further explain that accomplishing the CAD exchange by exchanging code that expresses an implicit function improves precision and allows for parametric editing at the target system, which are improvements over known methods. Additionally, paragraph [0047] explains various security risks specifically addressed by the security features recited in claim 1. Accordingly, the second step of the MPEP's analysis is satisfied, and the claims integrate any recited abstract idea into a practical application.
The Office action does not reach this conclusion, partly because it characterizes the recited security features (i.e., (A) all logic of the GPU code is first order; (B) the memory requirements for the GPU code are known at compile time; or (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access) as mere instructions to apply an abstract idea on a computer at a high level of generality. This is unreasonable. The recited features are specific, inherently computer-based features that address specific, computer-based security risks in a computer-based technology. It is difficult to see how these security features could be understood as mere instructions to apply any abstract idea on a computer, much less the abstract ideas actually identified in the Office action (i.e., determining implicit equation(s)/function(s) for CAD bod(ies) and expressing them as code).
Accordingly, claim 1 (and for similar reasons, all independent claims) should be found patent eligible, and Appellant respectfully submits that the § 101 rejections should be withdrawn.
(see Response filed 10/28/2025 [pages 2-4]).
The examiner respectfully disagrees with applicant argument that the second step of the MPEP's analysis is satisfied, and the claims integrate any recited abstract idea into a practical application.
As previously explained in the streamlined analysis, the asserted improvements described in paragraphs [0009], [0055]-[0056] reflect improvements to the abstract idea itself (i.e., representing CAD bodies using implicitly equations and code), rather than an improvement to the functioning of computers or an improvement to other technology or technical field. (See MPEP 2106.05(a), II. "it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology.").
With respect to the additional limitations, in particular, the claims recite that the provided code allows import at the target system and includes GPU code implemented with at least one security feature (e.g., first order logic, compile time memory knowledge, sandboxed execution). As explained previously, these limitations do not integrated the judicial exception into a practical application. First, limiting execution of the abstract idea to GPU code (e.g., GLSL execution) merely confines use of the abstract idea to a particular technological environment or field of use, which do not integrated a judicial exception into a practical application. See MPEP 2106.05(h). Second, the recited security features are described at a high level of generality and do not recite any specific technical mechanism that modifies GPU architecture, shader compilation processes, memory management techniques, or execution control structures. Rather, they amount to instructions that the abstract idea be executed using GPU functionality with certain characteristics. The instructions to apply an abstract idea using generic computer or GPU functionality do not integrate the judicial exception in to a practical application. See MPEP 2106.05(f).
Although paragraph [0047] describes the security features as safeguards within a GLSL or similar execution environment, the claims do not recite any specific technological implementation other than requiring execution in the known environment ([0032]). Therefore, the claims merely apply the abstract idea within an existing technological framework and do not reflect a technological improvement.
Accordingly, the additional limitations, considered individually and in combination with the abstract idea, do not integrate the judicial exception into a practical application.
Although applicant did not present arguments regarding Step 2B, the current office action already addressed this step to complete the patent subject matter eligibility analysis under 35 U.S.C. § 101. Therefore, the claims, when is considered as a whole, do not recite additional limitation elements that amount to significantly more than the judicial exception under Step 2B.
For the reasons discussed above, applicant’s arguments have been considered but are not persuasive. The claims are directed to abstract ideas (mathematical concepts and mental processes), the additional limitations do not integrate judicial exception into a practical application, and do not amount to significantly more than the judicial exception. The rejection under 35 U.S.C. § 101 is maintained.
Applicant' s arguments, see “Pre-Appeal Brief Conference Request” on pages 4-5, filed
10/28/2025, with respect to the rejection(s) of claim(s) 1, 7 and 13 under the statutory basis for the previous rejection under 35 § U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of the newly found prior art reference(s).
The newly applied reference Min (“Function-based 3D Web Visualization,” published in 2002) teaches the limitation of “displaying, based on the provided code, the one or more CAD bodies at the target system,” and Yao (“Sugar: Secure GPU Acceleration in Web Browsers,” published in 2018) teaches the limitation of “at least some graphics processing unit (GPU) code implemented with at least one security feature of (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access.” Therefore, the combination of Gielis US20050140678A1 in view of Min and Yao teach or suggest the amended limitations of claims 1, 7 and 13, and the rejection of claims 1, 7 and 13 under 35 U.S.C. §103 is maintained.
Claim Objections
Claims 1, 7 and 13 are objected to because of the following informalities:
Claims 1, 7 and 13 recite “… it run on the target system…” should read as “… it runs on the target
system…”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the memory requirements …" in lines 14-15. There is insufficient antecedent basis for this limitation in the claim.
Claims 7 and 13 also recite the limitation "the memory requirements …," and are rejected for same reason.
Claim 4 recites “the GPU code is provided to the graphics processing unit of the source computing system and would be generated for display purposes even without an export to the target system,” which renders the claim indefinite because it is unclear whether the limitation “would be generated” required that the GPU code is actually generated, or merely that it is capable of being generated under certain conditions. For the purpose of substantive examination, the examiner presumes that “would be generated” as GPU code that is at least capable of being generated for display purpose.
Claims 10 and 16 also recite the limitation " would be generated …," and are rejected for same reason.
The remaining claims are dependent upon one of the claims listed above and rejected for the same reason.
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.
The claim(s) 1-20 are rejected under 35 USC § 101 because the claimed invention is
directed to judicial exception an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Are the claims to a process, machine, manufacture or composition of matter?"
Yes, Claims 1-6 and 19 are directed to method and fall within the statutory category of processes;
Yes, Claims 7-12 and 20 are directed to system and fall within the statutory category of machines;
Yes, Claims 13-18 are directed to non-transitory computer-readable storage medium and fall within the statutory category of manufactures;
In order to evaluate the Step 2A inquiry "Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?" we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 1: The limitations of “determining, …, one or more implicit equations/functions for one or more CAD bodies” and “expressing, …, the one or more implicit equations/functions as code” as drafted, are process that, but for the recitation of generic computing components (e.g., “by a source computing system”), under the broadest reasonable interpretation (BRI) in light of the specification, cover performance of the limitation in the human mind.
For example, a person is capable of observing and evaluating CAD entities, mentally defining an implicit equation/function that represents the observed CAD entities, and translating the equation/function into a written code form (e.g., as a mathematical expression or programming syntax). The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011).
Examiner note: the instant specification confirms that the implicit equations/functions can be defined and edited by a user in a human understandable manner, for example, [0056], “Editing of parameters of the CodeRep can, for instance, be performed via manual code editing and/or via UI fields.” See also Fig.4, [0035], [0050] and [0057]. Even if some examples describe manual defining/editing at a target system, they still evidence that the claimed “implicit equation/ function” and “code” form are the type of information a person can determine and express mentally (or with pen and paper).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the
limitation in the mind, but for the recitation of generic computer components, then it falls within the
“Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under
Prong I step 2A.
In MPEP 2106.04(II)(B): A claim may recite multiple judicial exceptions. For example, claim 4 at issue in Bilski v. Kappos, 561 U.S. 593, 95 USPQ2d 1001 (2010) recited two abstract ideas, and the claims at issue in Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 101 USPQ2d 1961 (2012) recited two laws of nature. However, these claims were analyzed by the Supreme Court in the same manner as claims reciting a single judicial exception, such as those in Alice Corp., 573 U.S. 208, 110 USPQ2d 1976.
As explained in MPEP 2106.4(a)(2)(I): “The mathematical concepts grouping is defined as mathematical relationships, mathematical formulas or equations, and mathematical calculations. It is important to note that a mathematical concept need not be expressed in mathematical symbols, because "[w]ords used in a claim operating on data to solve a problem can serve the same purpose as a formula." In re Grams, 888 F.2d 835, 837 and n.1, 12 USPQ2d 1824, 1826 and n.1 (Fed. Cir. 1989). See, e.g., SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163, 127 USPQ2d 1597, 1599 (Fed. Cir. 2018) (holding that claims to a “series of mathematical calculations based on selected information” are directed to abstract ideas); Digitech Image Techs., LLC v. Elecs. for Imaging, Inc., 758 F.3d 1344, 1350, 111 USPQ2d 1717, 1721 (Fed. Cir. 2014) (holding that claims to a “process of organizing information through mathematical correlations” are directed to an abstract idea); and Bancorp Servs., LLC v. Sun Life Assurance Co. of Can. (U.S.), 687 F.3d 1266, 1280, 103 USPQ2d 1425, 1434 (Fed. Cir. 2012) (identifying the concept of “managing a stable value protected life insurance policy by performing calculations and manipulating the results” as an abstract idea).
MPEP 2106.04(a)(2)(I)(A): A mathematical relationship is a relationship between variables or numbers. A mathematical relationship may be expressed in words or using mathematical symbols.”
Further, MPEP recites: “For example, a step of "determining" a variable or number using mathematical methods or "performing" a mathematical operation may also be considered mathematical calculations when the broadest reasonable interpretation of the claim in light of the specification encompasses a mathematical calculation.
Claim 1, The limitation recites “determining, …, one or more implicit equations/functions for one or more CAD bodies” and “expressing, …, the one or more implicit equations/functions as code,” The limitation with the broadest reasonable interpretation (BRI) in light of specification that can be considered to represent mathematical concepts expressed in words including mathematical equation and relationships, for example, [0031], “an implicit equation/function can be the signed distance function (SDF) of a mesh of a given one of the CAD body/bodies.” [0035], “With reference to Fig. 4, implicits can describe shapes in terms of equations/functions …, the same circle can be described in an implicit fashion 403, such as through one or more equations which can be expressed as the code of 403. Describing shapes in an implicit fashion advantageously yields functions/equations which can take varying inputs (e.g., spatially varying inputs).” – MPEP 2106.04(a)(2)(I).
Examiner note: the claimed “determining” of implicit equation/functions corresponds to determining a mathematical relationship and/or equations defining a geometric shape, and the “expressing” limitation corresponds to represent that mathematical relationship and/or equations in code form. Therefore, these limitations recite mathematical relationships and equations, which fall within the mathematical concepts grouping of abstract ideas.
Claims 7 and 13 recite substantially the same elements as claim 1, and are rejected for the
same reasons under 35 U.S.C. 101.
Therefore, claims 1, 7 and 13 recite judicial exceptions. The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims as a whole integrates the exception into a practical application of that exception.
Step 2A Prong 2: Claims 1, 7 and 13: The judicial exception is not integrated into a practical application.
In particular, the claims recite the following additional elements - "by a source computing system” and “a target system” and “A system for computer aided design (CAD) exchange comprising: a source computing system including at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the system to perform” and “A non-transitory computer-readable storage medium for computer aided design (CAD) exchange including instructions that, when executed by at least one processor of a source computing system, cause the source computing system to perform,” which are mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to implement the judicial exception (see MPEP § 2106.05(f)) with the broadest reasonable interpretation, which does not integrate judicial exception into a practical application.
Further, the following additional elements – “providing, by the source computing system to a target system, the code; and displaying, based on the provided code, the one or more CAD bodies at the target system,…” are merely recitations of insignificant extra-solution activity as data output (i.e., data transmission and presentation), which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). The additional limitations do not recite any specific improvement to computer graphics, rendering algorithms, data transmission protocols, GPU architecture, or any computer functionality. Instead, the additional limitations merely specify that the mathematical representation (i.e., implicit equation/ function expressed as code) is output from source system, transferred to a target system, and displayed.
Additionally, adding the steps of providing the generated code to a target system and displaying the resulting CAD bodies based on the code to a process that only recites determining and expressing implicit equations or functions (abstract idea) does not add a meaningful limitation to the process of determining and expressing the implicit equations or functions.
Therefore, the providing and displaying limitations function only as generic data output and presentation mechanisms and do not meaningfully limit or integrate the judicial exception into a practical application.
Further, the following additional elements – “… the provided code allows for import of the one or more CAD bodies at the target system, and wherein the provided code includes at least some graphics processing unit (GPU) code implemented with at least one security feature selected from the group consisting of (A) all logic of the GPU code is first order; (B) the memory requirements for the GPU code are known at compile time; and (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access.”
The additional limitations further define that the code provided from the source computing system to the target system includes GPU code with at least one security feature and allows import of CAD bodies at the target system. However, It is merely adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer. The claim recites the desired characteristics of the GPU code and the ability to import CAD bodies at a high level of generality, without reciting any specific technical mechanism for performing the import, enforcing sandbox execution, constraining memory at compile time, or structurally limiting logic to first-order constructs. The claim also does not recite any particular modification to GPU architecture, shader compilation techniques, memory management, execution controls, or import processing mechanisms. Instead, the claim merely requires that the abstract idea (i.e., determining implicit equations/functions and expressing them as code) be executed using GPU code having certain characteristics and be capable of import at the target system. Therefore, the additional limitation mere instructions to implement the abstract idea on a computer using generic GPU functionality, which do not integrate the judicial exception into a practical application. See MPEP § 2106.05(f).
The Specification explains that the generated CodeRep may utilize OpenGL Shading language (GLSL), Python, C, or C# code … ([0032]), and clarifies that the “first order” logic feature is “first order in the GLSL sense” ([0047]) and describes compile time memory knowledge and sandboxed execution as safeguards associated with CodeRep execution environment [0047]. Therefore, the recited GPU security features correspond to characteristics of GPU code implemented within a technological environment (e.g., GLSL execution), rather than to any technological improvement to computer functionality. Implementing the abstract idea using GPU code executed in a constrained programing or sandboxed execution environment merely limits the judicial exception to a particular technological environment or field of use. Therefore, limiting an abstract idea to a specific programming model or execution environment does not integrate the exception into a practical application. See MPEP § 2106.05(h).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 7 and 13 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B: Claims 1, 7 and 13: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components which do not amount to significantly more than the abstract idea. Limitations that the courts have found not to be enough to qualify as "significantly more" when recited in a claim with a judicial exception include:
i. Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 573 U.S. at 225-26, 110 USPQ2d at 1984 (see MPEP § 2106.05(f));
ii. Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984 (see MPEP § 2106.05(d));
iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)); or
iv. Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski v. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker v. Flook, 437 U.S. 584, 588-90, 198 USPQ 193, 197-98 (1978) (MPEP § 2106.05(h)).
For example, the additional limitation “providing, by the source computing system to a target system, the code; and displaying, based on the provided code, the one or more CAD bodies at the target system,” does not amount to significantly more than the judicial exception. As shown in the reference Min (“Function-based 3D Web Visualization,” published in 2002) teaches transmitting function defined model descriptions (i.e., executable graphics code) to a client system and rendering the geometric model at the client using GPU/WebGL functionality (see, e.g., page.2, section 2.1, 2.3 and Page.5, second 4.1). The instant claim does not recite any specific or unconventional transmission protocol, rendering architecture, or technical improvement in how the display operation is performed. Instead, it merely requires sending code and displaying the CAD bodies, and does not provide significantly more to the judicial exception.
Similarly, the additional limitation “the provided code allows for import of the one or more CAD bodies at the target system, and wherein the provided code includes at least some graphics processing unit (GPU) code implemented with at least one security feature selected from the group consisting of (A) all logic of the GPU code is first order; (B) the memory requirements for the GPU code are known at compile time; and (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access,” also does not provide an inventive concept. As shown in the reference Yao (“Sugar: Secure GPU Acceleration in Web Browsers,” published in 2018) teaches executing GPU or shader code within a sandboxed and isolated virtual graphics plane (vGPU) that is fully isolated from the rest of the system (see Abstract; pages 520 and 526). The instant claim does not recite any new sandbox mechanism, modification to GPU hardware, or unconventional control technique. Instead, it merely requires that the abstract idea be executed within a known GPU security environment, and does not provide significantly more to the judicial exception.
Therefore, considered these additional elements, alone or in combination, merely apply the judicial exception using conventional computing and GPU techniques and do not amount to significantly more than the judicial exception.
Therefore, "Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis within the provided framework, claims 1, 7 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Dependent claims 2-6, 8-12 and 14-20 are also similar rejected under same rationale as cited above wherein these claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. These claims are merely further elaborate the mental process itself (and/or mathematical operations) or providing additional definition of process which does not impose any meaningful limits on practicing the abstract idea. Claims 2-6, 8-12 and 14-20 are also rejected for incorporating the deficiency of their independent claims 1, 7 and 13.
Claim 2 recites “the one or more CAD bodies comprise one or more external function features/constituents, and wherein the code comprises one or more calls to external functions.”
The limitation merely further defines CAD bodies including external function, and code comprises calls to external functions; therefore, it is mere instructions to implement an abstract idea using generic computer programming constructs and does not integrate the judicial exception into a practical application. see MPEP 2106.05(f). The limitation does not provide any additional technical step, specialized processing, or technological improvement. Instead, it describes the code representing the implicit equation or function of claim 1 includes function calls, which is a generic programming description and does not meaningfully limit how the judicial exception is determined or expressed. Therefore, the claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 3 recites “providing, by the computing system to the target system, a backup texture for the one or more CAD bodies.”
The limitation merely specifies providing backup texture to the target system; therefore, it merely a recitation of insignificant extra-solution activity as data output (i.e., transmitting backup texture to the target system)(see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Therefore, the claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 4 recites “the GPU code is provided to the graphics processing unit of the source computing system and would be generated for display purposes, even without an export to the target system.”
The limitation merely specifies GPU code can be received and displayed at source system; therefore, it merely a recitation of insignificant extra-solution activity as data output (i.e., provide GPU code to the GPU for display) (see MPEP § 2106.05(g)) which does not integrate a judicial exception into practical application. Therefore, the claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 5 recites “the determination of the one or more implicit equations/functions comprises determination of at least one signed distance function (SDF).”
The limitation merely specifies computing one or more singed distance functions representation for one or more CAD bodies; therefore, it is mere a mathematical concept (i.e., SDF as mathematical function is computed). Therefore, the claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 6 recites “the provided code accepts varying inputs, and wherein said varying inputs allow for one or more of parametric edits and manufacturing process correction at the target system.”
The limitation merely specifies the code representing the implicit equations or functions determined in claim 1 can receive varying input values to adjust parameters and update the CAD bodies at the target system; therefore, it mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, and does not integrate the judicial exception into a practical application. see MPEP 2106.05(f). The limitation does not recite any improvement to computer functionality, rendering techniques, or manufacturing technology. Therefore, the claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 19 recites “the GPU code is OpenGL Shading Language (GLSL) code.”
The limitation merely further defines code including the GPU code is written in OpenGL Shading Language (GLSL); therefore, it amounts to no more than generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP §2106.05(h). Therefore, the claim 19 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 8-12, 14-18 and 20 recite substantially the same elements as claims 2-6 and 19, and are rejected for the same reasons under 35 U.S.C. 101.
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.
Claim(s) 1, 2, 6-8, 12-14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over
Gielis US20050140678A1 in view of Min (“Function-based 3D Web Visualization,” published in 2002) and Yao (“Sugar: Secure GPU Acceleration in Web Browsers,” published in 2018).
Claim 1, Gielis teaches A computer-implemented method for computer aided design (CAD) exchange ([0200] - [0216]; [0209] “to export a shape into an external file format, … , since a common type of information is represented: e.g., SUPERSHAPES, a common file format is used to represent this information. Among other things, the use of a common file format can have some notable advantages in this context, such as:” [0210] “enabling the exchange of information between products … [0216] … information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting.”; [0142], “…a SUPERFORMULA-based modeller (such as, e.g., a 2-D and/or 3-D modeller) can advantageously be used in a variety of applications, ranging from CAD/CAM…”) comprising:
determining, by a source computing system, one or more implicit equations/functions for one or more CAD bodies ([0086], “…computer system…” [0142]-0147]; for example, [0142], “…a SUPERFORMULA-based modeller (such as, e.g., a 2-D and/or 3-D modeller) can advantageously be used in a variety of applications, ranging from CAD/CAM…” [0145] “…Since SUPERFORMULA 3D shapes can be expressed as implicit functions all of the above and other operations can be performed with SUPERSHAPES.” [0147] “As the SUPERFORMULA allows for both parametric expression and implicit function, the advantages of both, namely enumeration and classification of points, can be combined. This variety of possible operations and basic representations makes the SUPERFORMULA one of the most powerful shape representations, and certainly, a very uniform representation too.”);
expressing, by the source computing system, the one or more implicit equations/functions as code ([0215] “the information (Note: e.g., SUPERSHAPE) can be coded using defined file standards, such as, e.g., XML. Among other things, SUPERSHAPE files can be represented as XML documents and an abstract grammar can be defined for SUPERSHAPES using, e.g., DTD (Document Type Definition). In addition, SUPERSHAPES can also be coded using SCG (Scalable Vector Graphics) in some embodiments.”);
providing, by the computing system to a target system, the code ([0216] “… information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting.” [0180], “e.g., SUPERSHAPES, a common file format is used to represent this information. Among other things, the use of a common file format can have some notable advantages in this context, such as: enabling the exchange of information between products; enabling common libraries to be built that can be used in any supporting product …” Examiner note: A POSITA would understand that exchange of information between products necessarily involves a first computing system exports the coded shape information (e.g., SUPERSHAPE data in XML document) and a second computing system imports the information for use); and
([0215]-[0216]), ([0142], “…a SUPERFORMULA-based modeller (such as, e.g., a 2-D and/or 3-D modeller) can advantageously be used in a variety of applications, ranging from CAD/CAM…”; [0209]-[0216], a common type of information is represented: e.g., SUPERSHAPES, a common file format is used to represent this information; the information can be coded using defined file standards, such as, e.g., XML. Among other things, SUPERSHAPE files can be represented as XML documents; information regarding the common file formats are into a GENICAP Class Library (GCL); Examiner note: A POSITA would understand that when a common file format is used to exchange coded CAD data between products, the target system must be capable of importing and processing the coded CAD data), and
wherein the provided code ([0215]-[0216])
However, Gielis fails to teach displaying, based on the provided code, the one or more CAD bodies at the target system.
Min teaches displaying, based on the provided code, the one or more CAD bodies at the target system (Page.2, 2.1. Function-based shape modeling, “Function-based shape modeling is becoming increasingly popular in computer graphics. The idea of function-based approach to shape modeling is that complex geometric shapes can be produced from a "small formula" rather than thousands of polygons. Usually, parametric or implicit functions and their modifications are used to define the shapes.” 2.3. Function-defined geometric node, “A small VRML file with a function-defined model description is sent back to the client … When the VRML data reaches the client machine, the VRML plug-in starts to parse the VRML immediately. The scene graph traversal module proceeds and renders the scenes during the traversal. Once the scene graph traversal module finds the customized function-defined node, the browser plug-in will download the model description according to the specified URL. Alternatively, the description can be embedded in the VRML code. The polygonization of the function model is completed at the client machine, so that no large amount of rendering data is transferred across the network. Immediately after the polygonization has completed, the complex geometric model will be presented to the client.” Page.5, 4.1. F-Rep and its applications, “The F-Rep assumes that geometric shapes are represented with an inequality f(x,y,z) ≥ 0, …” Examiner note: A POSITA would understand that the “function-defined model description” embedded in the VRML file constitutes code representing the implicit function defining the CAD body. The client machine parses and evaluates the code, polygonises the function model, renders the geometric model, and display the CAD body at the client system).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis to incorporate the teachings of Min, and apply transmitting a function defined model description within a VRML file and performing parsing, evaluation, and rendering of the implicit function at a receiving system in order to support client (target system) reconstruction and rendering of compact function defined geometry representations. In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Min teaches transmitting a VRML file containing a function defined model description to a client system that the implicit function definition is parsed, polygonised , and rendered at the client machine. The combination of teachings would provide benefit of transmitting compact implicit function based CAD representations between systems and reconstructing and displaying at a target system through evaluation of the encoded function, thereby improving interoperability and efficiency of distributed visualization between different systems.
However, Gielis and Min fail to teach at least some graphics processing unit (GPU) code implemented with at least one security feature selected from the group consisting of (A) all logic of the GPU code is first order; (B) the memory requirements for the GPU code are known at compile time; and (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access.
Yao teaches at least some graphics processing unit (GPU) code implemented with at least one security feature selected from the group consisting of (A) all logic of the GPU code is first order; (B) the memory requirements for the GPU code are known at compile time; and (C) the GPU code stipulates that it run on the target system in a sandboxed execution environment that disallows operating system access (For security feature (c); Page.519, Abstract, “… A virtual graphics plane consists of a dedicated virtual GPU (or vGPU) as well as all the software graphics stack (including the device driver). Sugar enhances the system security since a virtual graphics plane is fully isolated from the rest of the system.” Introduction, “… through WebGL, a web app can program different shaders (i.e., GPU kernel code) to run on the GPU, which can directly access the memory using Direct Memory Access (DMA).” Page.520, left column, “… A virtual graphics plane consists of a dedicated virtual GPU (vGPU) and all the graphics stack needed to operate it, all sandboxed within the web app process.” Page.526, left column, “The page table shadowing is required for safety. It only allows the vGPU driver to map its own process memory pages into the page tables, which limits the vGPU’s DMA access to the web app process memory.” Examiner note: A POSITA would understand that the WebGL shade programs (i.e., GPU kernel code) execute on the GPU of the client device running the web application. The reference teaches that the virtual graphics plane, including the vGPU and graphics stack, is sandboxed within the web application process and fully isolated from the rest of the system. Therefore, the GPU code executes within a sandboxed execution environment that restricts DMA and memory mapping to the web application process and prevent access to operating system outside the sandbox).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Min to incorporate the teachings of Yao, and apply GPU shader execution within a virtual graphics plane sandbox in order to isolate GPU operations from the operating system and restrict unauthorized memory access during rendering at the client system. In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Min teaches transmitting a VRML file containing a function defined model description to a client system that the implicit function definition is parsed, polygonised, and rendered at the client machine so that the geometric model is displayed to the user. Yao teaches executing GPU shader code within a sandboxed execution environment that isolates GPU operations from the operating system and restricts unauthorized access. The combination of teachings would provide benefit of rendering implicitly function based CAD models at a client or target system while confining GPU execution to a sandboxed environment that limits DMA and memory mapping to the web application process, thereby maintaining system security during distributed visualization.
Claim 2, Gielis fails to teach, but Min teaches (Original) The computer-implemented method for CAD exchange of claim 1, wherein the one or more CAD bodies comprise one or more external function features/constituents, and wherein the code comprises one or more calls to external functions (Page.2, 2.3. Function-defined geometric node, “When a client tries to view a complex function-defined geometric model via the Internet, the VRML browser plug-in sends a view request to the remote content server. A small VRML file with a function-defined model description is sent back to the client.” Page.4, 3.2. Interaction between modules in the visualization pipeline, “The FShape core module will pass sourceURL and sourceString to the Seeker component … In order to allow for future extension of Parser component in runtime, the component is dynamically loaded into the FShape core module …the respective Parser module is to be developed separately with a set of standard function calls … The required function for the Parser component is Parse(string szSrc), in which the data obtained by the Seeker component will be interpreted accordingly … Another required function for the Polygonizer component is Calc(), in which the CInterpreted object obtained from the Parser component will be used accordingly. The CInterpreted object, as shown in Figure 2, contains necessary values and functions in order to execute the polygonization.” Page.6, 5. Support for any proprietary function-defined models, right column, “The FShape node will dynamically load the corresponding Parser and Polygonizer components based on the string value stored in sourceType field.” See also Fig.4. A sample HyperFun definition source as CAD style constructive solid geometry. Examiner note: A POSITA would understand that the function-defined geometric model (e.g., HyperFun definition) constitutes the CAD body, and the CAD body is defined by one or more functions forming geometric representation. The reference teaches that the function defined geometric model is implemented using separately developed Parser and Polygonizer modules that are dynamically loaded into the FShape core module. Because these modules are developed separately and invoked by the FShape core via function calls (e.g., Parse (string szSrc), Calc()), the CAD body comprises function features implemented through external functional components).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis to incorporate the teachings of Min, and apply dynamically loading and invoking external Parser and Polygonizer modules in order to support modular execution of function defined geometric models through calls to external functions. In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Min teaches a function defined geometric model is implemented using separately developed Parser and Polygonizer modules that are dynamically loaded and provide callable fruitions such as Parse(string szSrc) and Calc() for interpreting and executing the model description. The combination of teachings would provide benefit of permitting CAD bodies defined by implicit functions to comprise external functional constituents and to be executed through calls to external functions, thereby improving modularity, extensibility and runtime processing of function based geometric models.
Claim 6, Gielis further teaches (Original) The computer-implemented method for CAD exchange of claim 1, wherein the provided code accepts varying inputs, and wherein said varying inputs allow for one or more of parametric edits and manufacturing process correction at the target system ([0216] information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting. [0210] enabling the exchange of information between products; [0211] enabling common libraries to be built that can be used in any supporting product; [0169] …FIG. 20 shows an illustrative shape window that can be presented which shows the produced shape. In some illustrative examples, additional commands (e.g., for creating and/or varying shapes, etc.) can be entered via a pointer device (such as, e.g., by a right-mouse click).” Examiner note: A POSITA would understand that modifying geometric shapes via additional commands necessarily involves modification geometric parameters that allow one or more parametric edits).
The elements of claims 7 and 13 are substantially the same as those of claims 1. Further, claim 7 recites A system for computer aided design (CAD) exchange comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor (see Gielis, [0083] and [0086], “a central processing unit; memory (e.g., RAM, etc.)” and “The computer instructions can be written in various programming languages and/or can be stored in memory device(s)…”. Claim 13 recites “A non-transitory computer-readable storage medium for computer aided design (CAD) exchange including instructions that, when executed by at least one processor of a computing system” (See Gielis, [0085], “The CPU 322 can communicate with a computer readable medium (e.g., conventional volatile or non-volatile data storage devices) 328 (hereafter "memory 328") over the bus 326.” Therefore, the elements of claims 7 and 13 are rejected due to the same reasons as outlined above for claim 1.
The elements of claims 8, 12, 14 and 18 are substantially the same as those of claims 2 and 6. Therefore, the elements of claims 8, 12, 14 and 18 are rejected due to the same reasons as outlined above for claims 2 and 6.
Claim(s) 3, 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Min
and Yao as applied to claims 1, 7 and 13 above, and further in view of Rappoport US 7099803B1.
Claim 3, Gielis further teaches (Original) The computer-implemented method for CAD exchange of claim 1, further comprising: ([0086], “…computer system…”) to the target system (i.e., GENICAP Class Library (GCL) or other devices would import the common file formats from GCL)”),
However, Gielis fails to teach provide a backup texture for the one or more CAD bodies.
Rappoport teaches provide a backup texture for the one or more CAD bodies (fig.6; Col.9, lines 52-57, “A current object region 605 temporarily caches one or more portions of a feature list from a source CAD system 401--this cache generally represents a set of data (or operations) that is sufficiently proportioned so that it is large enough to hold the largest source operation pattern.” Col.10, line 10-17, “a bridge structure 402' is shown in FIG. 6. The bridge structure 402' can be universal data type or product representation--that is, an intermediate data type that is not, strictly speaking, the target data type. Thus, the bridge structure 402' can include additional information concerning the source CAD model, the target CAD model, and extraction and creation information that can be used for a lossless, two-way data exchange.” Col.5, lines 32-43, “An advantage of creating a persistent bridge data structure 402' is that version and extraction/creation information, such as undo logs or rollback logs, can be created to back-out or re-write changes …” Examiner note: the reference teaches portions of a source CAD model are temporarily cached and provided via an intermediate bridge structure during data exchange. The cached or intermediate CAD data constitutes a backup representation of the CAD bodies provided to the target system).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Min and Yao to incorporate the teachings of Rappoport, and apply temporarily cached CAD data as a backup texture in order to preserve exchanged CAD body information at the target system during data exchange. In this case, Gielis teaches generating and exporting coded CAD bodies. Min teaches transmitting function defined geometric model descriptions to a client system for processing and rendering. YAO teaches providing GPU related processing for CAD model handling. Rappoport teaches that portions of a source CAD model are temporarily cached and provided to a target system through an intermediate structure. The combination of teachings would provide benefit of maintaining a secondary representation of the exchanged CAD bodies at the target system, thereby reducing repeated data retrieval form the source system and improving overall data exchange efficiency and system performance.
The elements of claims 9 and 15 are substantially the same as those of claim 3. Therefore, the elements of claims 9 and 15 are rejected due to the same reasons as outlined above for claim 3.
Claim(s) 4, 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Min
and Yao as applied to claims 1, 7 and 13 above, and further in view of Zhang (“A GPU Accelerated Signed Distance Voxel Modeling System,” published in 2016).
Claim 4, Gielis and Min and Yao fail to teach, but Zhang teaches (Currently Amended) The computer-implemented method for CAD exchange of claim 1, wherein the GPU code is provided to the graphics processing unit of the source computing system and would be generated for display purposes even without an export to the target system (page.28-29, “CUDA/OpenGL interop eliminates the need for memory transfers for purposes of display. When the memory is mapped to CUDA, computational results can be stored as usual for global memory on the GPU. When mapped to OpenGL, the same data is used as the basis for display in a graphics window … Once the basic code is in place to display an array of shading values on the screen using CUDA/OpenGL interop [32] , developers can focus on programming the kernel to perform parallel computation of desired shading values. In our voxel modeler, the computation is divided into a 2D computational grid in which each thread is responsible for computing the shading value for a pixel in the image to be displayed. The sections below will talk in detail about how we actually determine the color for each pixel on a 2D window. In addition to rendering, our discrete SDF-rep modeler, like all CAD systems, needs to support interactions with the user. While OpenGL enables handling user input, we use GLUI [33] to build the user interface and to specify the actions associated with input from mouse and keyboard.” Examiner note: the reference teaches that computational results are stored in GPU global memory and directly mapped to OpenGL for display in a graphics window of the same system. The CUDA kernel executes on the GPU to compute shading values for pixels in the image to be displayed. Therefore, the GPU code is executed and used for rendering within the source computing system, and generating display output independent of any export to a target system).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Min and Yao to incorporate the teachings of Zhang, and apply CUDA kernels programming and CUDA/OpenGL memory mapping in order to display within the same source computing system without requiring data transfer for rendering. The combination of teachings would provide benefit of display using shared GPU memory resources at source system while preserving the ability to export data to a target system when desired, thereby improving workflow efficiency and reducing rendering cost during CAD processing.
The elements of claims 10 and 16 substantially the same as those of claim 4. Therefore, the elements of claims 10 and 16 are rejected due to the same reasons as outlined above for claim 4.
Claim(s) 5, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Min
and Yao as applied to claims 1, 7 and 13 above, and further in view of Ameta US20240135053A1.
Claim 5, Gielis and Min and Yao fail to teach, but Ameta teaches (Original) The computer-implemented method for CAD exchange of claim 1, wherein the determination of the one or more implicit equations/functions comprises determination of at least one signed distance function (SDF) ([0015], “lattice structures of CAD objects may be represented as signed distance fields (SDFs), which may also be referred to as signed distance functions.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Min and Yao to incorporate the teachings of Ameta, and apply signed distance functions as a representation for lattice structures of CAD objects in order to provide a compact implicit mathematical representation of complex lattice geometries suitable for efficient evaluation and transformation. The combination of teachings would provide benefit of improving computational efficiency and reducing memory consumption during lattice generation and processing operations.
The elements of claims 11 and 17 substantially the same as those of claim 5. Therefore, the elements of claims 11 and 17 are rejected due to the same reasons as outlined above for claim 5.
Claim(s) 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Min
and Yao as applied to claims 1, and 7 above, and further in view of Shen CN109525192A.
Claim 19, Gielis and Min and Yao fail to teach, but Shen teaches (New) The computer-
implemented method for CAD exchange of claim 1, wherein the GPU code is OpenGL Shading Language (GLSL) code (page.7, par. 2, “the OpenGL-OpenGL Shading Language shading language referred to in the present application is a language used for color programming in OpenGL, that is, a short custom program written by a developer, and the custom program is on a graphics card. Performed on the GPU graphics processing unit, instead of a part of the fixed rendering pipeline, makes programmability at different levels in the rendering pipeline.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Min and Yao to incorporate the teachings of Shen, and apply OpenGL Shading Language shader programs in order to implement GPU executable rendering code for processing and displaying exchanged CAD bodies. The combination of teachings would provide benefit of executing rendering operations directly on the GPU using standardized GLSL code, thereby improving graphical processing efficiency and enabling consistent GPU based rendering of exchanged CAD bodies at the target system.
The elements of claim 20 is substantially the same as those of claim 19. Therefore, the elements of claim 20 is rejected due to the same reasons as outlined above for claim 19.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be
directed to YI HAO whose telephone number is (571)270-1303. The examiner can normally be reached Monday - Friday.
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, Emerson Puente can be reached on (571)272-3652. 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.
/YI . HAO/
Examiner, Art Unit 2187
/EMERSON C PUENTE/Supervisory Patent Examiner, Art Unit 2187