DETAILED ACTION
This action is in response to the submission filed on 5/3/2022. 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 .
Drawings
The drawings are objected to because Figures 6 and 7 contain text which is illegible. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Applicant is directed to 37 CFR § 1.84 - Standards for drawings, specifically section (p) Numbers, letters, and reference characters:
“(3) Numbers, letters, and reference characters must measure at least .32 cm. ( 1/8 inch) in height. They should not be placed in the drawing so as to interfere with its comprehension. Therefore, they should not cross or mingle with the lines. They should not be placed upon hatched or shaded surfaces. When necessary, such as indicating a surface or cross section, a reference character may be underlined and a blank space may be left in the hatching or shading where the character occurs so that it appears distinct.”
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 12 and 21 recite “wherein each content object is an entity or a relation, is identified by a content identifier, is part of a single unit of content that represents all evolutions of the entity or relation and is associated with a corresponding physical object”. It is unknown what “a single unit of content is”. The written description does not reasonably convey the meaning of this limitation. The disclosure provides little to no description for a single unit of content, and no description of the single unit of content representing evolutions of an entity or relation.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-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 “storing at least a first iteration and a second iteration of a design for the component in the module” and “wherein each content object is an entity or a relation, is identified by a content identifier, is part of a single unit of content that represents all evolutions of the entity or relation and is associated with a corresponding physical object”, which is extremely vague and unclear. It is unknown what ‘a single unit of content is’. The disclosure provides little to no description for a content object being a part of a single unit of content. It is also unclear how a single unit of content could ‘represent all evolutions’ and what ‘representing’ means in this context; reciting the term ‘all evolutions’ implies than evolutions were previously recited. It is unknown what it would mean for entities or relations to have ‘evolutions’. It is also unclear what the difference is between design iterations and evolutions; paragraph [0048] of the printed publication implies that they are one and the same. The claim is extremely vague and it is unclear how to interpret and differentiate between the terms ‘module’ vs. ‘component’ vs. ‘content object’ vs. ‘unit of content’ vs. entity. Any application of prior art is the Examiner’s best interpretation of the claimed subject matter. Claims 2-11 and 13-20 are rejected by virtue of their dependency.
Claims 6 and 16 recite “enabling all authorized users to access…” which implies that authorized users were previously recited in the claims when they have not. Appropriate correction is required.
Claims 6 and 16 also recite “enabling all authorized users to access mutable versions of the immutable first iteration”. It is unclear how there can be mutable versions of an immutable iteration, as these states are contradictory.
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.
Claims 1-22 are 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 claims 1-22, applying step 1, the preamble of independent claims 1, 12 and 21 claim a method, system and a non-transitory computer readable medium. As such these claims fall within the statutory categories of process, machine, and article of manufacture. With respect to claim 22, independent claim 22 is drawn to “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.
Step 2A, prong one: In order to apply step 2A, a recitation of claim 1 is copied below. The limitations of the claim that describe an abstract idea are bolded.
A computer-based method of managing iterations and branching in a design evolution, the method comprising:
creating a module that corresponds to a component in response to a user command (mental process/drawing with pen and paper –observation, evaluation, judgement, opinion); and
storing at least a first iteration and a second iteration of a design for the component in the module (mental process/drawing with pen and paper –observation, evaluation, judgement, opinion),
wherein each of the first and second iterations contains one or more content objects (mental process/drawing with pen and paper –observation, evaluation, judgement, opinion), and
wherein each content object is an entity or a relation, is identified by a content identifier, is part of a single unit of content that represents all evolutions of the entity or relation and is associated with a corresponding physical object (mental process/drawing with pen and paper –observation, evaluation, judgement, opinion).
The limitations as analyzed include concepts directed to the "mental process" groupings of abstract ideas performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III). The claim creating iterations of designs for components in modules. The steps are simple enough/broadly claimed that they could be performed mentally or with pen and paper and drawing the components and content objects. Thus, limitations noted above also fall into the "mental process" groupings of abstract ideas.
Step 2A, prong two: Under step 2A prong two, this judicial exception is not integrated into a practical application because the additional claim limitations outside the abstract idea only present generic computing components or insignificant extra-solution activity. In particular, the claim recites the additional limitations: “A computer-based method of managing iterations and branching in a design evolution” (generic computing components merely carrying out the abstract idea - see MPEP § 2106.05(f) and (b)), “storing at least a first iteration and a second iteration of a design” (insignificant extra-solution activity - mere data gathering MPEP 2106.05(g)).
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B: Moving on to step 2B of the analysis, the Examiner must consider whether each claim limitation individually or as an ordered combination amounts to significantly more than the abstract idea. This analysis includes determining whether an inventive concept is furnished by an element or a combination of elements that are beyond the judicial exception. For limitations that were categorized as "apply it" or generally linking the use of the abstract idea to a particular technological environment or field of use, the analysis is the same. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitations is considered directed towards generic computer components carrying out the abstract idea and data gathering. See MPEP 2106.04(d) referencing MPEP 2106.05(h). Furthermore, as Berkheimer evidence that the claim element “storing at least a first iteration and a second iteration of a design” is Well-Understood, Routine, and Conventional, MPEP § 2106.05(d) (II) provides support that mere data collecting and data outputting is well understood, routine, and conventional: "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:
• Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP
Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788
F.3d at 1363, 115 USPQ2d at 1092-93
For the foregoing reasons, claim 1 is directed to an abstract idea without significantly more, and is rejected as not patent eligible under 35 U.S.C. 101. Independent claims 12, 21 and 22 are directed to substantially the same subject matter as independent claim 1 and are rejected under similar rationale and further failure to add significantly more.
The same conclusion is reached for the dependent claims 2-11 and 13-20.
Claims 2-11 are further directed to concepts directed to the "mental process" groupings of abstract ideas performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III). The claim creating iterations of designs for components in modules. The steps are simple enough/broadly claimed that they could be performed mentally or with pen and paper and drawing the components and content objects. Thus, limitations noted above also fall into the "mental process" groupings of abstract ideas. This judicial exception is not integrated into a practical application because the additional claim limitations outside the abstract idea only present generic computing components or insignificant extra-solution activity. In particular, the claim recites the additional limitations: “The computer-based method” (generic computing components merely carrying out the abstract idea - see MPEP § 2106.05(f) and (b)), “virtual workspace” (generic computing components merely carrying out the abstract idea - see MPEP § 2106.05(f) and (b)), “user interface device” (generic computing components merely carrying out the abstract idea - see MPEP § 2106.05(f) and (b)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitations is considered directed towards generic computer components carrying out the abstract idea.
Claims 13-20 are further directed to concepts directed to the "mental process" groupings of abstract ideas performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III). The claim creating iterations of designs for components in modules. The steps are simple enough/broadly claimed that they could be performed mentally or with pen and paper and drawing the components and content objects. Thus, limitations noted above also fall into the "mental process" groupings of abstract ideas. This judicial exception is not integrated into a practical application because the additional claim limitations outside the abstract idea only present generic computing components or insignificant extra-solution activity. In particular, the claim recites the additional limitations: “The computer-based system”, “computer-based memory”, “computer-readable instructions”, “one or more processors”, “computer-based system”, “virtual workspace”, “user interface device” (generic computing components merely carrying out the abstract idea - see MPEP § 2106.05(f) and (b)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional limitations is considered directed towards generic computer components carrying out the abstract idea.
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 (Hirschtick: para [0036-0038]), the method comprising:
creating a module that corresponds to a 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: 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”),
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 evolutions of the entity or relation and is associated with a corresponding physical object (Hirschtick: paras [0043], “The solution utilizes a Compound Document approach, with additional benefits: [0044] An entire product design of arbitrary size can be stored in a single Compound Document [0045] All CAD data (parts, drawings, assemblies, etc) and non-CAD data (PDF files, Word processing files, spreadsheet files, image files, videos, etc.) can be stored as “Tabs” in one compound Document [0046] CAD data in multiple native CAD formats from multiple different CAD systems can be stored together in a single Compound Document”).
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 all 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)”),
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 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”),
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”).
Additional References Cited
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and are cited in the attached PTOL-892.
Conclusion
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 on 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