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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR
1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/18/2026 has been entered.
Response to Amendment
The amendment filed 05/18/2026 has been entered. As directed, claims 15-16 and 18-20 have been
amended, and no claim has been added or canceled. Thus, claims 1-20 remain pending in the application.
Response to Arguments
With respect to the Applicant’s argued rejection under 35 § U.S.C. 101 in “Applicant Arguments/Remarks Made in an Amendment,”:
Applicant argues:
…
I. The Claims are Patent Eligible Under the 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. "A streamlined eligibility analysis can be used for a claim that . . . when viewed as a whole, clearly does not seek to tie up any judicial exception such that others cannot practice it." MPEP 2106.06(a). In particular, "claims directed to clear improvements to computer-related technology do not need the full eligibility analysis." MPEP 2106.06(b), citing Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335- 36 (Fed. Cir. 2016).
Here, the streamlined eligibility analysis is appropriate and satisfied because the claims are directed to a clear improvement in an inherently computer-related technology, as in Enfish. Specifically, the claims are directed to improvement(s) in computer aided design (CAD) exchange. As explained in the Background section of Applicant'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. Specification, paragraph [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." Paragraph [0004]. "Unfortunately, due to nuanced differences in geometry representations," the transfer of the geometry from one system to another "is inherently unreliable." Paragraph [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. Indeed, conventional attempts to solve this technological problem suffer a variety of drawbacks tied to computer-based technological issues, such as the differences in computer operations or commands between different systems. Paragraphs [0006]-[0007].
An additional challenge in the field is that companies often need to share CAD models for collaborative design, manufacturing, or visualization. However, there is a critical need to do so without fully revealing "proprietary, specialized, and/or trade secret geometries and/or construction techniques." Paragraph [0042]. This protection is valuable to companies for maintaining competitive advantage and preventing unauthorized replication or reverse engineering of their designs.
Taking independent claim 1 as an example, the claimed method is directed to solving these known technical problems in CAD technology, and thereby improving a computer-related technology. Claim 1 recites:
…
The method of claim 1 addresses the technical problems described above by determining at least one implicit function and a proprietary geometry representation for a CAD body, obfuscating the proprietary geometry representation in an external function, and expressing the implicit function(s) and external function as code. The claimed method thus enables the 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 (e.g., allowing for different parameter values to be specified for the CAD body, for instance changing thicknesses or diameters in the CAD body)." Paragraph [0009]. See also paragraphs [0055]-[0056], illustrating certain advantages with reference to specific examples. Additionally, obfuscating the proprietary geometry representation in an external function is an inherently computer-based solution to the inherently computer- based problem of exchanging CAD between systems without revealing proprietary information.
Notably, the aforementioned 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, avoidance of data structures that are difficult for the target system to use, allowing a CAD body to be displayed at a target system while protecting proprietary information from that target system - are plainly computer-related improvements to a computer-related technology. For at least this reason, the streamlined patent eligibility analysis is appropriate and is satisfied.
In response to Applicant's previous arguments on eligibility, the Office action states that the streamlined eligibility test is not satisfied, and that one reason for this is that the claim includes limitations the Office action characterizes as abstract ideas. Office action, p. 6. Though Applicant disagrees with the characterization, the characterization is logically incapable of establishing that the streamlined eligibility test is unsatisfied. The streamlined test is satisfied when "the claim clearly improves a technology or computer functionality," whether or not the claim recites a judicial exception. MPEP 2106.06, 2106.06(a). Indeed, if an Examiner did not believe a particular claim recited any judicial exception, there is no reason they would consider applying the streamlined eligibility test at all. Thus, the presence of allegedly abstract ideas in the claims is not a reason that the streamlined test cannot be applied or cannot be satisfied.
The Office action states that another reason the streamlined test is unsatisfied is that "[t]he alleged improvements described in the specification related to the abstract idea itself and are not reflected in any additional limitation." Office action, p. 6. Applicant respectfully disagrees with this statement. The abstract ideas identified by the Office action are "determining at least one implicit function, obfuscating a geometry representation in an external function, and expressing the functions as code," and the improvements are those described immediately above. It is impossible to see how the advantages of smaller data transfer, avoiding a poorly structured data format, facilitating parametric editing, or allowing CAD bodies to be transferred without exposing proprietary geometries could possibly be understood as improvements to the purportedly abstract ideas of determining an implicit function, expressing an implicit function as code, or obfuscating a geometry representation in an external function. On the contrary, they are plainly improvements to the computer-based technology of CAD. This is exactly the situation for which the streamlined eligibility test exists.
Applicant respectfully asserts that the streamlined analysis is appropriate and satisfied as to claim 1, and for similar reasons, also as to independent claims 8 and 15. All pending claims therefore comply with 35 U.S.C. § 101 and a full analysis under the two-part Subject Matter Eligibility Test is not required.
(See Response filed 05/18/2026 [pages 9-12]).
The Examiner respectfully disagrees with Applicant's argument that the streamlined eligibility analysis is appropriate and satisfied because the claims are directed to a clear improvement in an inherently computer-related technology, as in Enfish.
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”.
The claims 1 and 8 recite limitations such as determining at least one implicit function, obfuscating a geometry representation in an external function, and expressing the functions as code. The claim 15 recites limitations such as determining a code representation for a CAD body … wherein the first external function is configured to … wherein the code representation is configured to … expressing at least a portion of the code representation as an abstract syntax tree. These limitations, under the broadest reasonable interpretation in light of the specification, can be considered as mental process and/or mathematical concepts (mathematical relationships and equation). The additional limitations merely use a computer as a tool to perform an abstract idea (MPEP § 2106.05(f)) and add insignificant extra-solution activity (i.e., transmitting code, and displaying CAD body at target system or source system) to the judicial exception (MPEP § 2106.05(g)). Therefore, eligibility is not self-evident, and the full eligibility analysis is properly applied.
The Enfish decision does not apply to the pending claims. In Enfish, the claimed invention improved the computer’s internal data operation through a specific self-referential table structure. However, the pending claims recited at high level of generality, and merely use computing components as tool to perform abstract idea, and transmit code and display the CAD body at target system or source system. The alleged improvements described in the specification related to the abstract idea itself, and are not reflected in any additional limitation that could meaningfully limit the judicial exception. Therefore, the additional limitations, when considering the claim as whole, do not show/reflect a specific improvement to computer functionality or to another technology or technical field.
In addition, Applicant appears to misconstrue the prior Office Action. The Office did not state that the asserted benefits are themselves improvements to the abstract idea. Rather, the Office explained that those asserted benefits are related to the limitations identified as the judicial exception, and are not reflected in additional limitations that meaningfully limit the judicial exception. Applicant’s characterization of these benefits as improvement to CAD technology does not change the analysis. As explained in the Office Action, the additional limitations merely recite computing system as a tool, transmitting the code, and displaying the CAD body, and do not recite a specific technological implementation that integrates the judicial exception into practical application.
Therefore, the examiner properly applied the full eligibility analysis to determine whether the claims integrate a judicial exception into a practical application or recite additional limitations amount 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:
II. The Claims are Patent Eligible Under the Full Eligibility Analysis
…
B. Step 2A, Prong 1: The Claims Do Not Recite a Judicial Exception
…
First, regarding mathematical concepts, recent guidance from the Office advises that "Examiners should be careful to distinguish claims that recite an exception (which require further eligibility analysis) from claims that merely involve an exception (which are eligible and do not require further eligibility analysis)." See USPTO Memorandum from Deputy Commissioner of Patents, entitled "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101," August 4, 2025 (hereinafter "August 2025 Memorandum"). The August 2025 Memorandum explains that even though a claim may "involve or rely upon mathematical concepts," it does not recite a mathematical concept in the sense of Prong 1 unless it actually "set[s] forth or describe[s] any mathematical relationships, calculations, formulas, or equations using words or mathematical symbols." August 2025 Memorandum, page 3. For example, the August 2025 Memorandum instructs that a claim reciting "training the neural network in a first stage using the first training set" does not recite a judicial exception, but a claim reciting "training, by the computer, the ANN based on the input data and a selected training algorithm to generate a trained ANN, wherein the selected training algorithm includes a backpropagation algorithm and a gradient descent algorithm" does recite mathematical concepts for the sole reason that it "refer[s] to the mathematical calculations by name, i.e., a backpropagation algorithm and a gradient descent algorithm." Id.
Applying the instruction of the August 2025 Memorandum, even if the present independent claims may involve or rely on mathematical concepts such as implicit function(s), they do not recite any mathematical concept just by virtue of containing the phrase "implicit function." The Office action itself characterizes the claims as simply perhaps "represent[ing]" mathematical concepts, which Applicant believes reflects the fact that the claims involve mathematical concepts rather than reciting them. For at least the foregoing reasons, the claims do not recite a mathematical concept in the sense of Prong 1.
Second, regarding mental processes, Applicant respectfully submits that the claims do not recite any mental processes that can practically be performed in the human mind. The Office action asserts that the following portions of claim 1 are mental processes: "determining, ..., at least one implicit function and a proprietary geometry representation for a CAD body; obfuscating, with the source computing system, the proprietary geometry representation in a corresponding external function; expressing, ..., the at least one implicit function and the external function as code." Applicant submits that none of these features amount to a mental process within the meaning of Prong 1. Determining implicit function(s) for a CAD body is not a mental process because it cannot practically be performed in the human mind. This is analogous to "a claim to detecting suspicious activity by using network monitors and analyzing network packets," which the MPEP explains is not an abstract idea because "the human mind is not equipped to detect suspicious activity by using network monitors and analyzing network packets." MPEP2106.04(a)(2)(ll) (A), quoting SRI Int'l, Inc. v. Cisco Systems, Inc., 930 F.3d 1295, 1304(Fed. Cir. 2019).
Obfuscating a proprietary geometry representation in a corresponding external function is also not a mental process, and expressing the implicit function(s) and external function as code are also not mental processes because they cannot practically be performed in the human mind. Although in some cases "[c]Iaims can recite a mental process even if they are claimed as being performed on a computer," MPEP2106.04(a)(2)(ll (C), this situation generally arises only when the claim recites a mental process and generically links it to a computer environment, or incidentally uses a computer as a tool. See id., providing examples such as a system of computerizing actions "that humans have performed for hundreds of years." In contrast, obfuscating a geometry representation in an external function and expressing implicit function(s) as code are inherently computer-based steps that each produce an inherently computer- based output that exists outside the human mind (respectively, an external function, and code that expresses an implicit function and an external function).
Indeed, it is difficult to understand exactly what mental process could achieve these results. The Office action appears to state that the above-mentioned features amount to a mental process because a person could purportedly say out loud, or write by hand, "the implicit function and external function in a written or verbal format resembling code." Office action, page 15. Applicant respectfully submits that this is an unreasonable interpretation of the case law and USPTO guidance regarding mental processes. As the Federal Circuit held in CyberSource Corp. v. Retail Decisions, Inc. - the case cited by the Office action in support of this part of the rejection - a claim recites "unpatentable mental processes" if the claim's method steps themselves can all actually be performed in the human mind, "or by a human using a pen and paper." CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372 (Fed. Cir. 2011). The CyberSource court was referring to a claim that recited "obtaining information about other transactions. . "constructing a map of credit card numbers based up on the other transactions," and "utilizing the map of credit card numbers to determine if the credit card transaction is valid." CyberSource, 654 F.3d at 1370. The court's point was that a human being could use their mind (possibly aided by pen and paper) to obtain the information, construct the map, and assess validity of the transaction based on the map.
In contrast to CyberSource, the present Office action appears to assert that the claims are directed to a mental process because a person could attempt to envision (or write by hand) software code that would carry out aspects of the claimed method. By this reasoning, all software elements of a claim would always amount to mental processes, because a human being could envision or mock up on paper the code that would implement those elements. However, as described above, the USPTO has recently cautioned that in the ARP decision that "[s]oftware can make non-abstract improvements to computer technology, just as hardware improvements can." ARP decision, citing Enfish. Similarly, the August 2025 Memorandum instructs that a claim reciting "training the neural network in a first stage using the first training set" does not recite a judicial exception, despite the fact that a person could write out on paper the code that would accomplish this task. Accordingly, the possibility that a person could articulate "a format resembling code" in thought or on paper cannot legally establish that the claim features in question are mental processes. This is analogous to saying that a claim reciting a purely mechanical device is directed to a mental process just because a person could imagine or draw blueprints for the device. For at least these reasons, Applicant respectfully submits that the features identified by the Office action are not mental processes, and that the claim does not recite a mental process.
Accordingly, the pending claims do not recite any limitation that falls within one of the three groupings considered to be "abstract idea" subject matter, and therefore the claims do not recite an abstract idea. Thus, even if one proceeded with the full eligibility analysis despite it being unnecessary in this case, one should find at Step 2A, Prong 1 of the full analysis that the claims are patent eligible.
(See Response filed 05/18/2026 [pages 12-16]).
The Examiner respectfully disagrees with Applicant's argument that the claims merely involve mathematical concepts rather than reciting them.
As explained in MPEP § 2106.04(a)(2)(I), the mathematical concepts grouping is defined as mathematical relationships, mathematical formulas or equations, and mathematical calculations … A mathematical relationship is a relationship between variables or numbers. A mathematical relationship may be expressed in words or using mathematical symbols … 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.
The pending claims 1 and 8 recite “determining … at least one implicit function … for a CAD body.” Under the broadest reasonable interpretation (BRI) in light of the specification, the limitation recites a mathematical concept, including a mathematical relationship or equation. In particular, the specification explains in paragraph [0031] that an implicit equation/function can be the signed distance function (SDF) of a mesh of a given one of the CAD body. Paragraph [0035], With reference to Fig. 4, further explains implicits can describe shapes in terms of equations/functions and illustrates that a circle can be described implicitly through one or more equations/functions. The specification further explains that the representations can be based on simple math, including simple mathematical expression, ordinary arithmetic operations, and basic mathematical function ([0053]). Accordingly, under the BRI in light of the specification, the claimed “determining … implicit function” requires determining a mathematical function or equation describing the geometry of the CAD body and therefore recites a mathematical concepts. The Examiner’s conclusion is not based merely on the presence of the phrase “implicit function.” Rather, the pending claims requires the step of determining the implicit function for the CAD body. Under the BRI in light of the specification, the subject matter being determined is a mathematical function or equation that describes the geometry of the CAD body. Accordingly, the limitation recites a mathematical concepts under MPEP 2106.04(a)(2)(I).
Furthermore, the Examiner respectfully disagrees with Applicant's argument that the claims do not recite any mental processes that can practically be performed in the human mind.
Under the broadest reasonable interpretation in light of the specification, claims 1 and 8 broadly recite determining … obfuscating … and expressing .... Claim 15 broadly recites determining a code representation for a CAD body … wherein the first external function is configured to … wherein the code representation is configured to … expressing at least a portion of the code representation … However, the claims do not require any particular complexity of the implicit function, any particular obfuscation technique, any particular programming language, code structure, computer specific implementation of the sparse field structure or abstract syntax tree, or execution of the code. Accordingly, the Examiner’s determination is based on the breadth of the particular limitations as claimed, not merely on the fact that the claims refer to software or code. These steps include observation, evaluation, judgment, reasoning processes that can be performed mentally or with the aid of pen and paper (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).).
Applicant’s reliance on SRI Int’l, Inc. v. Cisco Systems, Inc., is not persuasive. In SRI, the claims required detecting suspicious activity using network monitors and analyzing network packets, which the human mind was not equipped to perform. In contrast, the pending claims do not require comparable machine dependent operations, such as operating network monitors or analyzing computer network packets. Rather, under the BRI, the identified limitations broadly encompass evaluating geometric information, determining how that information is represented or obfuscated, and expressing the correspond functions in coded form, without requiring a particular computer specific technique or execution of the code. These steps can be performed mentally or with the aid of pen and paper because the claims do not restrict them to a specific implementation.
Further, Applicant’s argument that this reasoning, would cause all software or code limitations to be treated as mental processes is also not persuasive. The Office is not taking the position that every claim involving software or code recites a mental process. Whether a limitation falls within the mental processes grouping depends on what the particular limitation actually requires under its broadest reasonable interpretation. The pending claims broadly recite the determining, obfuscating, and expressing operations without requiring execution of the code or another computer operation that could not practically be performed by a human.
Further, Applicant’s cited neural network example does not change the analysis. Writing code that could perform a claimed neural network training operation is not itself performing the training operation. In contrast, the limitations identified as mental processes are the broadly recited determining, obfuscating , and expressing operations themselves, and the present rejection explains how those operations, as claimed, can practically be performed through observation, evaluation, judgment, and reasoning processes.
Therefore, the identified limitation are direct to a “mental process”, similar to the comparison steps in MPEP § 2106.04(a)(2)(III), and claims 1, 8 and 15 remain directed to a judicial exception under Step 2A, Prong 1.
With respect to the Applicant’s argued rejection under 35 U.S.C. § 101 in “Applicant Arguments/Remarks Made in an Amendment,”:
Applicant argues:
C. Step 2A, Prong 2: Even if the Claims Recite a Judicial Exception, Any Such Exception is Integrated into a Practical Application
Even if one considers the claims to recite an abstract idea under Step 2A, Prong 1, though Applicant believes they do not, proceeding to the Prong 2 analysis would show that the claims recite a practical application of any such abstract idea, and therefore are not "directed to" the abstract idea. "Only when a claim recites a judicial exception and fails to integrate the exception into a practical application, is the claim 'directed to' a judicial exception, thereby triggering the need for further analysis pursuant to the second step of the Alice/Mayo test (USPTO Step 2B)." (2019 PEG at 5).
Prong 2 of Step 2A asks whether the alleged judicial exception is integrated into a practical application, as indicated (for example) by the claims applying, relying on, or using the abstract idea in a manner that imposes a meaningful limit on the judicial exception. Notably, "Step 2A specifically excludes consideration of whether the additional elements represent well-understood, routine, conventional activity. Accordingly, in Step 2A Prong Two, examiners should ensure that they give weight to all additional elements, whether or not they are conventional, when evaluating whether a judicial exception has been integrated into a practical application. Additional elements that represent well- understood, routine, conventional activity may integrate a recited judicial exception into a practical application." MPEP 2106.04(d)(1).
Applicant respectfully submits that one or more additional features are recited in the claims to apply, rely on, and/or use the purported abstract idea, such that each claim as a whole integrates any such abstract idea into a practical application. Applicant addresses independent claims 1 and 8 below, and then addresses newly amended independent claim 15.
Claims 1 and 8
Claim 1 recites the following:
…
Applicant respectfully submits that one or more additional features are recited in the claims to apply, rely on, and/or use the purported abstract idea, such that each claim as a whole integrates any such abstract idea into a practical application. Specifically, even if one interprets "determining, ..., at least one implicit function and a proprietary geometry representation for a CAD body; obfuscating, with the source computing system, the proprietary geometry representation in a corresponding external function; expressing, ..., the at least one implicit function and the external function as code" to be abstract ideas, though Applicant maintains that they are not, claim 1 still recites the following "additional" elements:
providing, with the source computing system, the code to a target system; and
displaying the CAD body at the target system based on the code.
As explained in the MPEP at 2106.04(d)(III), “[t]he Prong Two analysis considers the claim as a whole. That is, the limitations containing the judicial exception as well as the additional elements in the claim besides the judicial exception need to be evaluated together to determine whether the claim integrates the judicial exception into a practical application." This is because "the way in which the additional elements use or interact with the exception may integrate it into a practical application. Accordingly, the additional limitations should not be evaluated in a vacuum, completely separate from the recited judicial exception. Instead, the analysis should take into consideration all the claim limitations and how those limitations interact and impact each other when evaluating whether the exception is integrated into a practical application." Id.
Applicant respectfully submits that the present rejection is erroneous because it impermissibly evaluates the allegedly abstract and additional claim elements separately from one another, in a vacuum, rather than taking into consideration the way these elements interact and impact each other. For example, the Office action states at page 18 that the step of providing the claimed code to a target system is "insignificant extra-solution activity," even though the specification plainly states (and the claim plainly reflects) that the claimed method is a solution to the technical problems that arise in attempting to provide CAD files to a target system from the source system. Because the Office action divorces the allegedly abstract elements from the additional elements, it fails to evaluate the way these elements interact with each other to improve CAD technology.
Furthermore, the Office action states at page 18 that the additional elements cannot integrate the allegedly abstract ones into a judicial exception because they "are performed by conventional computers" and "are generic computer components." This statement is legal error, because the MPEP expressly prohibits examiners from considering whether "additional" elements are well-understood, routine, or conventional at Prong 2 of Step 2A. "Step 2A specifically excludes consideration of whether the additional elements represent well-understood, routine, conventional activity. Accordingly, in Step 2A Prong Two, examiners should ensure that they give weight to all additional elements, whether or not they are conventional, when evaluating whether a judicial exception has been integrated into a practical application. Additional elements that represent well-understood, routine, conventional activity may integrate a recited judicial exception into a practical application." MPEP at 2106.04(d)(1). Accordingly, the "additional" elements of claim 1 must be fully evaluated at Prong 2, and should be found to integrate the allegedly abstract elements into a practical application of CAD exchange.
The Office action states at page 17 that the computer improvements identified by Applicant (described above with reference to the streamlined analysis) arise from the allegedly abstract claim elements and further states that "Improvements within the abstract idea cannot supply integration under Step 2A prong 2." To the extent the Office action is saying that allegedly abstract claim elements should be excluded when evaluating integration into a practical application, or that the claims only reflect an improvement to an abstract idea, Applicant disagrees and respectfully submits the Office action is erroneous. The rule is that "an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology," MPEP at 2106.05(a)(II), not that the improvement in technology must be wholly unrelated to the allegedly abstract elements. On the contrary, "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 when determining whether the claim provides an improvement to the functioning of computers or an improvement to other technology or technical field." MPEP at 2106.05(a), emphasis added. In other words, the allegedly abstract element may be integrated into a practical application even if that element helps give rise to the improvement to computer technology. If this were not so, then the only way for a claim reciting an abstract idea to be patentable would be if the abstract idea were wholly extraneous to the claimed invention.
Additionally, it is not the case that the improvement reflected by the claims is an improvement to an abstract idea, like an improved economic or mathematical concept. It would be difficult to assert with a straight face that the improvements identified in the specification - for example, smaller data transfer, avoiding a poorly structured data format, facilitating parametric editing, or allowing CAD bodies to be transferred without exposing proprietary geometries - could possibly be understood as improvements to the allegedly abstract idea of determining an implicit equation, or improvements to the allegedly abstract idea of obfuscating a geometry representation in an external function. Instead, the improvements are very clearly improvements to the computer technology of CAD exchange. The fact that the improvements arise from the claim as a whole - including the allegedly abstract elements as well as the additional ones - cannot, as a matter of law, prevent the claim from integrating the alleged abstract ideas into a practical application.
In order to facilitate an accurate Prong 2 analysis, the MPEP lays out a specific framework for evaluating whether a claim as a whole is directed to an improvement in the functioning of a computer or technology. "In short, 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. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. . . . Second, if the specification sets forth an improvement in technology, the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. That is, the claim includes the components or steps of the invention that provide the improvement described in the specification. The claim itself does not need to explicitly recite the improvement described in the specification (e.g., "thereby increasing the bandwidth of the channel")." MPEP at 2106.04(d)(1).
As explained in Applicant's October 27 response to the previous Office action, following the guidance provided for the MPEP for exactly this type of claim avoids the legal errors described above (i.e., considering the additional elements in a vacuum and discounting improvements that are provided by the additional elements in combination with the allegedly abstract ones), and shows that claim 1 is directed to a computer improvement. Departing from the MPEP's instructions for this type of claim makes the above-described errors difficult to avoid and thus results in a legally unsustainable rejection.
For at least these reasons, as well as the reasons set forth in Applicant's October 27 response, Applicant respectfully traverses the Office action's Prong 2 analysis and submits that claim 1 is eligible for patenting.
Claim 8 recites the following:
…
Thus, claim 8 is eligible for patenting at least for reasons similar to those set forth
above with respect to claim 1.
Claim 15
…
Applicant submits that claim 15 should be found eligible at Prong 2 for reasons similar to those set forth above with respect to claims 1 and 8. Additionally, claim 15 recites that determining the code representation for the CAD body includes expressing at least a portion of the code representation as an abstract syntax tree, that the code representation for the CAD body comprises first code expressing one or more implicit equations/functions corresponding to the CAD body and second code configured to call a first external function, and that the first external function is configured to obfuscate a proprietary geometry of the CAD body via a sparse field structure.
Applicant respectfully submits that these specific, computer-based features are not abstract ideas and are not insignificant extra-solution activity. On the contrary, these features represent specific computer implementations that enable specific improvements to computer technology. The present Office action had suggested that previously pending claim 15 (and unamended claims 1 and 8) were not comparable to the claims of the Appeals Review Panel (ARP) decision in In re Desjardins on the grounds that the ARP decision "involved claims that improved computer performance through specific" software implementation (namely, algorithmic implementation and adaptive computation). Although Applicant maintains that previously pending claim 15 (and unamended claims 1 and 8) also improve computer performance in a manner analogous to the ARP claims, Applicant further submits that the specific implementation now recited in amended claim 15 should alleviate any concern that the claim lacks sufficient specificity to improve a computer technology. Accordingly, Applicant submits that claim 15 satisfies the Prong 2 analysis and should be found eligible for patenting.
(See Response filed 05/18/2026 [pages 17-23]).
The Examiner respectfully disagrees with Applicant’s argument that the one or more additional features are recited in the claims to apply, rely on, and/or use the purported abstract idea, such that each claim as a whole integrates any such abstract idea into a practical application.
As explained in MPEP § 2106.04(d)(II), “The analysis under Step 2A Prong Two is the same for all claims reciting a judicial exception, whether the exception is an abstract idea, a law of nature, or a natural phenomenon (including products of nature). Examiners evaluate integration into a practical application by: (1) identifying whether there are any additional elements recited in the claim beyond the judicial exception(s); and (2) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application, using one or more of the considerations introduced in subsection I supra, and discussed in more detail in MPEP §§ 2106.04(d)(1), 2106.04(d)(2), 2106.05(a) through (c) and 2106.05(e) through (h).”
The Office has considered the claimed limitations together, rather than in isolation. When the determining, obfuscating, and expressing limitations are considered together with the recited computing systems, providing the code to the target system, and displaying the CAD body based on the code, the additional limitations merely provide a computer environment and transmit and display the result of the recited abstract processing. The additional limitations do not recite a particular technological implementation by which the computing system, transmission, or display improve computer functionality or CAD technology, or otherwise meaningfully limit the judicial exception. Accordingly, even when the claim is considered as whole, the additional limitations do not integrate the judicial exception into practical application.
Furthermore, the Examiner respectfully disagrees with Applicant’s argument that the steps of providing the code to a target system and displaying the CAD body at the target system are not insignificant extra-solution activity. In particular, the providing limitation transmits the resulting code after the code has been determined and expressed, and the displaying limitation presents the CAD body based on the resulting code. The fact that these operations are performed in the context of CAD exchange does not itself establish that they meaningfully limit the judicial exception. The claims do not recite a particular technical manner in which the transmission or display is performed that meaningfully limits the identified judicial exception. Thus, even when these limitations are considered together with the other claim limitations, the providing and displaying steps amount to post-solution transmission and output data and do not integrate the judicial exception into a practical application. MPEP § 2106.05 (g).
The Examiner agrees that an asserted technological improvement may arise from the additional limitations in combination with the judicial exception and that the claim must be considered as a whole. However, that principle does not establish that the pending claims provide such an improvement. Although the claim need not expressly recite the stated result of an improvement, the claim must reflect the feature that provide the asserted technological improvement. However, when the additional limitations are considered together with determining, obfuscating and expressing limitations, they merely provide the computer environment, transmit the resulting code, and display the resulting CAD body. The claims do not recite a particular technical manner in which the resulting code is processed or used at the target system to achieve the asserted improvement. For example, the claims do not recite how the code is evaluated or executed at the target system to generate or process the CAD geometry, or any particular manner in which the transmission or display operations are technically improved. Instead, the claims broadly require providing the resulting code to the target system and displaying the CAD body based on the code. Accordingly, Applicant’s asserted benefits, such as reduced data transfer, improved editability, or protection of proprietary geometry, do not establish integration where the claimed additional limitations merely implement, transmit, and display the result of the identified judicial exception without reciting how those additional limitations technically achieve the asserted improvement. Therefore, claims 1 and 8 do not integrate the recited judicial exception into a practical application under Step2A, prong 2.
Further, with respect to amended claim 15, Applicant’s arguments have been considered but are not persuasive for the reasons set forth in the current Step 2A analysis. The newly recited code representation, first and second code, external function, sparse field structure, and abstract syntax tree limitations have been specifically evaluated under Prong 1. Thus, Applicant’s characterization of these limitations as specific computer implementations does not alter the analysis in the present Office action. Further, as explained under Prong 2, even where the configured obfuscation and import/display functionality is alternatively treated as an additional limitation, the recited functionality does not recite a particular technological mechanism that integrates the identified judicial exception into a practical application. Therefore, claim 15 does not integrate the recited judicial exception into a practical application under Step2A, prong 2.
Therefore, for the reasons discussed above, Applicant’s arguments have been considered but are not persuasive. The claims 1, 8, and 15 recite judicial exceptions, including mathematical concepts and/or mental processes, do not integrated judicial exception into a practical application under step 2A. Accordingly, the rejection of claims 1, 8 and 15, and the claims dependent therefrom, under 35 U.S.C. § 101 is maintained.
Applicant' s arguments, “Applicant Arguments/Remarks Made in an Amendment,” at pages 23-32,
filed 05/18/2026, with respect to the rejection(s) of claim(s) 1, 8, and 15 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 newly found prior art reference(s).
For claims 1 and 8:
The newly applied reference Min (“Function-based 3D Web Visualization,” published in 2002) teaches a function-based CAD exchange architecture in which parametric or implicit functions are used to define geometric shapes and proprietary function-defined models are supported using corresponding model-specific Parser and Polygonizer components. Min further teaches expressing the implicit function as HyperFun/VRML code and implementing the corresponding Parser and Polygonizer components as DLLs having callable functions, and providing the function-defined model code from a remote content server to a client system for processing and display.
The newly applied reference Nam (US20160203087A1) teaches protecting or obfuscating information associated with callable DLL functionality by separating source code logic into a DLL, encrypting the DLL, and storing the encrypted DLL in a plug-in.
The newly applied reference Miller (US20130125029A1) teaches providing executable code expressing external functionality from a source system to a target system. In particular, Miller teaches a modeling server providing a modeling client or modeling engine to a client device, where the provided component includes compiled code having callable functions and may be implemented as a DLL and loaded at the client as a browser plug-in.
Therefore, the combination of Min in view of Nam and Miller teaches or suggests the limitations of claims 1 and 8. Accordingly, a new rejection of claims 1 and 8 under 35 U.S.C. § 103 is made based on the newly applied prior art combination.
For claim 15:
The newly applied reference Min (“Function-based 3D Web Visualization,” published in 2002) teaches representing a CAD model using a function-based model description, including HyperFun code having mathematical expressions corresponding to implicit functions defining the geometry and function invocation statements calling functions supplied by the FRep library. Min further teaches providing the function defined-model description from a server to a client system, where the model description is parsed and polygonized for display, including support for proprietary function defined models.
The newly applied reference Miller (US20130125029A1) teaches computer executed 3D modeling software and instructions at a source computing system, and further teaches locally displaying a 3D model using script instructions that manipulate or create objects through a 3D modeling engine.
The newly applied reference Maetz (US20140119538A1) teaches protecting or obfuscating the geometry of a 3D object by applying a selected protection function to coordinates defining the geometry, thereby producing a protected representation of the 3D object. Maetz further teaches transmitting the protected 3D object to a receiving system and rendering the protected 3D object at the receiving system.
The newly applied reference Shepherd (US20210201537A1) teaches representing a 3D model using voxel data in which changes between spatially adjacent voxel rows are represented as delta data, and further run length encoding and encrypting the resulting delta voxel representation. Under the BRI applied in the rejection, this representation reads on the claimed sparse field structure because the 3D voxel field is represented using encoded changes while regions having no changes are compactly represented.
The newly applied reference Kilpatrick (US20090122062A1) teaches representing code as an abstract syntax tree. In particular, Kilpatrick teaches parsing shader language code and generating an abstract syntax tree from the shader code.
Therefore, the combination of Min in view of Miller, Maetz, Shepherd, and Kilpatrick teaches or suggests the amended limitations of claim 15. Accordingly, a new rejection of claim 15 under 35 U.S.C. § 103 is made based on the newly applied prior art combination.
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 claims 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 Revised Patent Subject Matter Eligibility Guidance
published in the Federal Register 01/07/2019, as well as subsequent USPTO eligibility guidance updates,
and has provided such analysis below.
Step 1: Are the claims to a process, machine, manufacture or composition of matter?"
Yes, Claims 1-7 are directed to method and fall within the statutory category of process;
Yes, Claims 8-14 are directed to system and fall within the statutory category of machine;
Yes, Claims 15-20 are directed to non-transitory computer-readable storage medium and fall within the statutory category of manufacture.
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:
Mental Processes:
As explained in MPEP 2106.04(a)(2)(III): Nor do the courts distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer. As the Federal Circuit has explained, "[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind." Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015). See also Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1318, 120 USPQ2d 1353, 1360 (Fed. Cir. 2016) (‘‘[W]ith the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.’’); Mortgage Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324, 117 USPQ2d 1693, 1699 (Fed. Cir. 2016) (holding that computer-implemented method for "anonymous loan shopping" was an abstract idea because it could be "performed by humans without a computer").
Further, as explained in MPEP 2106.04(a)(2)(III)(A): In contrast, claims do recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
• claims to "comparing BRCA sequences and determining the existence of alterations," where the claims cover any way of comparing BRCA sequences such that the comparison steps can practically be performed in the human mind, University of Utah Research Foundation v. Ambry Genetics, 774 F.3d 755, 763, 113 USPQ2d 1241, 1246 (Fed. Cir. 2014);
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011); and
• a claim to identifying head shape and applying hair designs, which is a process that can be practically performed in the human mind, In re Brown, 645 Fed. App'x 1014, 1016-17 (Fed. Cir. 2016) (non-precedential).
Further, as explained in MPEP 2106.04(a)(2)(III)(C): 1. Performing a mental process on a generic computer. An example of a case identifying a mental process performed on a generic computer as an abstract idea is Voter Verified, Inc. v. Election Systems & Software, LLC, 887 F.3d 1376, 1385, 126 USPQ2d 1498, 1504 (Fed. Cir. 2018) … 2. Performing a mental process in a computer environment. An example of a case identifying a mental process performed in a computer environment as an abstract idea is Symantec Corp., 838 F.3d at 1316-18, 120 USPQ2d at 1360 … 3. Using a computer as a tool to perform a mental process. An example of a case in which a computer was used as a tool to perform a mental process is Mortgage Grader, 811 F.3d. at 1324, 117 USPQ2d at 1699.
Claim 1: The limitations of “determining … at least one implicit function and a proprietary geometry representation for a CAD body,” as drafted, is process that, but for the recitation of generic computing components (i.e., “source computing system”), under the broadest reasonable interpretation (BRI) in light of the specification, covers performance of the limitation in the human mind.
For example, a person is capable of observing the shape and geometric characteristics of a CAD object, determining a simple equation or function that implicitly represents the shape, and determining a representation for proprietary geometric characteristics associated with the CAD object. The steps include observation, evaluation, judgment, and reasoning processes that can be performed mentally or with the aid of pen and paper (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 claimed limitation is broadly recited and does not require the implicit function to have any particular complexity or require the proprietary geometry representation to have any particular form, complexity, or computer specific structure. The recited “determining” does not require a technological process or computer specific operation beyond human evaluation and judgement in identifying an implicit function and a proprietary geometry representation for the CAD body. Accordingly, under BRI, the claimed determining step cover a process that can be performed in the human mind or with the aid of pen and paper. See MPEP 2106.04(a)(2)(III).
Claim 1: The limitations of “obfuscating … the proprietary geometry representation in a corresponding external function,” as drafted, is process that, but for the recitation of generic computing components (i.e., “source computing system”), under the broadest reasonable interpretation (BRI) in light of the specification, covers performance of the limitation in the human mind.
For example, a person is capable of reviewing information describing proprietary geometry of an object and mentally determining how to describe the proprietary geometry without directly revealing its underlying geometric information, and expressing that description as a separately defined function. The steps include observation, evaluation, judgment, and reasoning processes that can be performed mentally or with the aid of pen and paper (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 claimed limitation is broadly recited and does not require any particular obfuscation technique or require the external function to have any particular form, complexity or computer specific structure. The recited obfuscating operation does not require a technological process or computer specific operation beyond human evaluation and judgement concerning how the proprietary geometry representation is determined in the corresponding external function. Accordingly, under the BRI, the claimed obfuscating step covers a process that can be performed in the human mind or with the aid of pen and paper. See MPEP 2106.04(a)(2)(III).
Claim 1: The limitations of “expressing … the at least one implicit function and the external function as code,” as drafted, is process that, but for the recitation of generic computing components (i.e., “source computing system”), under the broadest reasonable interpretation (BRI) in light of the specification, covers performance of the limitation in the human mind.
For example, a person is capable of considering/reviewing a mathematical description of an object and a separately defined function, mentally determining a coded expression for each function, and writing the coded expressions using pen and paper. The steps include observation, evaluation, judgment, and reasoning processes that can be performed mentally or with the aid of pen and paper (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 claimed limitation is broadly recited and does not require any particular programming language, code structure, level of complexity, execution of the code, or computer specific process for expressing the function as code. The claimed “expressing” does not require a technological process or computer specific operation beyond human evaluation and reasoning in formulating each function in coded form. Accordingly, the limitation is broad enough to cover a person determining how the functions should be written and writing corresponding code to represent the functions. Therefore, under the BRI, the claimed expressing step covers a process that can be performed in the human mind or with the aid of pen and paper. See MPEP 2106.04(a)(2)(III).
Claim 15: The limitations of “determining a code representation for a CAD body, the code representation comprising first code expressing one or more implicit equations/functions corresponding to the CAD body, and second code configured to call a first external function;
wherein the first external function is configured to obfuscate a proprietary geometry of the CAD body via a sparse field structure;
…
wherein the code representation is configured to allow for import and display of the CAD body, including the obfuscated proprietary geometry of the CAD body, at the target system; and
wherein determining the code representation for the CAD body includes expressing at least a portion of the code representation as an abstract syntax tree.,” as drafted, is process that, but for the recitation of generic computing components, under the broadest reasonable interpretation (BRI) in light of the specification, covers performance of the limitation in the human mind.
For example, a person is capable of reviewing/observing the shape of a CAD object, describing the shape using a simple equation or function, writing a first coded expression for the equation or function, writing a second coded expression directing a call to another function, indicating that the called function is intended to represent proprietary geometry in an obfuscated manner using a sparse field structure, indicating that the coded expression is intended to permit import and display of the CAD body, including the obfuscated proprietary geometry of the CAD body, at another system, and arranging at least a portion of the coded expressions in a tree like hierarchical form. The steps include observation, evaluation, judgment, reasoning and organizing processes that can be performed mentally or with the aid of pen and paper (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 claimed limitation is broadly recited and does not require any particular complexity, machine execution, or computer specific implementation for the implicit questions/functions, code representation, external function call, sparse filed structure, or abstract syntax tree. The recited limitations broadly encompass formulating and organizing information, specifying relationships among portions of the information, and assigning intended functions or purposes to those portions, without requiring that the recited configured functionality actually be performed as part of the determining step. Therefore, under the BRI, the claimed determining step covers a process that can be performed in the human mind or with the aid of pen and paper. See MPEP 2106.04(a)(2)(III).
In addition, as explained 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.
Mathematical Concepts:
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).
Further, as explained in 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, as explained in MPEP 2106.04(a)(2)(I)(C)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 limitations of “determining … at least one implicit function … for a CAD body,” under its broadest reasonable interpretation (BRI) in light of specification, recites a mathematical concept, including a mathematical relationship, formula, or equation. In particular, the specification explains in paragraph [0031] that an implicit equation/function can be the signed distance function (SDF) of a mesh of a given one of the CAD body. Paragraph [0035], With reference to Fig. 4, further explains implicits can describe shapes in terms of equations/functions and illustrates that a circle can be described implicitly through one or more equations/functions. The specification further explains that the representations can be based on simple math, including simple mathematical expression, ordinary arithmetic operations, and basic mathematical function ([0053]). Accordingly, under the BRI in light of the specification, the claimed implicit function constitutes a mathematical relationship, formula, or equation describing the geometry of the CAD body. Thus, determining the at least one implicit function recites a mathematical concept. See MPEP 2106.04(a)(2)(I).
Claim 8 recites the similar elements as claim 1, and is rejected for the same reasons under 35 U.S.C. 101.
Therefore, claims 1, 8 and 15 recites judicial exceptions. The claim has been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2: Claims 1, 8 and 15: The judicial exception is not integrated into a practical application.
The additional limitations of "source computing system” and “A system for computer aided design (CAD) exchange comprising: a source computing system including at least one source computing system processor; a target computing system including at least one target computing system processor; a source computing system memory storing instructions that, when executed by the at least one source computing system processor, cause the source computing system to perform:” and “a target computing system memory storing instructions that, when executed by the at least one target computing system processor, cause the target computing system to …” 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 merely recitations of instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to implement the judicial exception, which does not integrate judicial exception into a practical application (see MPEP §2106.05(f)).
Further, the additional limitations of “providing, with the source computing system, the code to a target system; and displaying the CAD body at the target system based on the code” and “providing the code to the target computing system … display the CAD body based on the code” and “providing the code representation to a target system; and displaying the CAD body using the code representation with the source computing system,” which are merely recitations of insignificant extra-solution activity, such as data gathering (i.e., providing or transmitting code from source system to target system) and data output (i.e., displaying CAD body at target system or source system) which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). These 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 code is transferred from source system to a target system, and displayed CAD body based on the code at target system or source system at a high level of generality.
Additionally, for claims 1 and 8, adding the steps of providing the determined code representation to a target system and displaying the CAD body based on the code representation at the target system to a process that recites determining implicit function and proprietary geometry, obfuscating proprietary geometry, and expressing the CAD body information as code (identified judicial exception) does not add a meaningful limitation to the process of determination, obfuscation and expression. Rather, the providing step merely transmits the resulting code representation after it has been determined, and the displaying step merely outputs or presents the CAD body based on the resulting code representation. Thus, the limitation constitutes post-solution activities and does not meaningfully limit the process of determining implicit function and proprietary geometry, obfuscating proprietary geometry, and expressing the CAD body information as code.
Similarly, for claim 15, adding the steps of providing the code representation to a target system; and displaying the CAD body using the code representation with the source computing system to a process that recites determining a code representation having the recited code expressions, configured functionality, and abstract syntax tree organization (identified judicial exception) does not add a meaningful limitation to the process of determination. Rather, the providing step merely transmits the resulting code representation after it has been determined, and the displaying step merely outputs or presents the CAD body based on the resulting code representation. Thus, the limitation constitutes post-solution activities and does not meaningfully limit the process of determining the code representation.
Alternatively, even if the limitations of “wherein the first external function is configured to obfuscate a proprietary geometry of the CAD body via a sparse field structure” and “wherein the code representation is configured to allow for import and display of the CAD body, including the obfuscated proprietary geometry of the CAD body, at the target system,” are considered as additional limitations beyond the identified judicial exception, these limitations do not integrated judicial exception into practical application. The limitations merely apply the determined code representation using the recited computer functionality by specifying that the external function is configured to obfuscate proprietary geometry via a sparse field structure and that the code representation is configured to permit import and display of the CAD body at a target system. These limitations recite the functions or results to be achieved using the determined code representation, without specifying a particular computer operation or technological mechanism by which those functions or results are accomplished. Thus, the recited computer functionality merely uses a computer as a tool to perform the identified mental process and does not meaningfully limit the judicial exception. See MPEP § 2106.05(f).
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 inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 8 and 15 are 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, 8 and 15: The claim does 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.
As explained in MPEP 2106.05(A), “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));
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)).”
As explained in MPEP 2106.05(d)(II), “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network, …; ii. Performing repetitive calculations, … iii. Electronic recordkeeping, … (updating an activity log). iv. Storing and retrieving information in memory,…”
In particular, the additional limitations of claims 1 and 8, when considered individually and in combination, do not amount to significantly more than the judicial exception. The recited source computing system and target system merely provide computer components for implementing the claimed functions, while providing the code to the target system and displaying the CAD body based on the code merely ordinary functions of transmitting and displaying the result of the judicial exception. The claims do not recite a particular unconventional computer architecture, data transmission mechanism, or display mechanism.
Further, the additional limitations of claim 15, when considered individually and in combination, do not amount to significantly more than the judicial exception. The recited readable storage medium, processor, source computing system, and target system merely provide computer components for implementing the claimed functions. The providing and displaying limitations perform ordinary functions of transmitting and displaying the result of the judicial exception, while the recited configured functionalities does not require a particular unconventional computer implementation.
In addition, Tsukahara (US20010024230A1) teaches, in the BACKGROUND OF THE INVENTION, that conventionally a 3D virtual reality spatial image is transmitted from a server to a client computer as a VRML file, and the client computer, based on the receive VRML file, generates and displays the corresponding 3D virtual reality spatial image ([0004]). Thus, the reference evidences that providing code from a source system to a target system and displaying a corresponding geometry at the target system based on the received code were well-understood, routine and conventional.
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, 8 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Dependent claims 2-7, 9-14 and 16-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 (or mathematical operations) or providing additional definition of process which does not impose any meaningful limits on practicing the abstract idea. Claims 2-7, 9-14 and 16-20 are also rejected for incorporating the deficiency of their independent claims 1, 8 and 15.
Claim 2 recites “determining, with the source computing system, a traditional geometry representation for the CAD body, and wherein the code includes a call to an external function stored on the target system and corresponding to the traditional geometry representation,” as drafted, is process that, but for the recitation of generic computing components (i.e., “source computing system”), under the broadest reasonable interpretation (BRI) in light of the specification, covers performance of the limitation in the human mind.
For example, a person is capable of considering/reviewing the geometry of a CAD object, selecting a traditional geometry representation for representing the geometry, and writing code that includes a call to another function stored on a different system and corresponding to the selected geometry representation. The steps include observation, evaluation, selection, judgment, and reasoning processes that can be performed mentally or with the aid of pen and paper (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 claimed limitation is broadly recited and does not require the traditional geometry representation or external function call to have any particular complexity, code structure, programming language, or computer-specific implementation. Accordingly, the limitation is broad enough to cover a person selecting a relatively simple traditional representation for geometry and writing code that specifies a call to another function corresponding to the representation. Therefore, under the BRI, the claimed limitation can be performed in the human mind or with the aid of pen and paper. See MPEP 2106.04(a)(2)(III). Therefore, the claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 3 recites “providing to the target system, with the source computing system, a backup texture for the CAD body.”
This limitation merely further specifies transmitting a backup texture associated with the CAD body from the source computing system to the target system. It merely a recitations of insignificant extra-solution activity such as data gathering (i.e., providing additional data to the target system), which does not integrate a judicial exception into practical application or amount to significantly more than the judicial exception. See MPEP § 2106.05(g). Therefore, the claim 3 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 4 recites “obfuscating the proprietary geometry representation is performed using a sparse field structure.”
This limitation merely further specifies that the obfuscating process is performed using a sparse filed structure. The limitation merely applies the judicial exception using a computer implementation without reciting how the sparse field structure changes the obfuscating process or effects an improvement in the functioning of a computer or another technology or technical field. Thus, the limitation amounts to mere instructions to apply the judicial exception using a computer as a tool, which does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception. See MPEP§ 2106.05(f). Therefore, the claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 5 recites “determination of the at least one implicit function comprises determination of a signed distance function (SDF).”
This limitation merely further specifies the implicit function determined in claim 1 as a signed distance function (SDF). A SDF defines a mathematical relationship between a point and its singed distance relative to a boundary or surface. Thus, the limitation recites a mathematical concept. Therefore, the claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 6 recites “the code accepts varying inputs, and wherein the varying inputs allow for one or more of parametric edits and manufacturing process correction at the target system.”
This limitation merely further specifies that the code is capable of accepting varying inputs that allow for parametric edits or manufacturing process correction at the target system. The limitation does not require the parametric edits to actually be performed, but merely further characterizes the code by the inputs it is intended to accept and results those inputs are intended to permit. Thus, it merely an extension of metal process (e.g., mentally defining or organizing a code representation to accept varying inputs). Therefore, the claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 7 recites “a portion of the code is further provided to a graphics processing unit of the source computing system to allow display of the CAD body by the source computing system.”
This limitation merely further specifies providing a portion of the code to a GPU of the source computing system to allow display of the CAD body. It merely an insignificant extra-solution activity, i.e., transmitting the resulting code to GPU for subsequent display of the CAD body, which does not integrate a judicial exception into practical application or amount to significantly more than the judicial exception. See MPEP § 2106.05(g). Therefore, the claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 16 recites “convert the code representation from a first computer language to a second computer language.”
This limitation merely further specifies converting the code representation determined in claim 15 from on computer language to another computer language. The limitation merely applies the judicial exception using a computer as tool, without reciting a particular manner of performing the conversion that improves the functioning of the computer or another technology or technical field. Thus, the limitation does not integrate the judicial exception into a practical application or amount to significantly more than the judicial exception. See MPEP§ 2106.05(f). Therefore, the claim 16 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 19 recites “provide to the target system a kernel of a CAD program of the source computing system, the kernel including the first external function.”
This limitation merely further specifies providing a CAD program kernel, including the first external function, from the source computing system to the target system. it merely an recitations of insignificant extra-solution activity, i.e., transmitting additional information to the target system, which does not integrate a judicial exception into practical application or amount to significantly more than the judicial exception. See MPEP § 2106.05(g). Therefore, the claim 19 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim 20 recites “the code representation further comprises at least one input parameter, and the code representation is configured to allow the at least one input parameter to be edited at the source computing system or at the target system.”
This limitation merely further specifies that the code representation includes input parameter and is configured to allow the input parameter to be edited at the source system or target system. The limitation does not require the input parameter to actually be edited, but merely further characterizes the code representation by identifying an editable input parameter and where the parameter may be edited. Thus, it is an extension of mental process (e.g., mentally formulating or organizing a code representation having an editable input parameter). Therefore, the claim 20 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 9-14 and 17-18 recite the similar elements as claims 2-7, 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 and 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over
Min (“Function-based 3D Web Visualization,” published in 2002) in view of Nam US20160203087A1 and Miller US20130125029A1.
Claim 1, Min teaches A computer-implemented method for computer aided design (CAD) exchange (Page.1, Abstract; 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.”);
determining, with a source computing system , at least one implicit function and a proprietary geometry representation for a CAD body (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.2. VRML and its existing extensions, right column, “VRML is the most common format adopted to define 3D objects in the virtual web spaces. We have chosen it to integrate with function-based modeling technique for web visualization … This approach allows visualization of complex CAD models in VRML.” Page. 2.3. Function-defined geometric node, “In this project, a generic function-based node for VRML is proposed as a plug-in to a VRML browser. The idea of introducing such a node is to replace large polygonal representations of complex shapes with small formulae … With the proposed architecture design, a new function-based geometric node, called FShape, has been proposed for VRML … With this node, the content publishers can present any proprietary function-defined model to the viewers since they can develop the respective parsing and polygonization modules.” Page.6, 5. Support for any proprietary function-defined models, “Some function-defined models may not have a specific description language like HyperFun. They may be just represented by some mathematical functions, which are used with the supplied data values. In order to support any proprietary function-defined models in FShape node, the publishers have to develop their own respective Parser and Polygonizer components based on the predefined plug-in interfaces … The VRML source code that links to this proprietary function model is shown in Figure 7 and the examples of using such function-defined shapes in a VRML scene are presented in Figure 8.” Examiner note: Min teaches that parametric or implicit functions are used to define geometric shapes, corresponding to claimed implicit function. Min further teaches that VRML is used to define 3D objects and is applicable to visualization of complex CAD models, and Min proposes integrating its function-based geometric representation into the VRML environment. Min further teaches proprietary function-defined models represented by mathematical functions and supplied data values and having corresponding model specific Parser and Polygonizer components, corresponding to the claimed proprietary geometry representation. Min further teaches that content publishers develop and provide these function-defined models within the proposed architecture, corresponding to determining the implicit function and proprietary geometry representation at the source side);
(Page.4, 3.2. Interaction between modules in the visualization pipeline, “ … For every supported function based model, the respective Parser module is to be developed separately with a set of standard function calls. The Parser component is created as a Win32 dynamic linked library (DLL), which has an extension “.par” … The required function for the Parser component is Parse(string szSrc), in which the data obtained by the Seeker component will be interpreted accordingly … Like the Parser component, the Polygonizer component is dependent on the chosen function language used to describe the model. For every supported function-based model, the respective Polygonizer component is to be developed and a set of standard function calls must be supported. The Polygonizer component is created as a Win32 DLL which has an extension “.pol”. Page.6, 5. Support for any proprietary function-defined models, “In order to support any proprietary function-defined models in FShape node, the publishers have to develop their own respective Parser and Polygonizer components based on the predefined plug-in interfaces. Developing a Parser depends on the model and/or language used, while developing a Polygonizer depends only on the model … The FShape node will dynamically load the corresponding Parser and Polygonizer components based on the string value stored in sourceType field.” Examiner note: Min teaches that each supported geometric model defined by functions has a respective Parser module having standard function calls and implemented as a Win32 DLL, and likewise has a respective Polygonizer implemented as a Win32 DLL, corresponding to the external function. Min further teaches that a proprietary geometric model defined by functions has its own respective Parser and Polygonizer components, which are model dependent and dynamically loaded as the “corresponding” components, thus teaching a proprietary geometry representation and a corresponding external function.);
expressing, with the source computing system, the at least one implicit function and the external function as code (Page.6, left column, “Alternatively, the model definition can be embedded directly into the VRML code via sourceString.” FIG 4. A sample HyperFun definition source, “my_model(x[3], a[1]) { … cube = 0.9-dX*dX-dY*dY-dZ*dZ; blend = hfBlendInt(cube,inside,0.8,0.2,0.3); my_model = blend }”. Page.4, 3.2. Interaction between modules in the visualization pipeline, “ … For every supported function based model, the respective Parser module is to be developed separately with a set of standard function calls. The Parser component is created as a Win32 dynamic linked library (DLL) … The required function for the Parser component is Parse(string szSrc) … For every supported function-based model, the respective Polygonizer component is to be developed and a set of standard function calls must be supported. The Polygonizer component is created as a Win32 DLL …Another required function for the Polygonizer component is Calc() …”. Examiner note: Min teaches that the geometric model definition may be embedded directly into VRML code and provides a HyperFun definition source containing mathematical expressions defining the geomatic shape, corresponding to expressing the implicit function as code. Min further teaches respective Parser and Polygonizer components implemented as Win32 DLLs with stand function calls, including Parse () and Calc (), corresponding to expressing the external function as code);
providing, with the source computing system, (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 … Alternatively, the description can be embedded in the VRML code.” Page.6, left column, “In this example, the HyperFun definition source is referred via a file reference. Alternatively, the model definition can be embedded directly into the VRML code via sourceString.” Examiner note: Min teaches that the remote content server provides a VRML file containing a function model description to the client and further teaches that the model definition may be embedded directly into the VRML code, corresponding to providing code expressing the implicit function from the source computing system to the target/client system).
However, Min fails to teach obfuscating the representation in a corresponding external function.
Nam teaches obfuscating the representation in a corresponding external function ([0011] … a DLL generation step of generating a security logic DLL made of common intermediate language code by compiling a source code of the secure logic used in the application; an encrypted DLL generation step of generating an encrypted DLL by encrypting the security logic DLL; and a security module plug-in generation step of generating a security module plug-in including the encrypted DLL. [0012] … a key algorithm or logic in a program source code … is separated into a separate file; made into a DLL; and then encrypted and stored in the native code plug-in. [0029] … The encryption unit 110 may encrypt the received DLL by using an encryption algorithm such as DES, AES and RSA …The security module plug-in generation unit 130 includes the received encrypted DLL … into the plug-in … Examiner note: Nam teaches protecting information comprising a key algorithm or logic by compiling the information into a DLL and encrypting the DLL. Nam further teaches that the DLL includes callable modules and is encrypted and stored in a native code plug-in. Therefore, Nam teaches obfuscating information contained in a DLL having callable modules by encrypting the DLL).
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 Min to incorporate the teaching of Nam, and apply Nam’s technique of compiling protected information into a DLL and encrypting the DLL to Min’s proprietary geometry information associated with the corresponding Parser/Polygonizer functionality, in order to prevent the proprietary geometry information from being exposed or analyzed, thereby providing increased protection for the proprietary geometry information.
However, Min in view of Nam fails to teach providing, with the source computing system, the code expressing the external function to a target system.
Miller teaches providing, with the source computing system, the code expressing the external function to a target system ([0029] … For example, the modeling engine 152 may be downloaded from the modeling server 106 each time a user develops a 3D model at the client device 102. To this end, the modeling server 106 may include tangible, non-transitory computer-readable medium on which the instructions of the modeling client 152 and script interface layer 154 are stored. [0034] The modeling client 210 may be provided as a plugin that extends the functionality of the browser 206. A modeling client 210 may include a scripting Application Programming Interface (API) 212 and a modeling engine 214. In particular, the modeling client 210 may include compiled code with functions that may be invoked by the browser 206. … The modeling client 210 may correspond to the 3D modeling software module 152, and may be provided by the modeling server 106 to the client device 102 in response to a request from the client device 102. [0042] The 3D modeling sub-system 275 includes a browser application 276 in which a 3D modeling engine 278 may operate as a plugin implemented, at least partially, as a set of compiled instructions. The 3D modeling engine 278 may be provided as a dynamic link library (DLL), for example. [0068] … the 3D Modeling System components (i.e., a modeling client 210, modeling engine 264, 278) may be requested by the browser as a plug-in component for the browser … The modeling components 210, 264, and 278, may also be sent to the client at bock 834. At block 836, both the modeling components 210, 264, and 278, may be loaded into the program memory 122 as a browser plug-in … Examiner note: Miller teaches a modeling server that provides a 3D modeling client or modeling engine to a client device. The modeling client includes compiled code having functions that may be invoked by the browser, and the modeling engine may be implemented as compiled instructions or a DLL. Miller further taches that the modeling components are sent from the server to the client and loaded as a browser plug-in. Thus, Miller taches providing, from a source computing system to a target computing system, code expressing executable external functionality).
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 Min in view of Nam to incorporate the teaching of Miller, and apply Miller’s technique of proving compiled code having callable functions from a modeling server to a client device to provide Min’s respective Parser and Polygonizer components to the client, in order to enable the client to obtain the corresponding executable components used to process the function defined model, thereby allowing Min’s respective Parser and Polygonizer functionality to be dynamically loaded and used at the client for processing the received model.
Claim 2, Min teaches The computer-implemented method for CAD exchange of claim 1, further comprising determining, with the source computing system, a traditional geometry representation for the CAD body, (Page.1, right column, “Among these services, the polygon mesh representation is often used to represent geometric models. Thus the most popular 3D web content format Virtual Reality Modeling Language (VRML) [8] uses this representation for complex objects. Although there are many workarounds to improve the overall experience in 3D web visualization, the mainstream of the current web visualization is based on the scenario where the publisher creates a 3D model rather than an image and sends it to the viewer, which then renders and manipulates the model.” Examiner note: Min teaches that a polygon mesh representation is used to represent geometric models and is used by ARML for complex objects. Min further teaches that the publisher creates the 3D model and sends the model to the viewer.).
However, Min in view of Nam fails to teach the code includes a call to an external function stored on the target system and corresponding to the traditional geometry representation.
Miller teaches the code includes a call to an external function stored on the target system and corresponding to the traditional geometry representation ([0010] … The 3D modeling engine may be received as a compiled plugin including functions to extend the functionality of the browser application and include an interface layer that exposes the 3D modeling engine functions for use by a script … The script may include instructions that refer to the 3D modeling engine functions, and the functions may modify respective portions of model data to change one or more of dimensionality, positioning, and color of a 3D model component. The method may also send the script to a backend database. The script may be executed to extend the 3D modeling engine functions.” [0042] The 3D modeling sub-system 275 includes a browser application 276 in which a 3D modeling engine 278 may operate as a plugin implemented, at least partially, as a set of compiled instructions. The 3D modeling engine 278 may be provided as a dynamic link library (DLL), for example … Moreover, the 3D modeling engine 278 may be provided as a file stored in a predefined location which the browser application 276 always queries upon launch to detect the presence of, and automatically load, files conforming to a certain format. [0043] … More specifically, the 3D modeling engine 278 may interpret model data, which may include descriptions of various 3D and/or 2D shapes that make up the corresponding 3D model … and invoke various functions of the OpenGL API for drawing lines, points, and other basic primitives … [0052] The script interface layer 154 may allow a user to define a script 116 including instructions that, via the script interface layer 154, call functions of the 3D modeling software module 152 … Examiner note: Miller teaches a script containing instructions that call functions of a 3D modeling software module, corresponding to code including call to an external function. Miller further teaches that the 3D modeling engine may be implemented as a DLL stored at the client device and that the engine interprets model data describing 3D or 2D shapes).
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 Min in view of Nam to incorporate the teachings of Miller, and apply Miller’s technique of using code containing instructions that call client side 3D modeling functions to Min’s traditional geometry representation, in order to extend the geometry processing functionality available at the client, thereby allowing the received geometric model to be processed and renders using client side modeling functions.
The elements of claims 8-9 substantially the same as those of claims 1-2. Therefore, the elements of claims 8-9 are rejected due to the same reasons as outlined above for claims 1-2. Further. The additional limitations of claim 8, “A system for computer aided design (CAD) exchange comprising: a source computing system including at least one source computing system processor; a target computing system including at least one target computing system processor; a source computing system memory storing instructions that, when executed by the at least one source computing system processor, cause the source computing system to perform…” and “a target computing system memory storing instructions that, when executed by the at least one target computing system processor…”; (See Miller FIG 1; [0071]).
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 Min in view of Nam to incorporate the teaching of Miller, and apply Miller’s teaching of implementing client and server computer systems using processors configured by software stored on machine readable media to Min’s remote content server and client machine, in order to execute Min’s respective server and client software operations, thereby providing the computing resources for implementing Min’s disclosed server and client functionality.
Claim(s) 3 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Nam
and Miller as applied to claims 1 and 8 above, and further in view of Rappoport US7099803B1.
Claim 3, Min teaches providing to the target system, with the source computing system, (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 … Immediately after the polygonization has completed, the complex geometric model will be presented to the client.”
However, Min in view of Nam and Miller fails to teach, but Rappoport teaches provide a backup texture for the CAD body (Col.5, lines 25-37, “In one embodiment, a bridge data structure 402' is created by the intermediate system 400. The bridge data structure 402' can be a separately created and persistently stored data structure … 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 that fail when the CAD data exchange is taking place, or to recreate a particular instance of the CAD design.” Col.9, lines 22-29, “ … a bridge data structure 402' is created that can temporarily or persistently hold the CAD model for the target CAD system 403 … In still another embodiment, the bridge data structure 402' can be a universal file format that is itself converted by the target CAD system 403 to a native format.” Examiner note: Rappoport teaches a bridge data structure that can temporarily or persistently hold the CAD model for the target CAD system and can be provided as a universal representation that is converted by the target CAD system to its native format. Rappoport further teaches persistently retaining the bridge data structure with rollback and version information to recreate a particular CAD design or recover from unsuccessful exchange operations. Under the broadest reasonable interpretation, the retained CAD model representation corresponds to the backup texture for the CAD body.
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 Min in view of Nam and Miller to incorporate the teachings of Rappoport, and apply Rappoport’s technique of retaining a persistent intermediate representation with rollback and version information, in order to provide a recoverable fallback representation when processing or conversion of Min’s function defined model description is unsuccessful, thereby allowing a prior model state to be restored or recreated and improving the reliability of the model transfer and visualization process.
The elements of claim 10 is substantially the same as those of claim 3. Therefore, the elements of claim 10 is rejected due to the same reasons as outlined above for claim 3.
Claim(s) 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Nam
and Miller as applied to claims 1 and 8 above, and further in view of Shepherd US20210201537A1.
Claim 4, Min in view of Nam teaches The computer-implemented method for CAD exchange of claim 1, wherein obfuscating the proprietary geometry representation (See Min, Page.6, 5. Support for any proprietary function-defined models; See also Nam [0011], [0012] and [0029]) .
However, Min in view of Nam and Miller fails to teach obfuscating is performed using a sparse field structure.
Shepherd teaches obfuscating is performed using a sparse field structure ([0014] … A 3D model (e.g., vector or mesh model) of an object to be 3D printed is voxelized to provide a plurality of voxel layers. Each voxel layer includes a plurality of rows, where each row is a linear array of voxel values … Each remaining row of each voxel layer is XORed with the previous row to provide a delta row for each row, which indicates changes between each row and the previous row. Each delta row of each voxel layer may then be encoded using run length encoding and further compressed and/or encrypted. By determining only the changes between rows within voxel layers, the data to store the voxel space model can be significantly reduced. [0020] Method 100 may also include run length encoding each delta row of each voxel layer. Since each delta row of each voxel layer includes only the changes between adjacent voxel rows, many delta rows will include runs of bits indicating no changes. Therefore, the run length encoded voxel data for the 3D object is substantially compressed compared to the original voxel data for the 3D object. [0029] In one example, processor 402 may execute further instructions to run length encode each delta row of each voxel layer. In another example, processor 402 may execute further instructions to compress (e.g., gzip) or encrypt (e.g., AES256) the run length encoded delta rows of each voxel layer. Processor 402 may also execute further instructions to decompress the compressed voxel data including instructions to XOR the key voxel row with the initial delta row to provide the initial voxel row for each voxel layer. Examiner note: Shepherd teaches representing a 3D voxel field using delta voxel data identifying changes between spatially adjacent voxel rows and layers and run length encoding the delta data such that regions having no changes are compactly represented. Shepherd further teaches encrypting the resulting run length encoded delta voxel representation. Under BRI, the run length encoded delta voxel representation reasonably reads on a sparse field structure because it represents the 3D voxel field using encoded changes while compactly representing regions having no changes).
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 Min in view of Nam and Miller to incorporate the teachings of Shepherd, and apply Shepherd’s technique of representing a virtualized 3D model using delta rows that encode changes between voxel rows, run length encoding the delta rows, and encrypting the encoded voxel data to Min’s proprietary geometry information, in order to reduce the amount of data required to represent and store the protected geometry whole maintaining a reversible representation, thereby providing a compact protected representation from which the original voxel geometry can be recovered.
The elements of claim 11 is substantially the same as those of claim 4. Therefore, the elements of claim 11 is rejected due to the same reasons as outlined above for claim 4.
Claim(s) 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Nam
and Miller as applied to claims 1 and 8 above, and further in view of Ameta US20240135053A1.
Claim 5, Min teaches determination of the at least one implicit function (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.”).
However, Min in view of Nam and Miller fails to teach, but Ameta teaches 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.” [0052] … the processing pipeline 500 may include creating a lattice SDF from the lattice definition 502, which may include generating an SDF representation that represents an internal lattice structure based on the lattice definition 502 inputs.).
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 Min in view of Nam and Miller to incorporate the teachings of Ameta, and apply Ameta’s technique of creating a signed distance function representation for CAD geometry as Min’s implicit function, in order to increase the efficiency at which the geometry is represented, instantiated, and processed, thereby increasing computational speed and reducing memory requirements.
The elements of claim 12 is substantially the same as those of claim 5. Therefore, the elements of claim 12 is rejected due to the same reasons as outlined above for claim 5.
Claim(s) 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Nam
and Miller as applied to claims 1 and 8 above, and further in view of Cowden US20140074272A1.
Claim 6, Min in view of Nam and Miller fail to teach, but Cowden teaches The computer-implemented method for CAD exchange of claim 1, wherein the code accepts varying inputs, and wherein the varying inputs allow for one or more of parametric edits and manufacturing process correction at the target system (FIG. 2; [0009] … receiving a 3D model file representing a physical shape from a first designer's computer system in communications with said server generated by a first designer using a fluent development language … said 3D model having dynamic parameters and static parameters … receiving modification instructions from a second designer's computer system … to modify the 3D model file wherein only said dynamic parameters can be modified … [0033] Designer may optionally specify parameters for each model which can be customized by designers when models are generated. Parameters include but are not limited to: … (vii) whether or not the specific parameter can be modified by a subsequent or second designer. [0034] For example, the first designer may elect to for the bore in the 3D model file of FIG. 1 to remain a certain diameter and make this parameter static so that it can be not be modified by subsequent designers. Alternately, the designer can limit the modification to a range of diameters. Alternatively, the designer can decide that the bore can be completely removed. Therefore, the designer has the ability to make the model parameters dynamic so that they can be modified or static thereby preventing modifications. [0064] (i) a model script, in the case that the remote system wishes to store its own models in a database as opposed to storing them in the invention, … [0066] (iii) parameter names and values, selecting values of the model parameters that should be used when the model is generated … [0070] In one embodiment the scripting language, CADQuery, is used. CADQuery creates computer readable instructions directed to 3D model files and 3D printing … Whereas a typical language, such as FreeCAD, would require designers to write very detailed code to construct a model, CADQuery provides high-level functions to make it very easy. [0103] The 3D model file can be created using computer readable instructions on the server that are accessed by the first designer computer system such as in a SaaS model or locally on the first designer computer system. The 3D model file, with its metadata (e.g. parameters, title, license, etc.) can be transmitted to the server for storage in a single integrated file. A second designer computer system 42 can access the computer readable medium of the server and view the 3D model file, its text or script and its visual representation as displaced on the second designer computer system. The second designer, according to the dynamic parameters, can modify the 3D model file using a modification interface on the second design computer system. Examiner note: Cowden teaches a 3D model represented using computer readable model script or code, wherein parameter names and values are provided for use when the model is generated. Cowden further teaches that the model includes dynamic parameters that can be modified by a second designer through a second designer computer 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 Min in view of Nam and Miller to incorporate the teachings of Cowden, and apply Cowden’s technique of providing model code with parameter names and values used when the model is generated, wherein selected parameter values can be modified by a subsequent user, to Min’s transferred function model, in order to allow a user at the target system to change parameter values of the received function model and generate different configurations of the geometry from the received model, thereby allow the same transferred function model to be reused at the target system for different geometry configurations based on the modified parameter values.
The elements of claim 13 is substantially the same as those of claim 6. Therefore, the elements of claim 13 is rejected due to the same reasons as outlined above for claim 6.
Claim(s) 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Nam
and Miller as applied to claims 1 and 8 above, and further in view of Fryazinov (“Interactive ray shading of FRep objects,” published in 2008).
Claim 7, Min in view of Nam and Miller fails to teach, but Fryazinov teaches The computer-implemented method for CAD exchange of claim 1, wherein a portion of the code is further provided to a graphics processing unit of the source computing system to allow display of the CAD body by the source computing system (Figs.1 and 2; Page.3, Model representation, “In our system we use the functions in the OpenGL shading language (GLSL), which we obtain using the conversion from HyperFun models.” Page.4, Visualization process, “We use GPU for the most of calculations in the ray tracing algorithms adapted to function-based objects. As in the most of GPU-based ray-tracing methods, all the computations take place in the fragment shaders and data transfers from and to a graphics card through the textures. … The conversion from HyperFun to GLSL is a part of pre-procession stage, which also includes the generation of the set of shaders based on an initial model and setting of values to the parameters to the shader, such as bounding box of the scene, time dependent parameters and additional information if required.” Page.5, 4.1.2 Analytical root search, “On the pre-processing stage we generate polynomial functions for each leaf in the CSG-tree and insert this information in the shader.” Page.6, 5. EXPERIMENTAL RESULTS, “It can be seen from the table that with GPU-based rendering we can achieve interactive visualization of functionally based models and scenes.” Examiner note: Fryazinov teaches converting functions of source models into GLSL and, during preprocessing, generating shaders based on an initial model and inserting generated polynomial function information into the shader. As shown in Figure 1 and 2, the CPU prepares the model data and shader parameters, and the GPU renders the model using the generated shaders. Fryazinov further teaches that the GPU fragment shader calculations provide interactive visualization of functionally based models. Thus, Fryazinov teaches that the source computing system provides model representing code to its GPU to render and display the model).
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 Min in view of Nam and Miller to incorporate the teachings of Fryazinov, and apply Fryazinov’s technique of converting model defined functions into GLSL shaders and performing the rendering computations on a GPU at Min’s publisher side system, in order to allow the publisher to interactively visualize the function defined model while creating and preparing the model for transmission to the viewer, thereby improving rendering performance and responsiveness during source side model preparation.
The elements of claim 14 is substantially the same as those of claim 7. Therefore, the elements of claim 14 is rejected due to the same reasons as outlined above for claim 7.
Claim(s) 15, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over
Min (“Function-based 3D Web Visualization,” published in 2002) in view of Miller US20130125029A1 and Maetz US20140119538A1 and Shepherd US20210201537A1 and Kilpatrick US20090122062A1.
Claim 15, Min teaches (Page.1, Abstract; 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.”) comprising:
determining a code representation for a CAD body, the code representation comprising first code expressing one or more implicit equations/functions corresponding to the CAD body, and second code configured to call a first external function (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.2. VRML and its existing extensions, right column, “VRML is the most common format adopted to define 3D objects in the virtual web spaces. We have chosen it to integrate with function-based modeling technique for web visualization … This approach allows visualization of complex CAD models in VRML.” Page. 2.3. Function-defined geometric node, “In this project, a generic function-based node for VRML is proposed as a plug-in to a VRML browser. The idea of introducing such a node is to replace large polygonal representations of complex shapes with small formulae … With the proposed architecture design, a new function-based geometric node, called FShape, has been proposed for VRML … With this node, the content publishers can present any proprietary function-defined model to the viewers since they can develop the respective parsing and polygonization modules.” 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, where the real function f is positive for the points inside the shape …” 4.2. HyperFun, “HyperFun is a high-level modeling language specially designed to describe F-Rep models …HyperFun also contains the system FRep library that can be used to represent geometric primitives and transformations … Functional expressions can also include references to previously defined geometric objects.” Page.6, left column, above FIG.4, “Alternatively, the model definition can be embedded directly into the VRML code via sourceString.” Figure 4. A sample HyperFun definition source illustrates HyperFun model definition contains mathematical /model expression such as: dX = p[1]^2; dY = p[2]^2; dZ = p[3]^2; cube = 0.9-dX*dX-dY*dY-dZ*dZ; and function invocation statement including: cylz =hfCylinderZ(p,center,0.548); cylx = hfCylinderX(p,center,0.316); … spcyl = fSphere(p,center,0.894)|cyl; hole = hfCylinderY(p,center,0.316); … blend = hfBlendInt(cube,inside,0.8,0.2,0.3); Examiner note: Min teaches representing an FRep geometric model using HyperFun code, wherein FRep represents geometric shapes using implicit functions and the HyperFun model definition includes mathematical expressions defining the function-based geometry, corresponding to the claimed first code expressing one or more implicit equation/functions. Min further teaches that HyperFun includes a system FRep library for geometric primitives and transformations, and the same HyperFun model definition contains statement invoking library function (e.g., hfCylinderZ, hfCylinderY … hfBlendInt), corresponding to the claimed second code configured to call a first external function, because these functions are provided by FRep library rather than defined within the shown model definition. Min further teaches integrating the function-based representation into VRML, which is used to define 3D objects and is applicable to complex CAD models, corresponding to a code representation for a CAD body);
wherein the first external function (Page. 2.3. Function-defined geometric node, “In this project, a generic function-based node for VRML is proposed as a plug-in to a VRML browser … With this node, the content publishers can present any proprietary function-defined model to the viewers since they can develop the respective parsing and polygonization modules.” Page.6, 5. Support for any proprietary function-defined models, “Some function-defined models may not have a specific description language like HyperFun. They may be just represented by some mathematical functions, which are used with the supplied data values. In order to support any proprietary function-defined models in FShape node, the publishers have to develop their own respective Parser and Polygonizer components …” See also discussed 4.2. HyperFun and FIG.4. Examiner note: Min teaches that the HyperFun model definition includes statements that call functions provided by the system FRep library, corresponding to the claimed first external function. Min further teaches proprietary function-defined geometric models represented by mathematical functions and supported within the same FShape and VRML architecture);
providing the code representation to a target system (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 … 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.” Pages. 5-6, 4.3. Integration with FShape node, “A sample VRML and HyperFun definitions are given in Figure 3 and 4 for the resulting VRML shape shown in Figure 5 … In this example, the HyperFun definition source is referred via a file reference. Alternatively, the model definition can be embedded directly into the VRML code via sourceString.” Fig.3 shows “sourceURL http://www.model.com/md.hf” sourceType "hyperfun"” and Fig.4 shows “dX = p[1]^2; … cube = 0.9-dX*dX-dY*dY-dZ*dZ; …” Examiner note: Min teaches providing a function-defined model description from a server to a client system. The model description may comprise a HyperFun definition source referenced by the VRML FShape node through sourceURL, or the model definition may be embedded directly in the VRML code through sourceString. As discussed above, the HyperFun model definition corresponds to the claimed code representation comprising the first code and second code. Therefore, Min teaches providing the code representation to a target system, with client corresponding to the target system); and
wherein the code representation is configured to allow for import and display of the CAD body, including (Page. 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 polygonization of the function model is completed at the client machine … Immediately after the polygonization has completed, the complex geometric model will be presented to the client … With this node, the content publishers can present any proprietary function-defined model to the viewers since they can develop the respective parsing and polygonization modules” Page.6, 5. Support for any proprietary function-defined models, “Some function-defined models may not have a specific description language like HyperFun. They may be just represented by some mathematical functions, which are used with the supplied data values. In order to support any proprietary function-defined models in FShape node, the publishers have to develop their own respective Parser and Polygonizer components based on the predefined plug-in interfaces … The respective Parser module is a rather simple procedure in that case. It just reads the function model from the data file created interactively and makes it available for the Polygonizer. The FShape node will dynamically load the corresponding Parser and Polygonizer components based on the string value stored in sourceType field. The VRML source code that links to this proprietary function model is shown in Figure 7 and the examples of using such function-defined shapes in a VRML scene are presented in Figure 8.” Examiner note: Min teaches a function-defined model description that is transmitted to and parsed by a client system, where the corresponding model is polygonised and displayed. Min further teaches that the same FShape architecture supports proprietary function-defined models, wherein the VRML source code links to the proprietary model and the corresponding Parser and Polygonizer allow the proprietary model to be processed and visualized at the client side); and
wherein determining the code representation for the CAD body(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.2. VRML and its existing extensions, right column, “VRML is the most common format adopted to define 3D objects in the virtual web spaces. We have chosen it to integrate with function-based modeling technique for web visualization … This approach allows visualization of complex CAD models in VRML.” 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 …” 4.2. HyperFun, “HyperFun is a high-level modeling language specially designed to describe F-Rep models … The language, while being simple, provides enough functions in creating quite complex geometric models.” 4.3. Integration with FShape node, “A sample VRML and HyperFun definitions are given in Figure 3 and 4 for the resulting VRML shape shown in Figure 5 … In this example, the HyperFun definition source is referred via a file reference. Alternatively, the model definition can be embedded directly into the VRML code via sourceString.”).
However, Min fails to teach 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; displaying the CAD body using the code representation with the source computing system.
Miller teaches 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 ([0024] The 3D modeling software module (or simply “the modeling software”) generally allows the user to create and edit 3D models of buildings, vehicles, items of furniture, and other objects … The modeling software may receive user commands via the browser application for modifying the 3D model, generate a representation of the desired modifications (also referred to below as “mutations” of the model), and, when used in a collaborative environment, cause the modifications to the 3D model to be synchronized with at least one other client device … See also [0027] and [0071]); displaying the CAD body using the code representation with the source computing system ([0048] … The script 116, 292 may include instructions that also manipulate or create objects using the 3D modeling engine 278. For example, the script instructions may cause the modeling engine to interpret model data to determine a combination of geometric primitives and invoke a corresponding OpenGL function to make changes to the displayed model. These scripts 292 may define JavaScript functions that implement various interactive controls and functions of the 3D modeling engine 278 to draw, format, or edit components of a 3D model.).
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 Min’s source computing system to incorporate the teachings of Miller, and apply Miller’s technique of locally display a 3D model at the computing system used to create and edit the model, in order to provide the content publisher with visual feedback regarding the function-defined model before the model is distributed to remote viewers, thereby allowing the publisher to locally inspect and adjust the model prior to network transmission.
However, Min in view of Miller fails to teach obfuscate a geometry of the CAD body via a sparse field structure; including the obfuscated geometry of the CAD body, at the target system.
Maetz teaches obfuscate a geometry of the CAD body ([0039] … a 3D graphical object o (“3D object”) is represented by a first list (or array) of vertices, referred to as the “geometry”, wherein each vertex v=(x, y, z) consists of 3D coordinates ... [0040] A salient inventive idea of the present invention is to protect a 3D object by using a function with at least one parameter to warp the dimension space … [0041] … the present invention obtains a protected point by using a key to select a function that is applied to an input point. [0042] The protection results in the creation of a new set of vertices, yielding a protected 3D object … [0043] … A selection module then determines S12 which protection function Pf* shall be applied to encrypt the coordinates defining the vertices vv=(xv, yv, zv) of the 3D object. … Once the index f* to be used has been identified, the vertices of the object are encrypted using the associated protection function … Examiner note: Maetz teaches protecting or obfuscating the geometry of a 3D object by applying a selected protection function to the coordinates defining the vertices of the 3D object, thereby producing protected geometry); including the obfuscated proprietary geometry of the CAD body, at the target system ([0070] … the points correspond to the vertices of the surfaces composing the graphical object and are expressed in 3D coordinates. The transformation may be performed on the static part (Coordinate node in VRML syntax) or the animation part (CoordinateInterpolator node in VRML syntax), or preferably both. In other words, it is the representation of the 3D object that is protected … [0072] The sender 910 is configured to receive a 3D object via connection 920, encrypt the 3D object … and send the encrypted 3D object to the receiver 940 via connection 930. The receiver 940 is configured to receive an encrypted 3D object via connection 930, decrypt the encrypted 3D object … [0076] … the protected 3D object (and the scene comprising the 3D object) can always be rendered, although it will be more or less recognizable. Examiner note: Maetz teaches protecting the representation of a 3D object, transmitting the protected 3D object from a sender to a receiver, and rendering the 3D object at the receiver. Maetz further teaches that the protected 3D object can always be rendered).
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 Min in view of Miller to incorporate the teachings of Maetz, and configure Min’s called external function to apply Maetz’s protection function to the geometry of the function-defined 3D model, in order to protect proprietary geometry distributed to remote users while preserving the ability of the transferred 3D representation to be interpreted and rendered by the receiving system, thereby improving visualization functionality by using protected proprietary geometry to be securely transferred and visualized at the receiving system.
However, Min in view of Miller and Maetz fails to teach obfuscate via a sparse field structure.
Shepherd teaches obfuscate via a sparse field structure ([0014] … A 3D model (e.g., vector or mesh model) of an object to be 3D printed is voxelized to provide a plurality of voxel layers. Each voxel layer includes a plurality of rows, where each row is a linear array of voxel values … Each remaining row of each voxel layer is XORed with the previous row to provide a delta row for each row, which indicates changes between each row and the previous row. Each delta row of each voxel layer may then be encoded using run length encoding and further compressed and/or encrypted. By determining only the changes between rows within voxel layers, the data to store the voxel space model can be significantly reduced. [0020] Method 100 may also include run length encoding each delta row of each voxel layer. Since each delta row of each voxel layer includes only the changes between adjacent voxel rows, many delta rows will include runs of bits indicating no changes. Therefore, the run length encoded voxel data for the 3D object is substantially compressed compared to the original voxel data for the 3D object. [0029] In one example, processor 402 may execute further instructions to run length encode each delta row of each voxel layer. In another example, processor 402 may execute further instructions to compress (e.g., gzip) or encrypt (e.g., AES256) the run length encoded delta rows of each voxel layer. Processor 402 may also execute further instructions to decompress the compressed voxel data including instructions to XOR the key voxel row with the initial delta row to provide the initial voxel row for each voxel layer. Examiner note: Shepherd teaches representing a 3D voxel field using delta voxel data identifying changes between spatially adjacent voxel rows and layers and run length encoding the delta data such that regions having no changes are compactly represented. Shepherd further teaches encrypting the resulting run length encoded delta voxel representation. Under BRI, the run length encoded delta voxel representation reasonably reads on a sparse field structure because it represents the 3D voxel field using encoded changes while compactly representing regions having no changes).
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 Min in view of Miller and Maetz to incorporate the teachings of Shepherd, and apply Shepherd’s technique of representing the protected 3D geometry using voxel delta representation, run length encoding, and encryption, in order to reduce the amount of data required to represent, store, and transfer the protected geometry while maintaining a reversible representation, thereby provide a compact protected geometry representation that can be recovered for subsequent processing and display at the receiving system.
However, Min in view of Miller and Maetz and Shepherd fails to teach expressing at least a portion of the code representation as an abstract syntax tree.
Kilpatrick teaches expressing at least a portion of the code representation as an abstract syntax tree ( [0023] …As illustrated by FIG. 2A, the preview system 100 can receive an input scene 202 that includes one or more light sources 204 and one or more 3D representations 206. For example, a scene can include 3D geometry describing a car, texture information that specifies the material properties of the car, and a point light source located above the car. In various implementations, the light sources 204 and the 3D representations (e.g., geometries and material properties) 206 are described by one or more light shaders 208 and one or more surface shaders 210, respectively. [0031] FIG. 3 is a block diagram of an example specializing compiler 212. In various implementations, the specializing compiler 212 generates an abstract syntax tree (AST) and determines which expressions in the AST are directly or indirectly related to input that may be manipulated at run-time (e.g., through the parameter controls 118). The specializing compiler 212 can receive an input shader 302. For example, the specializing compiler can receive light shaders 208, surface shaders 210, or both. The specializing compiler 212 can then parse the shader using parser 304. The parser 304 can parse the shader language code and generate an AST. For example, the parser 304 can generate AST 306 from input shader 302. An AST is a directed tree that contains operators at internal nodes and operands at leaf nodes of the tree. [0040] FIG. 5 is an example code fragment 500 that is used to define an RSL shader. In various implementations the code fragment 500 can be used to define an input shader 102. As illustrated by FIG. 5, the code fragment 500 illustrates a surface shader, as defined by parameters 502. For example, Ks specifies a specular reflection property for the surface. As another example, Kd specifies a diffuse reflection property for the surface. When the specializing compiler 212 parses parameters 502, it can generate an AST. For example, the expression “Ks=0.2” can be used to generate a portion of the AST where “Ks” and “0.2” are leaf nodes, and “=” is the root node to the leaf nodes. Examiner note: Kilpatrick teaches a 3D preview system in which 3D representations including geometry are described by shader code. Kilpatrick further teaches parsing the shader language code to generate an AST and a code fragment defining a shader can be used to generate a portion of the AST.).
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 Min in view of Miller and Maetz and Shepherd to incorporate the teachings of Kilpatrick, and apply Kilpatrick’s generating an abstract syntax tree when Min’s parser processes the HyperFun code defining the function-based geometric model, , in order to provide a structured representation of the functional expressions for identifying and processing relationships among the expressions during subsequent code processing and render, thereby facilitate systemic interpretation and processing of Min’s function-defined geometric model by its Parser and polygonizer for web visualization.
Claim 18, Min teaches determine a traditional geometry representation for the CAD body, and wherein (Page.1, right column, “Among these services, the polygon mesh representation is often used to represent geometric models. Thus the most popular 3D web content format Virtual Reality Modeling Language (VRML) [8] uses this representation for complex objects. Although there are many workarounds to improve the overall experience in 3D web visualization, the mainstream of the current web visualization is based on the scenario where the publisher creates a 3D model rather than an image and sends it to the viewer, which then renders and manipulates the model.” Examiner note: Min teaches that a polygon mesh representation is used to represent geometric models and is used by ARML for complex objects. Min further teaches that the publisher creates the 3D model and sends the model to the viewer.).
However, Min fails to teach the code representation includes a call to a second external function corresponding to the traditional geometry representation, wherein the second external function is stored on the target system.
Miller teaches the code representation includes a call to a second external function corresponding to the traditional geometry representation, wherein the second external function is stored on the target system ([0010] … The 3D modeling engine may be received as a compiled plugin including functions to extend the functionality of the browser application and include an interface layer that exposes the 3D modeling engine functions for use by a script … The script may include instructions that refer to the 3D modeling engine functions, and the functions may modify respective portions of model data to change one or more of dimensionality, positioning, and color of a 3D model component. The method may also send the script to a backend database. The script may be executed to extend the 3D modeling engine functions.” [0042] The 3D modeling sub-system 275 includes a browser application 276 in which a 3D modeling engine 278 may operate as a plugin implemented, at least partially, as a set of compiled instructions. The 3D modeling engine 278 may be provided as a dynamic link library (DLL), for example … Moreover, the 3D modeling engine 278 may be provided as a file stored in a predefined location which the browser application 276 always queries upon launch to detect the presence of, and automatically load, files conforming to a certain format. [0043] … More specifically, the 3D modeling engine 278 may interpret model data, which may include descriptions of various 3D and/or 2D shapes that make up the corresponding 3D model … and invoke various functions of the OpenGL API for drawing lines, points, and other basic primitives … [0052] The script interface layer 154 may allow a user to define a script 116 including instructions that, via the script interface layer 154, call functions of the 3D modeling software module 152 … Examiner note: Miller teaches a script containing instructions that call functions of a 3D modeling software module, corresponding to code including call to an external function. Miller further teaches that the 3D modeling engine may be implemented as a DLL stored at the client device and that the engine interprets model data describing 3D or 2D shapes).
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 Min to incorporate the teachings of Miller, and apply Miller’s technique of using code containing instructions that call client side 3D modeling functions to Min’s traditional geometry representation, in order to extend the geometry processing functionality available at the client, thereby allowing the received geometric model to be processed and renders using client side modeling functions.
Claim 19, Min fails to teach, but Miller teaches provide to the target system a kernel of a CAD program of the source computing system, the kernel including the first external function ([0010] … the method may receive a 3D modeling engine from a backend server at a browser application. The 3D modeling engine may be received as a compiled plugin including functions to extend the functionality of the browser application and include an interface layer that exposes the 3D modeling engine functions for use by a script. [0034] The modeling client 210 may be provided as a plugin that extends the functionality of the browser 206. … the modeling client 210 may include compiled code with functions that may be invoked by the browser 206. The modeling client 210 can be installed in the computing environment 200 only after a user of the corresponding computing device agrees to the terms of use of the modeling client 210. The modeling client 210 may correspond to the 3D modeling software module 152, and may be provided by the modeling server 106 to the client device 102 in response to a request from the client device 102. Examiner note: Miller teaches a modeling server providing a modeling client or modeling engine to a client device, wherein the provided modeling component is implemented as a compiled plugin containing callable modeling functions. Under BRI, the provided modeling client or modeling engine corresponds to a kernel of a CAD program containing executable external functionality).
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 Min to incorporate the teachings of Miller, and apply Miller’s technique of providing, from a modeling server to a client device, a compiled modeling component containing callable modeling functions, to Min’s function-based modeling system, in order to make the executable modeling functionality required for processing the function-defined model available at the client, thereby allowing the client to receive and use the required modeling functionality when processing the transferred model representation.
Claim(s) 16 is rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Miller and
Maetz and Shepherd and Kilpatrick as applied to claim 15 above, and further in view of Fallon US9298871B1.
Claim 16, Min in view of Miller and Maetz and Shepherd and Kilpatrick fails to teach, but Fallon teaches convert the code representation from a first computer language to a second computer language (Col.2, lines 1-3, “the pcell source code created in a first programming language undergoes a translation process to translate that source code to a second programming language.” Col.5, lines 16-20, “this translation functionality is performed by analyzing the details of the source code in the first programming language, and then mapping the first language constructs to constructs in the second programming language.” Col.6, lines 27-31, “In addition, the translations must be properly performed at the semantic level. This means that the behavior of the original pcell must be understood, and the translated version of the pcell must behaviorally operate to provide necessarily the processing results as the original language pcell.”).
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 Min in view of Miller and Maetz and Shepherd and Kilpatrick to incorporate the teachings of Fallon, and translate Min’s function model code from a first programming language into second programming language, in order to permit the model code to be used by a receiving design or visualization system that does not natively support the original language, thereby allow existing function model code to remain usable across systems that support different computer languages.
Claim(s) 17 is rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Miller and
Maetz and Shepherd and Kilpatrick as applied to claim 15 above, and further in view of Rappoport US7099803B1.
Claim 17, Min teaches provide (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 … Immediately after the polygonization has completed, the complex geometric model will be presented to the client.”). However, Min in view of Miller and Maetz and Shepherd and Kilpatrick fails to teach, but Rappoport teaches provide a backup texture for the CAD body (Col.5, lines 25-37, “In one embodiment, a bridge data structure 402' is created by the intermediate system 400. The bridge data structure 402' can be a separately created and persistently stored data structure … 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 that fail when the CAD data exchange is taking place, or to recreate a particular instance of the CAD design.” Col.9, lines 22-29, “ … a bridge data structure 402' is created that can temporarily or persistently hold the CAD model for the target CAD system 403 … In still another embodiment, the bridge data structure 402' can be a universal file format that is itself converted by the target CAD system 403 to a native format.” Examiner note: Rappoport teaches a bridge data structure that can temporarily or persistently hold the CAD model for the target CAD system and can be provided as a universal representation that is converted by the target CAD system to its native format. Rappoport further teaches persistently retaining the bridge data structure with rollback and version information to recreate a particular CAD design or recover from unsuccessful exchange operations. Under the broadest reasonable interpretation, the retained CAD model representation corresponds to the backup texture for the CAD body.
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 Min in view of Miller and Maetz and Shepherd and Kilpatrick to incorporate the teachings of Rappoport, and apply Rappoport’s technique of retaining a persistent intermediate representation with rollback and version information, in order to provide a recoverable fallback representation when processing or conversion of Min’s function defined model description is unsuccessful, thereby allowing a prior model state to be restored or recreated and improving the reliability of the model transfer and visualization process.
Claim(s) 20 is rejected under 35 U.S.C. 103 as being unpatentable over Min in view of Miller and
Maetz and Shepherd and Kilpatrick as applied to claim 15 above, and further in view of Cowden US20140074272A1.
Claim 20, Min in view of Miller and Maetz and Shepherd and Kilpatrick fails to teach, but Cowden teaches the code representation further comprises at least one input parameter, and the code representation is configured to allow the at least one input parameter to be edited at the source computing system or at the target system (FIG. 2; [0009] … receiving a 3D model file representing a physical shape from a first designer's computer system in communications with said server generated by a first designer using a fluent development language … said 3D model having dynamic parameters and static parameters … receiving modification instructions from a second designer's computer system … to modify the 3D model file wherein only said dynamic parameters can be modified … [0033] Designer may optionally specify parameters for each model which can be customized by designers when models are generated. Parameters include but are not limited to: … (vii) whether or not the specific parameter can be modified by a subsequent or second designer. [0034] For example, the first designer may elect to for the bore in the 3D model file of FIG. 1 to remain a certain diameter and make this parameter static so that it can be not be modified by subsequent designers. Alternately, the designer can limit the modification to a range of diameters. Alternatively, the designer can decide that the bore can be completely removed. Therefore, the designer has the ability to make the model parameters dynamic so that they can be modified or static thereby preventing modifications. [0064] (i) a model script, in the case that the remote system wishes to store its own models in a database as opposed to storing them in the invention, … [0066] (iii) parameter names and values, selecting values of the model parameters that should be used when the model is generated … [0070] In one embodiment the scripting language, CADQuery, is used. CADQuery creates computer readable instructions directed to 3D model files and 3D printing … Whereas a typical language, such as FreeCAD, would require designers to write very detailed code to construct a model, CADQuery provides high-level functions to make it very easy. [0103] The 3D model file can be created using computer readable instructions on the server that are accessed by the first designer computer system such as in a SaaS model or locally on the first designer computer system. The 3D model file, with its metadata (e.g. parameters, title, license, etc.) can be transmitted to the server for storage in a single integrated file. A second designer computer system 42 can access the computer readable medium of the server and view the 3D model file, its text or script and its visual representation as displaced on the second designer computer system. The second designer, according to the dynamic parameters, can modify the 3D model file using a modification interface on the second design computer system. Examiner note: Cowden teaches a 3D model represented using computer readable model script/code together with model parameters. Cowden further teaches providing parameter names and values that select the model parameters used when the model is generated, and storing the model file and its parameters in a single integrated representation. Cowden also teaches configuring each parameter as dynamic or static, wherein a dynamic parameter may be modified by a subsequent designer while a static parameter is prevented from modification).
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 Min in view of Miller and Maetz and Shepherd and Kilpatrick to incorporate the teachings of Cowden, and apply configuration of model parameter as dynamic so that the parameters can be modified by a subsequent designer, in order to allow a receiving user to reconfigure Min’s transferred function model by changing selected parameter values without creating separate model definitions for different configuration, thereby providing reuse and parametric editability of the transferred model.
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 at (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
Prosecution Insights