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 .
Terminal Disclaimer
The terminal disclaimer filed on 10/27/2025 disclaiming the terminal portion of any patent granted
on this application which would extend beyond the expiration date of co-pending application 17/689,813 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Amendment
The amendment filed 10/27/2025 has been entered. As directed, no claim have been amended,
canceled or added. 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:
…
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.
Importantly, this conclusion is not undermined by the extent to which the benefits are achieved via software rather than hardware. This point was emphasized by the Appeals Review Panel of the PTAB in a September 26, 2025, decision reversing a § 101 rejection introduced as a new ground of rejection by PTAB in a patent application appeal ("ARP decision").1 The ARP addressed software-based patentable improvements as follows:
Enfish ranks among the Federal Circuit's leading cases on the eligibility of technological improvements. In particular, Enfish recognized that "[m]uch of the advancement made in computer technology consists of improvements to software that, by their very nature, may not be defined by particular physical features but rather by logical structures and processes." 822 F.3d at 1339. Moreover, because "[s]oftware can make non-abstract improvements to computer technology, just as hardware improvements can," the Federal Circuit held that the eligibility determination should turn on whether "the claims are directed to an improvement to computer functionality versus being directed to an
abstract idea." Id. at 1336 (emphasis added).
Here, as in Enfish, the claims are directed to an improvement to computer functionality rather than to an abstract idea, and the eligibility determination turns on this fact. Accordingly, 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 10/27/2025 [pages 8-11]).
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.” In this case, the claims recite limitation such as determining at least one implicit function, obfuscating a geometry representation in an external function, and expressing the functions as code. Under their broadest reasonable interpretation in light of specification can be considered as mental process and mathematical concepts (mathematical relationships and equation). The additional limitations mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP § 2106.05(f)), and merely adding insignificant extra-solution activity (i.e., display CAD body) to the judicial exception (MPEP § 2106.05(g)). Therefore, eligibility is not self-evident and the streamlined path is not applicable.
The Enfish decision does not apply to the instant claims. In Enfish, the claimed invention improved the computer’s internal data operation through a specific self-referential table structure. However, the instant claims merely use conventional computing components to perform abstract representation steps for CAD geometry. The alleged improvements described in the specification related to the abstract idea itself and are not reflected in any additional limitation (e.g., providing …; displaying …) that could meaningfully limit the judicial exception. Therefore, the additional limitation does not show a specific improvement to computer functionality or to another technology or technical field.
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 elements amounting to significantly more than the exception.
With respect to the Applicant’s argued rejection under 35 U.S.C. § 101 in “Applicant Arguments/Remarks Made in an Amendment,”:
Applicant argues:
…
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." MPEP 2106.04(a)(2)(III)(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]laims can recite a mental process even if they are claimed as being performed on a computer," MPEP 2106.04(a)(2)(III)(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 10/27/2025 [pages 13-15]).
The examiner respectfully disagrees with applicant's argument that the claims merely “involve” mathematical concepts rather than “recite” 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, pressure (p) can be described as the ratio between the magnitude of the normal force (F) and area of the surface on contact (A), or it can be set forth in the form of an equation such as p = F/A. Examples of mathematical relationships recited in a claim include:
i. a relationship between reaction rate and temperature, which relationship can be expressed in the form of a formula called the Arrhenius equation, Diamond v. Diehr; 450 U.S. at 178 n. 2, 179 n.5, 191-92, 209 USPQ at 4-5 (1981).
The instant claims recites such mathematical subject matter.
Claim 1 explicitly requires:
“determining … at least one implicit function … for a CAD body,” and
“expressing … the implicit function … as code.”
The specification defines the “implicit function” as one or more equations describing geometric relationship of the CAD body ([0031], [0035], Fig.4). Under a broadest reasonable interpretation in light of the specification, determining and expressing the “implicit function” requires forming and representing equations defining spatial geometry. These are mathematical relationships and equations as described in the 2019 PEG.
The Diehr example illustrates the type of mathematical relationship that counts have identified as a mathematical concept (e.g., a relationship between reaction rate and temperature expressible as a formular). Likewise, the instant claim recites equations describing relationships between CAD-body geometry and the correspond code.
Therefore, the limitation is directed to a mathematical concept, similar to the comparison steps in 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 specification, claim 1 recites observing and evaluating a CAD model feature to determining at least one implicit function and a proprietary geometry representation, transforming that representation through obfuscation, and expressing the results as code. The claim does not specify the complexity of the implicit function, any particular technique for obfuscation, or any defined coding format. When the claim recites these high-level conceptual operations on geometric information without limiting how they must be performed, the steps reasonably amount to evaluating information and rewriting the information into a different form, which can be performed mentally or by using pencil and paper. This is consistent with the analysis in CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366 (Fed. Cir. 2011), which explains that a method step constitutes a mental process when it can be performed in human mind or with pen and paper, even if the claim nominally recites a computer. Therefore, the limitations reasonably fall within the “mental processes” grouping of abstract ideas (MPEP 2106.04(a)(2)(III).
The SRI Int’l, Inc. v. Cisco Systems, Inc., 930 F.3d 1295, 1304 (Fed. Cir. 2019) case recited by applicant is not persuasive. In SRI, the claims required specific computer network monitoring operations that continuously analyzed data packets to detect suspicious actively. These steps necessarily involved active machine-based processing that cannot be performed mentally. In contrast, the instant claims do not recite real-time monitoring or continuous computer operation. They merely describe evaluating geometric relationships and expressing them as code without requiring any particular computer technique. There steps can be performed mentally when the claim does not restrict how they must be implemented.
Applicant also cites the Appeals Review Panel (ARP) decision. However, the ARP decision is not applicable. The ARP decision involved claims that improved computer performance through specific algorithmic training and adaptive computation. By contrast, the instant claims involve evaluating and rewriting geometric information without improving how the computer operates or processes data.
Therefore, the limitation is 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:
…
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)(1), "[o]ne way to demonstrate such integration [into a practical application] is when the claimed invention improves the functioning of a computer or improves another technology or technical field. .. . Such claims are eligible at Step 2A because they are not "directed to" the recited judicial exception." To evaluate this consideration, the MPEP instructs that "first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. 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."Id. "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')."Id. Furthermore, "[w]hen performing this evaluation, examiners should be 'careful to avoid oversimplifying the claims' by looking at them generally and failing to account for the specific requirements of the claims." MPEP at 2106.05(a), citing McRO, Inc. v. Bandai Namco Games Am. Inc., 837 F.3d 1299, 1313 (Fed. Cir. 2016).
Following the MPEP's instruction, an evaluation of the specification shows that the disclosure does provide sufficient details for a person of ordinary skill in the art to recognize that the claimed subject matter provides an improvement to computer technology. As explained above with reference to the streamlined analysis, the claimed method of CAD exchange provides several improvements over known methods, such as enabling the exchange to be accomplished with a smaller data transfer, increasing precision by avoiding the need for making approximations, enabling 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[ing] 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]. The specification explicitly sets forth these improvements, and the first step of the MPEP's analysis is therefore satisfied.
Next, an evaluation of the claims shows that the claims do reflect one or more of the improvements disclosed in the specification. Continuing to take claim 1 as an example, claim 1 recites determining at least one implicit function and a proprietary geometry representation for a CAD body; obfuscating the proprietary geometry representation in a corresponding external function; expressing the implicit function and the external function as code; and providing the code to a target system. As clearly explained in the specification, and as would be readily apparent to a person of ordinary skill in the art, these features give rise to most or all of the improvements provided by the claimed method of CAD exchange. For example, exchanging code rather than meshes, voxels, or boundary representations provides the advantages of accomplishing CAD exchange with a smaller amount of data than is conventional. Paragraph [0009]. Paragraphs [0055]-[0056] further explain that accomplishing the CAD exchange by exchanging code that expresses the implicit function gives rise to the advantages of precision and allowing for parametric editing at the target system, which are improvements over known methods. Additionally, a person of ordinary skill in the art would readily appreciate that obfuscating the proprietary geometry representation in an external function would keep the proprietary geometry representation protected even after the code is provided to the target system by the source system. This is an improvement over known systems in which providing the CAD body to the target system necessarily reveals all proprietary information about the CAD body's geometry representation, which is a troubling issue in the field of CAD exchange in many common use cases, such as manufacturing an item by providing the corresponding CAD body (made by a first company) to a 3-D printer or manufacturing machine (controlled by a second company). See paragraph [0004].
Although certain features mentioned above (determining at least one implicit function and a proprietary geometry representation for a CAD body; obfuscating the proprietary geometry representation in a corresponding external function; expressing the implicit function and the external function as code) include those identified by the Office action as an abstract idea, this identification is immaterial for this part of the MPEP's analysis, because "the improvement [to the computer and/or technology] 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.
The Office action asserts that certain "additional elements" mentioned above (namely, 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) are merely insignificant extra-solution activity that cannot integrate any abstract idea into a practical application. Applicant respectfully disagrees. Insignificant extra-solution activities are claim elements that are only "nominally or tangentially related to the invention," or that are required by "all uses of the recited judicial exception." MPEP at 2106.05(g). There is no apparent reason to believe that any of the features identified in the Office action are only tangentially related to the claimed method of CAD exchange, or would be required any time someone determined an implicit function.
Indeed, the Office action does not actually provide any reasoning to the contrary, although the MPEP instructs that such reasoning should accompany a § 101 rejection involving alleged extra-solution activity. Id. To illustrate this instruction, the MPEP explains that "[f]or example, an examiner could explain that adding a final step of storing data to a process that only recites computing the area of a space (a mathematical relationship) does not add a meaningful limitation to the process of computing the area." Id., emphasis added. Here, no such explanation is provided, and Applicant believes no such explanation could plausibly be articulated, because the features in question are not insignificant and are not extra-solution. Thus, these features must be considered at the Step 2A, Prong 2 analysis, and they should be found to integrate any purported abstract idea into the practical application of exchanging a CAD body between a source system and a target system, thus enabling display of the CAD body at the target system.
Accordingly, though Applicant believes that claim 1 (and for similar reasons, all independent claims) does not recite any abstract idea, the Prong 2 analysis still shows that the claim is not "directed to" any such abstract idea, because the claim as a whole integrates any such idea into a practical application. This is true at least because the specification describes the relevant subject matter such that a person of ordinary skill in the art would recognize that the subject matter provides improvement(s) to a computer and/or technology, and the claims include the components or steps of the invention(s) that provide the improvement(s). The full eligibility analysis must therefore end at Step 2A, Prong 2 with the conclusion that the claims are eligible for patenting, and that no §101 rejection is proper. Applicant respectfully requests that the rejections under §101 be withdrawn.
(see Response filed 10/27/2025 [pages 16-19]).
The examiner respectfully disagrees with applicant argues 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.
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).” However, the alleged improvements identified by applicant arise from the abstract representation steps of “determining, obfuscating, and expressing, which are part of the abstract idea itself. Improvements within the abstract idea cannot supply integration under Step 2A prong 2. Thus, the relevant additional limitations are the generic computer components, providing…the code to a target system and displaying… based on the code. These limitations merely represent data transmission and data output that occur after the abstract processing is complete. The limitations are performed by conventional computers and are identified in MPEP § 2106.05 (f) and (g) with explains and examples of Mere Instructions To Apply An Exception and Insignificant Extra-Solution Activity that do not meaningfully limit a judicial exception.
Furthermore, the examiner respectfully disagrees with applicant argues 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. These steps merely send the result of the abstract processing and present it for viewing. The claim does not specify any technical detail about how the data is transmitted, stored, or displayed that would meaningfully limit the abstract operations. In MPEP § 2106.05(g), As explained by the Supreme Court, the addition of insignificant extra-solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. Parker v. Flook, 437 U.S. 584, 588-89, 198 USPQ 193, 196 (1978). In Flook, the Court reasoned that "[t]he notion that post-solution activity, no matter how conventional or obvious in itself, can transform an unpatentable principle into a patentable process exalts form over substance. A competent draftsman could attach some form of post-solution activity to almost any mathematical formula.
Furthermore, the examiner respectfully disagrees with applicant argues that the Office failed to explain why the steps of providing and displaying are insignificant extra-solution activities. The prior Office Action already provided the required explanation consistent with MPEP § 2106.05(g). Specifically, the action identified the providing step (transmitting code from one system to another) as data gathering, and the displaying step (showing the CAD body based on the code) as data output. Both actions merely transmit or display the results of the abstract processing and do not integrate the judicial exception into a practical application. Therefore the Office has satisfied the explanatory requirement by identifying the nature of these activities and indicating that they do not meaningful limit the claim. Therefore, the claims do not integrate the recited abstract idea into a practical application under Step 2A Prong 2.
Although Applicant did not present arguments regarding Step 2B, the prior Office action already addressed this step to complete the patent subject matter eligibility analysis under 35 U.S.C. § 101 . As previously Office action explained, the claims do not include any additional elements, alone or in combination that are sufficient to amount to significantly more than the judicial exception. The identified additional limitation (e.g., transmitting code between systems and displaying the CAD body) are generic computer functions that merely perform generic computer functions of executing, transmitting, and displaying information. These operations represent well-understood, routine, and conventional (WURC) computer functions, as explained in MPEP 2106.05(d)(II) and confirmed by the courts in Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) and Interval Licensing LLC v. AOL, Inc., 896 F.3d 1335, 1344-45, 127 USPQ2d 1553, 1559-60 (Fed. Cir. 2018).
Therefore, the claims, when is considered as a whole, do not recite additional limitation elements that amount to significantly more than the judicial exception, claims 1, 8, and 15 do not recite patent-eligible subject matter under 35 U.S.C. § 101.
For the reasons discussed above, applicant’s arguments have been considered but are not persuasive. The claims are directed to abstract ideas (mathematical concepts and mental processes), are not integrated judicial exception into a practical application, and do not recite additional elements amount to significantly more than the judicial exception. The rejection under 35 U.S.C. § 101 is maintained.
Applicant's arguments filed under “Applicant Arguments/Remarks Made in an Amendment” on
08/29/2025, the applicant' s arguments with respect to rejection under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant argues:
… In the present case, the cited references, whether taken alone or in combination, fail to teach or suggest all of the limitations of the claims.
Claim 1 recites the following:
…
These features are not taught or suggested by the cited references, whether taken individually or in combination. As the Office action notes, the primary cited reference, Gielis, describes representing CAD bodies using so-called "SUPERSHAPES," which can be coded for transfer to another system using XML or Scalable Vector Graphics. However, Gielis does not teach or suggest obfuscating a proprietary geometry representation in an external function. The Office action acknowledges this deficiency of Gielis, but asserts that Gupta and Makkinejad remedy it. Applicant respectfully disagrees for the following reasons.
Gupta describes a method of deliberately introducing defects into a CAD model so that unauthorized users cannot 3D print a high quality product using the model. See, e.g., Gupta, paragraph [0054]. The Office action characterizes this as "obfuscating a geometry representation," but acknowledges that Gupta fails to actually teach obfuscating a geometry representation in a corresponding external function. Instead, the Office action asserts that this obfuscating a geometry representation in an external function would have been obvious in view of Makkinejad. Applicant respectfully submits that this conclusion is unreasonable. Makkinejad describes methods of introducing "alternative information" or "false error information" into the text of computer error messages to prevent malicious actors from gleaning information about the computer system through the error messages. See, e.g., Makkinejad, paragraphs [0006]-[0008].
The obviousness rejection is premised on the proposition that a person of ordinary skill in the art would have arrived at the idea of obfuscating a proprietary geometry representation in an external function based on Gielis's method of deliberately introducing a defect into a CAD model and Makkinejad's method of deliberately introducing false information into error messages. Applicant submits that this proposition is unreasonable. Even taken together, Gielis and Makkinejad do not even approach the concept of obfuscating a proprietary geometry representation in an external function. Defects in CAD models and false information in error messages do not amount to obfuscation of geometry representations, much less obfuscation in an external function.
The Office action states that "Makkinejad teaches obfuscating the geometry representation in a corresponding external function and expressing the external function as code" purely because Makkinejad mentions at paragraph [0035] that its method is implemented by an API that provides "classes and methods" usable by different programming languages. This is an unreasonably broad interpretation of Makkinejad, or of the claim language "obfuscating . .. the proprietary geometry representation in a corresponding external function," or both. Makkinejad does not teach or suggest obfuscating anything in an external function - it simply describes computer mechanisms such as APIs for replacing accurate text with inaccurate text. It is unreasonable to suggest that Makkinejad's API for replacing accurate error message text with inaccurate error message text would have prompted a person of ordinary skill in the art to attempt to modify Gupta to obfuscate a geometry representation in an external function. The obviousness rejection should be withdrawn for at least this reason.
Additionally, the claim further recites expressing the implicit function and the external function as code and providing the code to a target system. Under the Office action's interpretation that the external function is Makkinejad's API, there would be no reason to provide code expressing the API to a target system. Accordingly, even if the Office action's interpretation of "obfuscating . . . in a corresponding external function" as encompassing Makkinejad's API could be considered reasonable in a vacuum, which Applicant does not concede, it cannot be considered reasonable in the context of the claim as a whole. Nothing in Makkinejad, Gupta, or any other reference would suggest any reason to provide code expressing Makkinejad's API to a target system. Applicant respectfully submits that this problem indicates either that the rejection fails to account for every limitation of the claim, or that the interpretation of the claim language is not consistent with the claim as a whole, or both. The obviousness rejection should be withdrawn for at least this additional reason.
Accordingly, for the reasons set forth above, the cited references fail to render obvious the claimed feature of obfuscating a proprietary geometry representation in an external function. Each independent claim, and therefore each dependent claim as well, is patentable over the cited art for at least this reason.
Furthermore, all claims are patentable over the cited art for the additional reason that the cited art fails to teach or suggest displaying the CAD body at the target system based on the code. The Office action asserts that Massaro supplies this feature, and Applicant respectfully disagrees for the following reasons.
Massaro describes methods for designing a HVAC system (or more generally, "any system that has components designed to particular specifications"). Massaro, paragraph [0042]. In Massaro's method, the system is designed using a first CAD software application. Id. The first application exports geometrical information (e.g., inlet and outlet coordinates, pipe fitting orientations) and property values (e.g., airflow direction, pressure class, material type) to a text file, or other suitable data file. Paragraphs [0043]-[0045]. Then the information stored in the text file is imported into a second CAD application. Paragraph [0047]. The second application uses the stored information to identify standard HVAC components (e.g., duct lengths, connectors, gauges, etc.) that "map to" the geometric and property information specified in the data file for the designed HVAC system. Paragraph [0049]. Finally, based on the identified standard HVAC components, the second system generates a three-dimensional representation of the "intended system" that resembles the system designed on the first software application, but is "constructed of standard fittings" identified as suitable substitutes by the second software application. [0051]. Alternatively, the second system may construct a blueprint or parts list instead of the three-dimensional representation. Paragraphs [0053]-[0055].
Accordingly, Massaro fails to teach or suggest displaying a CAD body at a second system based on code provided by a first system, much less based on code related to implicit function(s). Instead, Massaro displays a three-dimensional representation assembled from standard HVAC fittings that is intended as a standardized version of an HVAC system designed in a different CAD application. Massaro therefore would not have suggested to a person of ordinary skill in the art that it might be possible or beneficial to modify Gielis or any other reference to display a CAD body at a target system based on code provided by a source system. The concept of displaying a CAD body is absent from Massaro.
Furthermore, the entire point of Massaro's invention is to identify and present a set of suitable standard fittings instead of the original CAD body. Displaying the CAD body at the target system would defeat the purpose of Massaro's invention and effectively change its principle of operation. However, "[i]f a proposed modification would render the prior art invention being modified unsatisfactory for its intended purpose, there may be no suggestion or motivation to make the proposed modification." MPEP at 2143.01(V), citing In re Gordon, 733 F.2d 900 (Fed. Cir. 1984). And "[i]f the proposed modification or combination of the prior art would change the principle of operation of the prior art invention being modified, then the teachings of the references are not sufficient to render the claims prima facie obvious." MPEP at 2143.01(VI), citing In re Ratti, 270 F.2d 810, 813 (CCPA 1959). For at least these additional reasons, Massaro cannot remedy the deficiencies of Gielis or any other reference, and each independent claim is patentable over the cited art for at least this additional reason, as are all claims depending therefrom.
Accordingly, each independent claim recites several features that are not taught or suggested by the art of record. The independent claims, and therefore the dependent claims as well, are therefore patentable over the art of record. Applicant respectfully requests withdrawal of the present rejections under 35 U.S.C. § 103.
(see Response filed 10/27/2025 [pages 19-24]).
The examiner respectfully disagrees the applicant's argument that Gielis in view of Gupta and Makkinejad fail to teach the limitation of claim 1, “obfuscating, with the source computing system, the proprietary geometry representation in a corresponding external function.”
Under the broadest reasonable interpretation (BRI), “obfuscating” can be interpreted as making the geometry representation of misleading, degraded, or difficult to use or interpret, and “external function” reasonably includes any callable software function or API used by an application to perform obfuscation operations. The claim does not require a particular obfuscation technique (e.g., encryption) and external function be limited to geometry-specific functions.
In the prior Office action, Gupta is cited for teach obfuscating a geometry representation. Gupta teaches embedding security elements into a CAD model so that an unauthorized user cannot obtain a high-quality printed part from the model ([0054]). The model’s geometric representation is intentionally modified causing normal use (accurate/high-quality 3D printing) fails. The reference explicitly teaches obfuscating the geometry representation under BRI, because the resulting representation is purposely rendered misleading and unsuitable for unauthorized use.
The applicant argues that Makkinejad does not teach obfuscation “in an external function” of a geometry representation, because it discusses replacing error-message text. However, the Office action does not rely on Makkinejad to teach geometry-specific content; rather, Makkinejad is cited for teaching that obfuscation functionality is implemented via an API that provides classes and methods usable by different programming languages and operating environments ([0035]). An API that exposes obfuscation operations as callable classes and methods is reasonably an “external function” under BRI. When Gupta’s geometry-obfuscation technique is implemented using the external obfuscation API structure taught by Makkinejad, the geometry representation of Gupta is obfuscated in a corresponding external function, as claimed. The claim limitation does not limit the external function to a particular type of data or to graphical operations. Under BRI, Makkinejad’s obfuscation API can be interpreted as an external function performing obfuscation.
Applicant also argues that combining Gupta and Makkinejad is “unreasonable” and that the references “do not even approach the concept” of the claimed feature. However, both references address protecting proprietary or sensitive information from unauthorized access or misuse, such as Gupta by altering CAD models to prevent accurate reproduction, and Makkinejad by introducing false information via an obfuscation API to prevent inspection of internal system details. As explained in the Office Action, incorporating Makkinejad’s external function obfuscation mechanism into Gupta’s CAD obfuscation method represent a reasonable combination of known compatible features, since both references address data obfuscation for information protection. The combination remains consistent with the claim limitation and does not alter the function or operation of the cited systems.
Furthermore, the examiner respectfully disagrees the applicant's argument that the rejection fails to account for every limitation of the claim, or that the interpretation of the claim language is not consistent with the claim as a whole, or both for the limitation of claim 1, “expressing, with the source computing system, the at least one implicit function and the external function as code; providing, with the source computing system, the code to a target system.”
First, Applicant mischaracterizes the mapping in the Office action. As explained at prior Office action pages 23-24, the limitations “expressing … the at least one implicit function and the external function as code” and “providing … the code to a target system” are met by the combination of Gielis with Gupta and Makkinejad, not by Makkinejad alone. Under the broadest reasonable interpretation (BRI), “code” is any machine-readable representation of instructions or functions, and “target system” is any second application or device that receives and uses the code.
In the prior office action, Gielis is cited for teaching expressing CAD shapes as implicit functions and representing those functions as code in standardized formats (e.g., XML or SVG) and GENICAP SUPERSHAPES file formats. Gielis further teaches saving this code to an external file and using the file as a common transport format between applications, so that other products can import the information and “use the common methods for importing and exporting” via a shared class library. Thus, Gielis already discloses both (i) expressing the implicit function as code, and (ii) providing that code from a source system to a different target system.
Gupta, as discussed above, teaches modifying (obfuscating) the geometry representation of a CAD model by embedding security elements, so that an unauthorized user cannot accurately manufacture the corresponding part. When this geometry obfuscation is implemented via the external obfuscation API of Makkinejad to provide “a set of classes and methods” accessible from different programming languages and operating environments resulting code that is saved and transported in the manner of Gielis reasonably “expresses” both (a) the implicit function for the CAD body and (b) the external obfuscation function (e.g., via calls to or data for that API). When that combined code is then exported and used as a common transport format between applications as taught by Gielis, the limitation “providing … the code to a target system” is met under BRI.
Second, even considering Makkinejad alone, the applicant’s assertion that there is “no reason” to provide code expressing the API to another system is inconsistent with Makkinejad’s disclosure. Makkinejad expressly states that the obfuscation API is designed to be used in “various programming languages and operating environments” and provides bindings for languages such as C, C++, Java, .NET, Python, and Perl ([0035]) inherently making the API code available to other applications including the functions. Therefore, the reference reasonably teaches or suggests providing code representing an external function to another system, as recited in claim 1. This interpretation remains consistent with the broadest reasonable reading of the claim limitation and the Office Action’s original reasoning.
Furthermore, the examiner respectfully disagrees the applicant's argument that Massaro fails to teach or suggest display a Cad body at a second system based on code provided by a first system, much less based on code related to implicit function(s).
In the prior Office Action, Gielis is cited for teaching expressing an implicit function representing a CAD body as code, for example in XML, SVG, or other structured file formats (see Gielis, [0147] and [0215]). Gielis further indicates that such code can be stored in a file and accessed or shared ([0202] and [0216]), thereby inherently supporting use of the same file on a different computing system to visualize or manipulate the represented geometry.
The Office Action cited Massaro solely to confirm that, once geometric or design information is stored in a file, it was known in the art that such a file could be transferred to another CAD system and used to generate a corresponding visual model. Massaro describes exporting design information from one CAD application and importing that information into another CAD environment, where the second system generates and displays a representation of the design. While Massaro does not state that the file contains “code,” it explicitly shows that a file containing geometric data can be imported and displayed at a second system, which consistent with the concept of displaying a CAD body at a target system based on data (or code) representing the geometry.
Under the broadest reasonable interpretation, the claim phrase “displaying the CAD body at the target system based on the code” does not require the code itself to be directly transmitted by the target system or explicitly identified as a “code file.” The claim simply requires that the display at the target system be generated using information that corresponds to code representing the CAD body. Gielis provides the representation as code; Massaro teaches that such data may be transferred and used to display a geometry at another system. The combination therefore reasonably teaches the recited limitation.
Furthermore, applicant’s argument about principle of operation and unsatisfactory modification are not persuasive. The rejection does not change how Massaro works or the purpose of Massaro’s system. The combination only relies on Massaro’s separate teaching that related geometry data can be sent to another system and displayed. Using this teaching to show that displaying geometry at a different system was known in the art, and relying on that teaching does not change Massaro’s operation.
For the reasons discussed above, applicant’s arguments have been considered but are not persuasive. Therefore, the rejection of claims 1, 8 and 15 under 35 U.S.C. §103 is maintained.
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 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Are the claims to a process, machine, manufacture or composition of matter?"
Yes, Claim 1-7 are directed to method and fall within the statutory category of processes.
Yes, Claims 8-14 are directed to system and fall within the statutory category of machines;
Yes, Claim 15-20 are directed to non-transitory computer-readable medium and falls within the statutory category of manufactures;
In order to evaluate the Step 2A inquiry "Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?" we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 1: The limitations of “determining, …, 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;” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation (BRI), covers performance of the limitation in the mind. A person, for example, is capable of observing and evaluating CAD model feature to determine implicit function and a proprietary geometry representation for CAD body, applying a transformation (e.g., sparse field structure or other geometric obfuscation) for the defined proprietary geometry representation in a specific way for protect proprietary geometry representation, and then converting the implicit function and external function in a written or verbal format resembling code (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).).
It also can be considered to represent mathematic concepts (i.e., determine…implicit function … for a CAD body and expressing, …, the at least one implicit function … as code;). In the instant specification, [0031], “an implicit equation/function can be the signed distance function (SDF) of a mesh of a given one of the CAD body/bodies.” [0035], “With reference to Fig. 4, implicits can describe shapes in terms of equations/functions …, the same circle can be described in an implicit fashion 403, such as through one or more equations which can be expressed as the code of 403. Describing shapes in an implicit fashion advantageously yields functions/equations which can take varying inputs (e.g., spatially varying inputs).”
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Prong I step 2A.
Claims 8 and 15 and recite the similar elements as claim 1, and is rejected for the same reasons under 35 U.S.C. 101.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea under Prong I step 2A.
Therefore, claims 1, 8 and 15 recite judicial exceptions. The claims have 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.
In particular, the claims recite the following additional elements - "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” and “an electronic input device of a computer” 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 generic computing components and functions being used as a tool or instructions to implement the judicial exception (see MPEP § 2106.05(f)) with the broad reasonable interpretation, which does not integrate a judicial exception into elements.
Further, 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.” which are merely recitations of insignificant extra-solution activity, such as data gathering (i.e., provide code to target system) and data output (i.e., displaying CAD body at target system) which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). The insignificant extra-solution activities are further addressed below under step 2B as also being Well-Understood, Routine, and Conventional (WURC).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 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 claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components which do not amount to significantly more than the abstract idea. Further, the insignificant extra-solution data gathering and outputting data activities are also Well-Understood, Routine and Conventional (see MPEP § 2106.05(d)(ll)). 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, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); …
Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality: vi. Instructions to display two sets of information on a computer display in a non-interfering manner, without any limitations specifying how to achieve the desired result, Interval Licensing LLC v. AOL, Inc., 896 F.3d 1335, 1344-45, 127 USPQ2d 1553, 1559-60 (Fed. Cir. 2018);
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” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation (BRI), covers performance of the limitation in the mind. A person, for example, is capable of observing and evaluating received data to define a traditional geometry representation for the CAD body (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).), and wherein the code includes a call to an external function stored on the target system and corresponding to the traditional geometry representation.” This merely further defined the received code referring to claim 1 , which is merely recitations of insignificant extra-solution activity, such as data gathering (i.e., receiving the code at target system) which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). 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 merely further specifies extra data are sent by source device, and receiving at target device, which is merely recitations of insignificant extra-solution activity, such as data gathering (i.e., provide data to the target system) which does not integrate a judicial exception into practical application (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 merely specifies a sparse field structure for obfuscating the proprietary geometry representation; therefore, it merely an extension of mental process. 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 merely specifies implicit function includes a signed distance function, it merely an extension of mental process and mathematic concepts. 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 merely specifies inputs for code; therefore, it merely recitations of insignificant extra-solution activity, such as data gathering (i.e., inputs) which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). 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 merely specifies GPU receives code (e.g., instructions) for display; therefore, it merely recitations of insignificant extra-solution activity, such as data gathering (i.e., receive partial code and display CAD) which does not integrate a judicial exception into practical application (see MPEP § 2106.05(g)). Therefore, the claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 9-14 and 16-20 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, 6-8, 13-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis
US 20050140678 in view of Gupta US 20180081997 A1 and Makkinejad US 20090300774 A1 and Massaro US 20160034605 A1.
Claim 1, Gielis teaches A computer-implemented method for computer aided design (CAD) exchange ([0200] - [0216]; [0209] “to export a shape into an external file format, … , since a common type of information is represented: e.g., SUPERSHAPES, a common file format is used to represent this information. Among other things, the use of a common file format can have some notable advantages in this context, such as:” [0210] “enabling the exchange of information between products … [0216] … information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting.”; [0142], “…a SUPERFORMULA-based modeller (such as, e.g., a 2-D and/or 3-D modeller) can advantageously be used in a variety of applications, ranging from CAD/CAM…”) comprising:
determining, with a source computing system , at least one implicit function and a proprietary geometry representation for a CAD body ([0086], “…computer system…”; [0143]-0147]; [0145] “…Since SUPERFORMULA 3D shapes can be expressed as implicit functions all of the above and other operations can be performed with SUPERSHAPES.” [0147] “As the SUPERFORMULA allows for both parametric expression and implicit function, the advantages of both, namely enumeration and classification of points, can be combined. This variety of possible operations and basic representations makes the SUPERFORMULA one of the most powerful shape representations, and certainly, a very uniform representation too.” [0142], “…a SUPERFORMULA-based modeller (such as, e.g., a 2-D and/or 3-D modeller) can advantageously be used in a variety of applications, ranging from CAD/CAM…” fig.20, [0169], “FIGS. 20-21 show an illustrative graphical user interface (GUI) that can be presented to a user in some illustrative 3D shape creator software applications. In this regard, FIG. 20 shows an illustrative shape window that can be presented which shows the produced shape. In some illustrative examples, additional commands (e.g., for creating and/or varying shapes, etc.) can be entered via a pointer device (such as, e.g., by a right-mouse click). In some illustrative examples, such as shown in FIG. 21, a separate parameter interface window can also be provided. In such a separate parameter interface window, a set of parameters can be selected and/or modified.”);
(fig.20. produced shape; [0086], “…computer system…”;);
expressing, with the source computing system, the at least one implicit function and ([0215] “the information can be coded using defined file standards, such as, e.g., XML. Among other things, SUPERSHAPE files can be represented as XML documents and an abstract grammar can be defined for SUPERSHAPES using, e.g., DTD (Document Type Definition). In addition, SUPERSHAPES can also be coded using SVG (Scalable Vector Graphics) in some embodiments.” [0147], “…SUPERFORMULA 3D shapes can be expressed as implicit functions all of the above and other operations can be performed with SUPERSHAPES…”; therefore, the SUPERSHAPES is coded into defined file standards including implicit function (i.e., SUPERFORMULAR is expressed as implicit function);
providing, with the source computing system, the code to a target system ([0201], “…the shapes created can be saved to an external file. In preferred embodiments, a wide variety of file formats are available to which the created shapes can be saved. By way of example, in some embodiments, at least the following file formats are supported: [0202] GENICAP SUPERGRAPHX Format (GSF): This is a file format by GENICAP, the assignee of the present invention, that represents SUPERSHAPES. Using this format, complex 3D shapes can be described very compactly, reducing file-sizes by a factor of 1000 or more in relation to other file formats. In some preferred embodiments, the GSF file format can be used as a common transport format between some or all applications (e.g., so as to greatly enhance communications and/or the like).” [0216] “… information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting.” Note: The library is interpreted as one type of target system and transport format between some or all application is also interpreted the code to another type of target system); and
However, Gielis does not explicitly to teach obfuscating the geometry representation.
Gupta teaches obfuscating the geometry representation ([0054], “… embedding security elements into a computer model that can be either printed accurately or not printed accurately on specific 3D printers. In an example embodiment, an original CAD model is obfuscated by introducing special elements that prevent high-quality manufacturing of the 3D geometry specified by the CAD model unless certain conditions for printing and processing of the CAD model are met. Specifically, when these special conditions are not met, the manufactured artifact will be defective because the presence of embedded elements in the final part printed using the original CAD model reduces the quality and performance of the part.”)
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis to incorporate the teachings of Gupta, and apply embedding security elements into a computer model in order to provide a new layer of protection against part counterfeiting and theft. [0055] In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Gupta teaches embedding security elements into a computer model (i.e., geometry representation) that can be either printed accurately or not printed accurately on specific 3D printers for security protection.
Therefore, it would have been obvious to combine coding of implicit-function-based SUPERSHAPES with the file export of Gielis with embedding security elements system of Massaro in order to protect proprietary CAD model during file export, such as avoid an unauthorized activities to obtains the CAD geometry.
However, Gielis and Gupta does not explicitly to teach obfuscating the geometry representation in a corresponding external function and expressing the external function as code.
Makkinejad teaches obfuscating the geometry representation in a corresponding external function and expressing the external function as code ([0035], “The obfuscation API 136 provides a set of classes and methods that may be used to invoke the obfuscation features of the framework 130 using various programming languages and operating environments. For instance, the obfuscation API 136 may provide bindings for several programming languages or environments, including C, C++, Java, .Net, Python, and Perl, as well as others.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta to incorporate the teachings of Makkinejad, and apply obfuscation API provides a set of classes and methods as external function and bindings API with code in order to provide standard interfaces to be used by the applications when accessing and harnessing the functionality of the framework. [0035] In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Gupta teaches embedding security elements into a computer model (i.e., geometry representation) that can be either printed accurately or not printed accurately on specific 3D printers for security protection. Makkinejad teaches obfuscation API provides a set of classes and methods that may be used to invoke the obfuscation features of the framework using various programming languages and operating environments.
Therefore, it would have been obvious to combine coding of implicit-function-based SUPERSHAPES with the file export of Gielis, the embedding security elements system of Massaro, and the programmable obfuscation access via external function of Makkinejad in order to provide a robust way to protect proprietary CAD model during file export, such as avoid an unauthorized actor obtains a 3D model; specially, it would allow coded CAD proprietary geometry to be obfuscated before export using code-based external function.
However, Gielis and Gupta and Makkinejad does not explicitly to teach displaying the CAD body at the target system based on the code.
Massaro teaches displaying the CAD body at the target system based on the code (see claim 12, “… generating a visual representation of the CAD drawing, wherein the visual representation is formatted according to a drawing format used by the target application; and storing the visual representation in the composite drawing file, wherein a display of the visual representation generated by the target application reflects a display of the CAD drawing generated by the source application. [0008], “… importing data parameters into a program code and applying standard information such as design specifications as well as specific data associated with a system.” [0010], “… Geometrical information representing the visual representation and the property values of each component are exported to a data file using the first program code … The data file is then imported into a second software application. The data file and the standards information is used to generate a final design using the second software application.”)
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta and Makkinejad to incorporate the teachings of Massaro, and apply generating a visual representation of the CAD drawing, wherein the visual representation is formatted according to a drawing format used by the target application in order to display of the visual representation generated by the target application reflects a display of the CAD drawing generated by the source application. In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Gupta teaches embedding security elements into a computer model (i.e., geometry representation) that can be either printed accurately or not printed accurately on specific 3D printers for security protection. Makkinejad teaches obfuscation API provides a set of classes and methods that may be used to invoke the obfuscation features of the framework using various programming languages and operating environments. Massaro teaches generating a visual representation of the CAD drawing is formatted according to a drawing format used by the target application, then import the file to the second application in the target device, and display of the visual representation generated by the target application reflects a display of the CAD drawing generated by the source application.
Therefore, it would have been obvious to combine all the teaches in order to provide a robust way to protect proprietary CAD model during file export, such as avoid an unauthorized actor obtains a 3D model; specially, it would allow coded CAD proprietary geometry to be obfuscated before export using code-based external function, and generate and display a visual representation consistent with the CAD shape with source application. Examiner note: the first program code used to generate and export geometry and property data can reasonably be interpreted as a portion of the code.
Claim 6, Gielis 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 ([0216] information regarding the common file formats are into a GENICAP Class Library (GCL), such that all products can use the common methods for importing and exporting. [0210] enabling the exchange of information between products; [0211] enabling common libraries to be built that can be used in any supporting product; [0169] …FIG. 20 shows an illustrative shape window that can be presented which shows the produced shape. In some illustrative examples, additional commands (e.g., for creating and/or varying shapes, etc.) can be entered via a pointer device (such as, e.g., by a right-mouse click).” [0202] GENICAP SUPERGRAPHX Format (GSF): … the GSF file format can be used as a common transport format between some or all applications (e.g., so as to greatly enhance communications and/or the like).Examiner note: It would have been obvious to one of ordinary skilled in the art understand that other devices would allow to load or import the common file including SUPERSHAPE is coded in XML documents, and show instructions in the user interface for varying inputs allow for one or more of parametric edit and manufacturing process correction since it disclosed “exchange of information between products and GSF file format can be used as a common transport format between some or all applications (e.g., so as to greatly enhance communications and/or the like)”).
Claim 7, Gielis 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 (fig.20-21; [0169] FIGS. 20-21 show an illustrative graphical user interface (GUI) that can be presented to a user in some illustrative 3D shape creator software applications. In this regard, FIG. 20 shows an illustrative shape window that can be presented which shows the produced shape. In some illustrative examples, additional commands (e.g., for creating and/or varying shapes, etc.) can be entered via a pointer device (such as, e.g., by a right-mouse click). In some illustrative examples, such as shown in FIG. 21, a separate parameter interface window can also be provided. In such a separate parameter interface window, a set of parameters can be selected and/or modified. Note: It would have been obvious to one of ordinary skilled in the art understand that GUI is a portion of the code is provided to the GPU for rendering display and enabling user interaction with systems).
The elements of claims 8, 13-15 and 20 are substantially the same as those of claims 1 and 6-7. Therefore, the elements of claims 8, 13-15 and 20 are rejected due to the same reasons as outlined above for claims 1 and 6 -7. Further. The extra limitation 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…”; and claim 15, “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…” (See Gielis, CAD exchange discussed in claim 1; and see Massaro, [0026], “Client terminals 110 and 120 are typically computers, or other processing devices such as a desktop computer, laptop computer, personal digital assistant (PDA), wireless handheld device, and the like. They may be capable of processing and storing data themselves or merely capable of accessing processed and stored data from another location (i.e., both thin and fat terminals). These client terminals 110, 120 are operatively connected to network 104, via bi-directional communication channels 116, 122, respectively, which may be for example a serial bus such as IEEE 1394, or other wire or wireless transmission medium. Client terminals 110, 120 are described in more detail in relation to FIG. 3.”; [0041], “As shown in FIG. 4, algorithm 400 is a series of steps, typically stored on a computer-readable medium that may be executed at a server, or other processing device to implement the present invention.”)
Claim(s) 2, 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Gupta
and Makkinejad and Massaro as applied to claims 1, 8 and 15 above, and further in view of Williams US20150332487A1.
Claim 2, Gielis and Gupta and Makkinejad and Massaro fail to teaches 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.
Williams teaches 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 (Fig.2-3; [0026], “… a request processing module 136 may process requests from client devices such as the client device 102, identify and retrieve relevant portions of the polygon data 114 (e.g., polylines and patterns) along with other relevant map data, and transmit this data to the requesting client device via the network interface 132 and the network 112. Further, a polygon encoding module 138 may, after the request processing module 136 retrieves relevant portions of the polygon data 114 and prior to sending the portions of the polygon data 114 to the client device 102, encode or represent the portions of the polygon data 114 in a format or representation that is both efficient for communication to a client device 102 and easily rendered by the client device 102, as further discussed below. Upon receiving the data, the client device 102 may invoke a polygon decoder 140 configured to decode or process the encoded portions of the polygon data 114 from the map data server 104. For example, the polygon decoder 140 may process the encoded portions of the polygon data 114 and communicate vertices, indices into a list of vertices, etc. to the graphics card 120 for rendering.” [0018], “ … the representation of polygons allows for an implicit definition of the boundary of a polygon via an ordering of vertices in the indexed list of vertices.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta and Makkinejad and Massaro to incorporate the teachings of Williams, and apply the encoded polygon data is both efficient for communication to a client device and easily rendered by a client device in order to the client device may locally retrieve a corresponding formula and generate an appropriate description of component shapes. In this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Gupta teaches embedding security elements into a computer model (i.e., geometry representation) that can be either printed accurately or not printed accurately on specific 3D printers for security protection. Makkinejad teaches obfuscation API provides a set of classes and methods that may be used to invoke the obfuscation features of the framework using various programming languages and operating environments. Massaro teaches generating a visual representation of the CAD drawing is formatted according to a drawing format used by the target application, then import the file to the second application in the target device, and display of the visual representation generated by the target application reflects a display of the CAD drawing generated by the source application. Williams teaches the target system invokes a polygon decoder 140 as external function to decode the portions of the polygon data as traditional geometry representation.
Therefore, it would have been obvious to combine all teaches in order to provide a robust way to protect proprietary CAD model during file export, such as avoid an unauthorized actor obtains a 3D model; specially, it would allow coded CAD proprietary geometry to be obfuscated before export using code-based external function, and generate and display a visual representation consistent with the CAD shape from source application, and the code includes a call to an external decoding function, such as the polygon decoder stored on the target system, configure to decode the encoded traditional CAD shape prior to display or rendering.
The elements of claims 9 and 18 are substantially the same as those of claim 2. Therefore, the elements of claims 9 and 18 are rejected due to the same reasons as outlined above for claim 2.
Claim(s) 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Gupta
and Makkinejad and Massaro as applied to claims 1, 8 and 15 above, and further in view of Rappoport US 7099803.
Claim 3, Gielis further teaches providing to the target system, with the source computing system, ([0086], “…computer system…”; i.e., GENICAP Class Library (GCL) or other devices would import the common file formats from GCL)”).
However, Gielis and Gupta and Makkinejad and Massaro fail to teach a backup texture for the CAD bodies.
Rappoport teaches a backup texture for the CAD bodies (fig.6; col.52-57, “A current object region 605 temporarily caches (examiner note: i.e., backup texture) one or more portions of a feature list from a source CAD system 401--this cache generally represents a set of data (or operations) that is sufficiently proportioned so that it is large enough to hold the largest source operation pattern; col.10, line 10-17, “a bridge structure 402' is shown in FIG. 6. The bridge structure 402' can be universal data type or product representation--that is, an intermediate data type that is not, strictly speaking, the target data type. Thus, the bridge structure 402' can include additional information concerning the source CAD model, the target CAD model, and extraction and creation information that can be used for a lossless, two-way data exchange.” Examiner note: it would have been obvious to one of ordinary skilled in the art understand a temporarily caches as backup texture for one or more portions of a feature list from a source CAD system can be sent to bridge structure (e.g., part of target system) associated with target CAD system).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta and Makkinejad and Massaro to incorporate the teachings of Rappoport, and apply a temporarily caches as backup texture for one or more portions of a feature list from a source CAD system can be sent to bridge structure (e.g., part of target system) associated with target CAD system in order to set up a dedicated storage area on a target system that allowing faster retrieval of that data by significantly reducing the need to repeatedly fetch it from the original source, thus improving overall performance.
The elements of claims 10 and 17 are substantially the same as those of claim 3. Therefore, the elements of claims 10 and 17 are rejected due to the same reasons as outlined above for claim 3.
Claim(s) 4, 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Gupta
and Makkinejad and Massaro as applied to claims 1, 8 and 15 above, and further in view of Arya US 20150039902 A1.
Claim 4, Gielis and Gupta and Makkinejad and Massaro further teaches The computer-implemented method for CAD exchange of claim 1, wherein obfuscating the proprietary geometry representation (see Gielis, fig.20; See Gupta [0054]) .
However, Gielis and Gupta and Makkinejad and Massaro fail to teach obfuscating representation is performed using a sparse field structure.
Arya teaches obfuscating representation is performed using a sparse field structure ([0009], “To provide further security of hashed values, digest obfuscation may be performed on hashed values output from a hashing algorithm. Digest obfuscation may include translating bits of the hashed value into bit units according to a sparse bit selection pattern, and performing a cypher on the resultant bit units according to a digit cypher, using the bit units as indices into the digit cypher to generate a resultant obfuscated value.” [0031], “The obfuscation application 122 may further utilize a sparse bit selection module 412 to generate a translated digest 414 from the digest 404 (or from a truncated digest 410 in cases in which a truncation module 408 is employed). The translated digest 414 may include bit units including a number of bits corresponding to a digit cypher 112 to be used to generate a final output. For instance, for a digit cypher 112 using base 64, the bit units may include six bits. To determine the bit units of the translated digest 414, the sparse bit selection module 412 may utilize a sparse bit selection pattern 114 to determine which input data bits 302 of the digest 404 to transpose into what bit unit locations 306 of which output bit units 304.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta and Makkinejad and Massaro to incorporate the teachings of Arya, and apply Digest obfuscation may include translating bits of the hashed value into bit units according to a sparse bit selection pattern in order to generate a resultant obfuscated value. in this case, Gielis teaches SUPERSHAPES (i.e., proprietary geometry representation in fig.20) is coded using defined file standards (e.g., XLM or SVG), where the SUPERSHAPES including implicit function and parametric expression; then it can be saved to an external file, such as GENICAP SUPERGRAPHX Format (GSF) that represents SUPERSHAPES. Gupta teaches embedding security elements into a computer model (i.e., geometry representation) that can be either printed accurately or not printed accurately on specific 3D printers for security protection. Makkinejad teaches obfuscation API provides a set of classes and methods that may be used to invoke the obfuscation features of the framework using various programming languages and operating environments. Massaro teaches generating a visual representation of the CAD drawing is formatted according to a drawing format used by the target application, then import the file to the second application in the target device, and display of the visual representation generated by the target application reflects a display of the CAD drawing generated by the source application. Arya teaches performing digest obfuscation by translating bits of a hashed value into bit units according to a sparse bit selection pattern, then performing cypher on those translated bits to generate an obfuscated result.
Therefore, it would have been obvious to combine all these teachings a system that obfuscates proprietary geometry using a sparse field structure to improve data confidentiality, geometric protection, and secure CAD exchange.
The elements of claims 11 and 16 are substantially the same as those of claim 4. Therefore, the elements of claims 11 and 16 are rejected due to the same reasons as outlined above for claim 4.
Claim(s) 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Gielis and Gupta
and Makkinejad and Massaro as applied to claims 1, 8 and 15 above, and further in view of Ameta US 20240135053.
Claim 5, Gielis and Gupta and Makkinejad and Massaro fail to teaches the determination of the at least one implicit function comprises determination of a signed distance function (SDF).
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.”).
It would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Gielis and Gupta and Makkinejad and Massaro to incorporate the teachings of Ameta, and apply signed distance functions represent lattice structures of CAD objects in order to increase the efficiency at which lattice designs are represented, instantiated, and processed, and may thus increase the computational speed and reduce memory requirements of computing systems that perform lattice infill generation and transformation processes [0015].
The elements of claims 12 and 19 are substantially the same as those of claim 5. Therefore, the elements of claims 12 and 19 are rejected due to the same reasons as outlined above for claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shapiro US 6718291, disclose geometric models by implicit mathematical functions. The implicit functions allow interpolation of all desired boundary conditions over the geometry without meshing, and the boundary conditions may then may be combined with a piecewise continuous model of the solution structure (i.e., the analysis problem).
Rappoport US 6614430, discloses a method and apparatus for mechanical data exchange between parametric computer aided design systems ("CAD"). According to an embodiment, computer-implemented methods, techniques and structures are employed to extract parametric specification data from a source CAD file and create a second parametric-based CAD file for a different CAD system. In one embodiment, an intermediate data structure is utilized. An objective is creation of a second parametric-based CAD file that preserves design intent of the parametric-based source CAD file.
D'Souza US 6587746, discloses a code generation program, referred to as a parent program, for the creation of a child program for generating CAD script commands for automatically creating drawings in a CAD program.
“Modelling with Implicit Surfaces that Interpolate” by GREG TURK, published in October 2002,
discloses implicit functions for 2D and 3D modeling associated with CAD, and equations into code (introduction, page.861, 866).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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