DETAILED ACTION
This action is in response to the submission filed on 3/23/2026. Claims 1-22 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments- Drawings
Applicant’s arguments with respect to the amendments have been fully considered and are persuasive. The objections have been withdrawn.
Response to Arguments- 35 USC § 112
Applicant's arguments regarding the amendments filed have been fully considered and the rejections are partially withdrawn. However, some rejections have not been addressed by the amendments. See below.
Response to Arguments- 35 USC § 101
Applicant's arguments regarding the amendments filed have been fully considered. The rejections to claims 1-21 have been withdrawn. The rejection to claim 22 is maintained.
Applicant argues on pages 10-11 that “Even if the branches and objects themselves comprise only software objects, here the software itself is not being claimed. Instead, the data model for store software is claimed, and therefore claim 1 does not comprise software per se.” This argument does not make sense, because a data model is purely software. The claim recites no hardware for performing the software functions.
Response to Arguments- 35 USC § 102
Applicant's arguments filed have been fully considered but they are not persuasive.
Applicant argues on pages 13-15 that Hirschtick does not disclose a module storing all branches/iterations over a design evolution of a product.
Hirschtick, paragraphs [0273-0274 describes the “Version Manager”: “Referring also to FIG. 22, the system provides a graphical representation of versions 2200 and workspaces 2210 in the Version Manager”. Versions 2200 include versions such as “Alternative 1” and “Alternative 2”. The Version Manager is the ‘module’ that stores all iterations. The independent claims also refer to ‘a single unit of content’ that represents all design evolutions of the entity or relation and is associated with a corresponding physical object. It is unclear how the “single unit of content” is different from the module listed. It is also assumed that “design evolutions” and “iterations” are synonymous. For the purposes of examination, the module and the “single unit of content” are considered equivalent. The content objects are entities that “are a part of” the Version Manager which represents the design evolutions and is also the “single unit of content”.
The rejection has been updated to reflect the amended claim language.
Claim Rejections - 35 USC § 112
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 12 and 21 recite “a single unit of content that represents all design evolutions” which implies that multiple design evolutions were previously recited, when they were not. It is unclear if design evolutions is referring to the first and second iterations, and if not, what is the difference between iterations and design evolutions.
Claims 6 and 16 also recite “enabling all authorized users to access mutable versions of the immutable first iteration, the second iteration, and/or the third iteration…” It is unclear how there can be mutable versions of an immutable iteration. Applicant states on page 20 that “Applicant believes it is clear that an initial version of an object ("first iteration") may be immutable, but subsequent versions/revisions/iterations may be mutable”. However what Applicant “believes” is irrelevant; the claim recites a contradictory statement. Further, Applicant’s argument implies that the second and third iterations are mutable but the claims state that all versions are immutable. Appropriate correction is required.
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.
Claim 22 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. To determine if a claim is directed to patent ineligible subject matter, the Court has guided the Office to apply the Alice/Mayo test, which requires:
1. Determining if the claim falls within a statutory category;
2A. Determining if the claim is directed to a patent ineligible judicial exception consisting of a law of
nature, a natural phenomenon, or abstract idea; and
2B. If the claim is directed to a judicial exception, determining if the claim recites limitations or elements
that amount to significantly more than the judicial exception. (See MPEP 2106).
Step 1: With respect to claim 22, applying step 1, independent claim 22 claims “An object oriented data model” comprising a “module” containing “content objects”, which could be interpreted to comprise only software elements. According to the current guidance, a system that qualifies as a patent eligible system under 35 USC 101 cannot consist only of software per se. If the system consists only of software per se, the system is not a patent eligible under 35 USC 101. Because the instant claims could comprise software per se, the claims are being held as non-statutory under 35 USC 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20160246899 A1 (“Hirschtick”).
Regarding claims 1, 12 and 21, Hirschtick teaches:
A computer-based method of managing iterations and branching in a design evolution comprising changes over time in a design of a component of a product represented in a computer-based environment (Hirschtick: para [0036-0038]), the method comprising:
creating a module that virtually contains a unit of content in computer-based memory that corresponds to the component in response to a user command (Hirschtick: para [0131], “Sketcher—a software component that the user uses to create and manipulate geometry and constraints”); and
storing at least a first iteration and a second iteration of a design for the component in the module (Hirschtick: [0273] “Version Manager”; para [0274], “Referring also to FIG. 22, the system provides a graphical representation of versions 2200 and workspaces 2210 in the Version Manager”; para [0137], “Version—a named state of a compound document. Versions are immutable and separate from workspaces. To capture a workspace at a particular point in time, a user can save it as a version”; the Version Manager is the ‘module’ storing iterations),
wherein each of the first and second iterations contains one or more content objects (Hirschtick: para [0100], “Assembly—used to assemble parts. An Assembly is used to define the structure and behavior of an assembly. Each Assembly has its own Feature list that contains Instances (of parts and sub-assemblies), Mates, Mate Connectors, Groups, and Relations”; [0107], “Constraint—a relationship between two geometries that mutually limits their positions, e.g., a “coincident” constraint on two points will result in the points having the same location. There are many types of constraints, such as coincident, parallel, perpendicular, tangent and so on. Constraints are logical relationships between geometries. For example, a “parallel” constraint between two line segments will ensure that the two line segments are parallel”; para [0293], “When working with a CAD design, many geometric elements may be created based on other geometries. The geometry and relationship data are tracked as references between objects. When working within a single parametric history, making any change can be visualized from the point of change all the way to the final design (with all later features also applied)”), and
wherein each content object is an entity or a relation, is identified by a content identifier (Hirschtick: para [0189], “orange text may identify entities”; para [0256], “Mate connector
dialog for identifying an Owner Part”), is part of a single unit of content that represents all design evolutions of the entity or relation and is associated with a corresponding physical object (it is unclear how the ‘single unit of content’ is different from the module listed above; the content objects are entities that ‘is a part of’ the Version Manager which represents the design evolutions, which is also the ‘single unit of content’; Hirschtick: [0273] “Version Manager”; para [0274], “Referring also to FIG. 22, the system provides a graphical representation of versions 2200 and workspaces 2210 in the Version Manager”; paras [0043], [0044] [0046]).
Regarding claims 2 and 13, Hirschtick teaches:
The computer-based method of claim 1, wherein each of the first and second iterations, once stored, is immutable (Hirschtick: para [0042], “At any time, a user can designate an autosaved immutable state of the 3D Models on any branch as a named version without requiring creation of files”).
Regarding claims 3 and 14, Hirschtick teaches:
The computer-based method of claim 2, further comprising:
providing a mutable version of the first or second iteration to a first user's virtual workspace, in response to a request from the first user that specifies either the first or second iteration (Hirschtick: para [0024], “Disclosed are details of a parametric feature-based 3D CAD system that allows multiple users to simultaneously edit a parametric feature-based 3D CAD model consisting of 3D parts and assemblies of those parts (“3D Model”). Several CAD users, each using their own computer, phone, tablet, wearable computer (e.g., glasses, watch, etc.), or other connected computing device, can edit the same 3D Model at the same time. Editing may be separate and simultaneous—there is no need for users to worry about locking, checking out, or otherwise restricting each other's access to 3D Models. As a result, users see each other's changes occur in real-time, and may also identify what aspects other users are actively modifying through visible “Collaboration Cues”).
Regarding claims 4 and 14, Hirschtick teaches:
The computer-based method of claim 3, further comprising:
enabling the first user to modify any of the content objects in the mutable version, delete any of the content objects from the mutable version, and/or add new content objects to the mutable version, to create a modified version of the first or second iteration (Hirschtick: para [0038], “Users can visualize a textual and/or graphical view of who has performed what work when on a 3D Model, including individual edits, versions, branches, and merges”; para [0039] “Users can restore earlier states of a 3D Model, including states that existed before other users performed edits on the 3D Model”; para [0040], “Users with touch-screen tablets, phones, wearable computing devices, or other touch-based computing device, can use a touch-based user interface, 2D and 3D, to simultaneously edit the same 3D Models with users using web browsers and mice or trackpads”; para [0041], “Client software within a browser allows use without installing any software on the client device [0042] At any time, a user can designate an autosaved immutable state of the 3D Models on any branch as a named version without requiring creation of files”; para [0092], “FIG. 25 shows code representation opened while
CAD editing”).
Regarding claims 5 and 15, Hirschtick teaches:
The computer-based method of claim 4, further comprising:
storing the modified version as a third iteration in the module, in response to the first user committing the modified version to the module, wherein the third iteration, once stored, is immutable (Hirschtick: para [0271], “A project may have many workspaces; one for each branch. At any point in time, a user can save a state of a workspace as immutable, thereby creating a version. A version is a snapshot of a project at a particular point in time”).
Regarding claims 6 and 16, Hirschtick teaches:
The computer-based method of claim 5, further comprising:
enabling authorized users to access mutable versions of the immutable first iteration, the second iteration, and/or the third iteration in the module, from each respective users' virtual workspace (Hirschtick: para [0178], “The tabs may be rearranged (ordered positioning), and this action applies to the workspace (so would also be applied to any other users collaborating on the same workspace). Which tab is currently active, and any positioning/scrolling of the workspace, are user-specific and non-persistent. Therefore each user collaborating on a project workspace has their own active tab and their own tab scroll state. Options for each individual tab, accessible through the user interface, may include renaming the tab, viewing and editing tab properties (such as, but not limited to, description; part number; revision; state of a part), duplicate, copy to clipboard, export to STL, translate, and delete”).
Regarding claims 7 and 17, Hirschtick teaches:
The computer-based method of claim 3, further comprising:
storing the modified version as an initial iteration in a new branch within the module, in response to the first user committing the modified version to the module as the initial iteration in the new branch, wherein the initial iteration in the new branch, once stored, is immutable (Hirschtick: para [0042], “At any time, a user can designate an autosaved
immutable state of the 3D Models on any branch as a named version without requiring creation of files”; para [0137], “Version—a named state of a compound document. Versions are immutable and separate from workspaces. To capture a workspace at a particular point in time, a user can save it as a version”; para [0271], “A project may have many workspaces; one for each branch. At any point in time, a user can save a state of a workspace as immutable, thereby creating a version. A version is a snapshot of a project at a particular point in time. The geometric data (and the accompanying data like Part names, etc.) of that version is unchangeable”).
Regarding claims 8 and 17, Hirschtick teaches:
The computer-based method of claim 7, further comprising: storing the first iteration and the second iteration on an initial branch in the module, wherein the new branch is different than the initial branch (Hirschtick: para [0282], “A user always works in an active workspace. A project may have many workspaces, which under most circumstances do not interact with each other. Any changes a user makes within an active workspace are immediately reflected in that workspace and not in any others; any collaborators in the same workspace are immediately updated”; para [0283], “A user may bookmark a particular state of a project workspace for future reference by saving a version, a permanent and immutable state of the project. A user may branch by creating a new workspace at a given version. The initial state of the project in the new workspace is identical to that of the version. Workspaces and versions form a directed acyclic graph with a “parent” relationship; the first “parent” of a workspace being the version it was branched from, and the parent of a version being the parent version of the workspace it was saved from”).
Regarding claims 9 and 18, Hirschtick teaches:
The computer-based method of claim 7, wherein the module is one of a plurality of modules and wherein each module contains one or more content objects organized into iterations and/or branches (Hirschtick: para [0137], “Version—a named state of a compound document. Versions are immutable and separate from workspaces. To capture a workspace at a particular point in time, a user can save it as a version”; para [0283], “A user may bookmark a particular state of a project workspace for future reference by saving a version, a permanent and immutable state of the project. A user may branch by creating a new workspace at a given version. The initial state of the project in the new workspace is identical to that of the version. Workspaces and versions form a directed acyclic graph with a “parent” relationship; the first “parent” of a workspace being the version it was branched from, and the parent of a version being the parent version of the workspace it was saved from”).
Regarding claims 10 and 19, Hirschtick teaches:
The computer-based method of claim 7, further comprising:
enabling the first user to merge branches within the modules from his or her virtual workspace (Hirschtick: para [0284], “Project branches (separate workspaces within the same project) may be merged together. A basic merging scenario involves one branch which contains all newer changes from another branch, and the user merging from that branch into the one to update. A more complex merging scenario involves a main workspace, or master design, and multiple branched workspaces for developing changes, with merging intended to incorporate some changes across multiple branches into the main workspace”; para [0286], “From the selected features, the user may incrementally push (merge) a change from one workspace into the other”).
Regarding claims 11 and 20, Hirschtick teaches:
The computer-based method of claim 7, further comprising:
enabling the first user to enter a query from a user interface device specifying one of the modules, one of the branches and one of the iterations; and returning data to the user interface device that corresponds to the specified module, branch, and iteration in response to the query (Hirschtick: para [0152], “Distributed Search Servers (“DSS”) 155 are preferably run in a clustered configuration in a Core data center. DSS run software including, but not limited to, an operating system such as Ubuntu or other Linux variant and commercial or open-source software such as elasticsearch. DSS provide both data indexing and a search mechanism for locating projects, parts, users, etc. from a query string”; para [0276], “Version actions include Open (open and switch to the graphics area for the selected version in view only mode), Open in new browser tab (open the selected version in a new browser tab in view only mode), Branch to create workspace (create a new branch and workspace from the selected version), and Properties (create or edit meta data about the selected version). Workspace actions include Open (switch to and open the graphics area for the selected workspace), Open in new browser tab (open the selected workspace in a new browser tab), History (view the persistent transaction history records for the selected workspace), Properties (create or edit meta data for the selected workspace), and Delete (delete the selected workspace; note that users cannot delete the last remaining workspace—to do so requires deleting the entire project)”).
Regarding claim 22, Hirschtick teaches:
An object-orientated data model (Hirschtick: Fig. 6) comprising:
a user-specified module containing content objects, wherein each content object is either an entity or a relation (Hirschtick: para [0189], “orange text may identify entities”; para [0100], “Assembly—used to assemble parts. An Assembly is used to define the structure and behavior of an assembly. Each Assembly has its own Feature list that contains Instances (of parts and sub-assemblies), Mates, Mate Connectors, Groups, and Relations”; para [0293], “When working with a CAD design, many geometric elements may be created based on other geometries. The geometry and relationship data are tracked as references between objects. When working within a single parametric history, making any change can be visualized from the point of change all the way to the final design (with all later features also applied)”; para [0131], “Sketcher—a software component that the user uses to create and manipulate geometry and constraints”),
wherein each content object has a content ID and an associated physical object (Hirschtick: para [0189], “orange text may identify entities”; para [0256], “Mate connector
dialog for identifying an Owner Part”; para [0100], “Assembly—used to assemble parts. An Assembly is used to define the structure and behavior of an assembly. Each Assembly has its own Feature list that contains Instances (of parts and sub-assemblies), Mates, Mate Connectors, Groups, and Relations”), and
wherein the content objects are organized into a plurality of branches and iterations within the module (Hirschtick: para [0102], “Branch—workspace for a specific version of a project”; para [0137], “Version—a named state of a compound document. Versions are immutable and separate from workspaces. To capture a workspace at a particular point in time, a user can save it as a version”; para [0038], “Users can visualize a textual and/or graphical view of who has performed what work when on a 3D Model, including individual edits, versions, branches, and merges”),
wherein an iteration is a change to one or more contained content objects (Hirschtick: para [0271], “A project may have many workspaces; one for each branch. At any point in time, a user can save a state of a workspace as immutable, thereby creating a version. A version is a snapshot of a project at a particular point in time. The geometric data (and the accompanying data like Part names, etc.) of that version is unchangeable”; para [0038], “Users can visualize a textual and/or graphical view of who has performed what work when on a 3D Model, including individual edits, versions, branches, and merges”; para [0039], “Users can restore earlier states of a 3D Model, including states that existed before other users performed edits on the 3D Model”), and wherein an associated one of the content IDs for one of the changed content objects refers to a different physical object after the change (Hirschtick: para [0189], “orange text may identify entities”; para [0256], “Mate connector dialog for identifying an Owner Part”; para [0179], “A project menu, also accessible through the user interface, allows project-wide options such as to rename the project, copy the current workspace, view or change properties (such as default units), print, access versions and/or persistent transaction history, and undo or redo actions”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NITHYA J. MOLL whose telephone number is (571)270-1003. The examiner can normally be reached Monday-Friday 10am-6pm EST.
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, Rehana Perveen can be reached at 571-272-3676. 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.
/NITHYA J. MOLL/Primary Examiner, Art Unit 2189
Prosecution Insights