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 .
Status of Claims
This Office action is in response to correspondence received July 9, 2026.
Claims 1-3, 5-12, and 14-20 are amended. Claims 4 and 14 are canceled. Claims 1-3, 5-12, and 14-20 are pending and have been examined.
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-3, 5-12, and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s):
Claim 1:
A method for automatically generating at least one recommendation for improving a product design within workspaces within which a different collaborative design process takes place, the method comprising: receiving at least one design document related to a product comprising a plurality of components; evaluating the at least one design document and the product to identify one or more design characteristics associated with at least one of the product and a current design process related to the product, wherein evaluating the at least one design document and the product further comprises: identifying a product structure for the product, the product structure defining one or more hierarchical relationships between one or more components of the plurality of components of the product, and defining at least one design characteristic of the one or more design characteristics from the product structure; identifying one or more related workspaces of other collaborative design processes associated with the one or more design characteristics identified from the at least one design document and the product; from the one or more related workspaces, identifying one or more prior design feedback associated with at least one component related to a product structure node of the product structure identified for the product, the one or more prior design feedback comprising one or more user feedback inputs received during the other collaborative design processes in respect of a different product design; determining a relevance level of the one or more prior design feedback by evaluating at least a prior design process and a prior design decision resulting from the one or more prior design feedback, wherein determining the relevance level of the one or more prior design feedback comprises: analyzing the one or more prior design feedback to identify a set of key design contributions to the prior design decision, and assigning a high priority level to the one or more prior design feedback identified to be the set of key design contributions; and generating the at least one recommendation for the product design based at least on the relevance level of the prior design process and the prior design decision.
Claim 11:
automatically generating at least one recommendation for improving a product design within workspaces within which a different collaborative design process takes place, store one or more prior design feedback comprising one or more user feedback inputs received during a collaborative design process between one or more users in respect of a different product design; receive at least one design document related to a product comprising a plurality of components; evaluate the at least one design document and the product to identify one or more design characteristics associated with at least one of the product and a current design process related to the product, wherein in evaluating the at least one design document and the product, identify a product structure for the product, the product structure defining one or more hierarchical relationships between one or more components of the plurality of components of the product, and define at least one design characteristic of the one or more design characteristics from the product structure; identify one or more related workspaces of other collaborative design processes associated with the one or more design characteristics identified from the at least one design document and the product; from the one or more related workspaces, identify one or more prior design feedback associated with at least one component related to a product structure node of the product structure identified for the product, the one or more prior design feedback comprising one or more user feedback inputs received during the other collaborative design processed conducted within the one or more related workspaces in respect of a different product design; determine a relevance level of the one or more prior design feedback by evaluating at least a prior design process and a prior design decision resulting from the one or more prior design feedback, wherein in determining the relevance level of the one or more prior design feedback, the processor is further configured to: analyze the one or more prior design feedback to identify a set of key design contributions to the prior design decision, assign a high priority level to the one or more prior design feedback identified to be the set of key design contributions; and generate the at least one recommendation for the product design based at least on the relevance level of the prior design process and the prior design decision.
Claims 1 and 11 describe an abstract idea that is a judicial exception – a certain method of organizing human activity - Managing Personal Behavior or Relationships or Interactions Between People. Here the interactions, behavior, and relationships being managed are evaluating design decisions and prior design decisions including design feedback to generate a recommendation for product design. The references to workspaces under a broadest reasonable interpretation refer to the abstract idea of where ideas about products are memorialized, could be a notebook for example. The references to product structure amount to no more than the information about the product. The node is simply another information element of the product structure. See pars 65-66 of the spec. Every element above is a combination of data, information and human activity, and nothing more. The claims as a whole –apart from additional elements – are to arrive at a recommendation based on decisions made by people. As the claims define the specifics of collaborating between people they are a certain method of organizing human activity.
This judicial exception is not integrated into a practical application. The additional elements amount to applying a generic computer or other machinery to the abstract ideas, above.
Claim 1 recites:
within an electronic collaborative system having a plurality of electronic workspaces
electronic workspace x 2
conducted within the one or more related electronic workspaces
Claim 11 recites:
A system for
within an electronic collaborative system having a plurality of electronic workspaces
the system comprising: a design data storage operable to
and a processor configured to:
the processor is further configured to:
electronic workspace x 3
These elements alone and in combination are elements found in a generic computer like storage, processor, system, and in combination they amount to instructions to apply the abstract idea to a computer. The electronic workspace is under a broadest reasonable interpretation in light of the specification any software that is used in its ordinary capacity to see design information. Taken together, and with the claims as a whole, the claims apply human activity to a generic combination of hardware and software, in other words, at least two software applications (electronic workspaces) running on at least one computer sharing information with each other. See MPEP 2106.05(f)(2). Therefore, the claims do not recite a practical application of an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, for the same reasons as there is not a practical application, the combination of additional elements being instructions to apply the abstract idea to a computer are not significantly more than the abstract idea.
Per the dependent claims
Claims 2, 4-10 and 12, 14-20 are rejected because they further describe the abstract idea or recite elements that are ordinary machinery or generic computing elements applied to the abstract idea. Metadata is simply data (data about data); determining relationships and hierarchy is simply design process; applying a model is applying a formula or other rules based structure; time periods are a part of project planning; under a broadest reasonable interpretation, a natural language summary is something that is done between people – summarizing something.
Therefore, claims 1-3, 5-12, and 14-20 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 6-8, 11, 12, and 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hakimi et al., US PGPUB 20230185997 A1 ("Hakimi") in view of LaMarche US PGPUB 20200160359 A1 ("Lamarche").
Per claims 1 and 11, which are similar in scope, Hakimi teaches A method for automatically generating at least one recommendation for improving a product design within an electronic collaborative system having a plurality of electronic workspaces within which a different collaborative design process takes place, the method comprising: receiving at least one design document related to a product comprising a plurality of components; in par 052: " A product design process 450 of FIG. 4 begins at block 452, in which a product design is manually provided to an automated analysis module. For example, a written description of the potential product is provided as an input to the stakeholder simulation engine 314 of FIG. 3. In some aspects of the present disclosure, the stakeholder simulation engine 314 takes a description of the design (text, image, or speech) as input."
Hakimi then teaches evaluating the at least one design document and the product to identify one or more design characteristics associated with at least one of the product and a current design process related to the product, wherein evaluating the at least one design document and the product further comprises: identifying a product structure for the product, the product structure defining one or more hierarchical relationships between one or more components of the plurality of components of the product, and defining at least one design characteristic of the one or more design characteristics from the product structure; in par 053: " At block 454 of the product design process 450 of FIG. 4, the product design is analyzed to determine how the product design rates based on pre-configured design attributes. For example, at block 460, the current design is compared to past iterations of the design as well as other designs from the same user. At block 456, the product design attribute ratings are compared to each persona model. At block 458, products scores are updated. At block 470, a summary of visualizations is generated." Under a broadest reasonable interpretation, evaluating the current design based on pre-configured design attributes identifies the attributes to the design (attributes are characteristics). Product design teaches under a broadest reasonable interpretation product structure as it is a hierarchical relationship between product components and subcomponents which are inherent in a product design. See Applicant specification par 8. Here design attributes teach subcomponents.
Hakimi then teaches identifying one or more related electronic workspaces of other collaborative design processes associated with the one or more design characteristics identified from the at least one design document and the product; in pars 036-037: “The machine-assisted collaborative product design server 370 may connect to the user device 350 for enabling a machine-assisted, collaborative product design process. For example, the machine-assisted collaborative product design server 370 may train a neural network to simulate a plurality of stakeholder personas in a product review process to provide a plurality of stakeholder models. In response, the machine-assisted collaborative product design server 370 is configured to simulate, using the plurality of stakeholder models, the plurality of stakeholder personas in the product review process of a potential product.
[0037] In addition, the machine-assisted collaborative product design server 370 is configured to aggregate individual scores from a plurality of stakeholder models corresponding to each of the plurality of stakeholder personas regarding the potential product. In some aspects of the present disclosure, each of the individual scores corresponds to a stakeholder persona and that stakeholder persona's reaction to the potential product. The machine-assisted collaborative product design server 370 is also configured to display a summary providing an overview of the aggregated individual scores regarding the potential product to a user.”
Under a broadest reasonable interpretation, stakeholder personas teach electronic workspaces as they have information about designs and design decisions pertaining to individuals.
Hakimi then teaches from the one or more related electronic workspaces, identifying one or more prior design feedback associated with at least one component related to a product structure node of the product structure identified for the product, the one or more prior design feedback comprising one or more user feedback inputs received during the other collaborative design processes conducted within the one or more related electronic workspaces in respect of a different product design; (note that claim 11, here similar in scope, teaches design data storage operable to store one more prior design feedback, see Fig 5 where the screen stores the prior design feedback). in par 057: "The machine-assisted collaborative product design mobile application 510 also includes a metrics section 530 for each historical design. For example, a computer aided design (CAD) designer persona 540 is shown including a metrics graph 542, in which there is no corresponding bias score. In addition, a manager persona 550 is shown, including a metrics graph 552. A product lead persona 560 is also shown, including a metrics graph 562. As noted, the various personas in this example do not include an associated bias, as these simulated personas are presumed to operate without a bias." See Fig 5 Item 530, Metrics shown for each historical design teach prior design feedback from a historical design data storage. As Fig 5 shows with different people rating the same prior design, this is a collaborative design process between one or more users.
Hakimi does not teach determining a relevance level of the one or more prior design feedback by evaluating at least a prior design process and a prior design decision resulting from the one or more prior design feedback, wherein determining the relevance level of the one or more prior design feedback comprises: analyzing the one or more prior design feedback to identify a set of key design contributions to the prior design decision, and assigning a high priority level to the one or more prior design feedback identified to be the set of key design contributions; and generating the at least one recommendation for the product design based at least on the relevance level of the prior design process and the prior design decision.
Lamarche teaches user experience development based on persona prototypes . See par 009.
Lamarche teaches determining a relevance level of the one or more prior design feedback by evaluating at least a prior design process and a prior design decision resulting from the one or more prior design feedback, wherein determining the relevance level of the one or more prior design feedback comprises: analyzing the one or more prior design feedback to identify a set of key design contributions to the prior design decision, and assigning a high priority level to the one or more prior design feedback identified to be the set of key design contributions in par 25: "The user interaction device 104 allows a number and variety of users 105 to contribute to the identification of attributes important for a target persona for a particular product or service. Each user 105 can communicate with the user interaction device 104 via an individual computerized device, such as a server, desktop, laptop, or tablet device via a network, such as a LAN or WAN. With such a configuration, the user interaction device 104 can improve efficiency (e.g., reduce redundant efforts) within an organization and can provide an opportunity for cross validation of product or service designs and real-time analysis. This, in turn, can provide the company with access to more opportunities for innovation in service design and with the ability to reach broader markets." See also par 026: “Further, as will be described in detail below, the persona source device 300 is configured to automate the persona creation process which is effective in improving market needs when it is repeated periodically. This is because personas represent a snapshot of customers in a specific context at a specific period of time. To stay in touch with evolving customer needs, organizations can repeatedly engage in the persona development process. As such, the persona source device 300 provides an effective way to capture user needs and preferences efficiently, hence it can easily be used on a substantially continual basis.” Attributes are identified prior to the evaluation of a present design, as taught in pars 025-026.
Then, the previously created personas are used where attributes are determined to have a relevance level as taught in par 043-044: “In element 202, the persona development device 102 is configured to receive a research request 116 from a user interaction device, the research request 116 including an attribute 160 related to a persona. In one arrangement, with reference to FIG. 4, a user or a group of users 105 can initiate operation of the persona development device 102 by entering a research request 116 into the user interaction device 104. As indicated above, the user interaction device 104 operates as a hub or group decision support system which facilitates the exchange of ideas among the various user for a given project. Accordingly, the use of the user interaction device 104 mitigates redundant activity among the distinct users 105 and provides the opportunity for input and cross-validation of the research request 116 before the transmitting the request 116 to the persona development device 102.
The research request 116 can include keywords or attributes 160 relating to a particular product and a persona 162 that the developers believe is associated with the product. For example, assume the case where the developers would like to improve a given smartwatch for either athletes or people who are serious about exercise. In such a case, the research request 116 can indicate that the product relates to a smartwatch and that the persona of interest includes the attributes of athletes or people who exercise regularly.”
The smartwatch under current development pulls the persona of interest (previously created set of feedback about attributes) that is relevant – athlete to smartwatch. See also par 045: “, a persona analytics module 118 of the persona development device 102 is configured extract keywords or attributes 160 from the research request 116 to identify the product or services associated with the request, as and to use the attributes 160 to retrieve a persona associated with, and in response to, the research request 116. For example, assume the case where the persona analytics module 118 has extracted the attributes 160 “smartwatch,” “athletes,” and “exercise” from the research request 116. Based the attributes 160, the persona analytics module 118 can perform a search of the persona database 112 to determine if corresponding attributes 164 exists as part of a persona 162 stored in the persona database 112.” Then see teaching of a match in par 046: “For example, with reference to FIG. 4, assume the case where the persona analytics module 118 identifies a match between the attributes 160 (i.e., “smartwatch,” “athletes,” and “exercise”) identified in the research request 116 and the attributes 164 (i.e., “smartwatch,” “athletes,” and “exercise”) of one or more personas 162 in the persona database 112. Based upon this correspondence, the persona analytics module 118 can retrieve the matching personas 162 from the database and the persona development device 102 can forward a research response 122 to the user interaction device 104 which includes the identified persona from the database 112” Match teaches relevance level under a broadest reasonable interpretation because it teaches a correspondence. This is in contrast to what is taught in par 047 where a lack of correspondence is taught.
Then, Lamarche teaches and generating the at least one recommendation for the product design based at least on the relevance level of the prior design process and the prior design decision in par 56: "In one arrangement, with reference to FIG. 4, the persona development device 102 is configured to forward one or more design suggestions 190 to the user interaction device 104 with the request response 122. For example, based upon the attributes 160 associated with the research request 116, the personal analytics module 118 is configured to review user data 130 from the user data source 124 and to apply a predictive model 192 to the user data 130 to create a design suggestion 190 related to the research request 116."
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the collaborative design based on prior feedback teaching of Hakimi with the using prior feedback that is relevant to make a design suggestion teaching of Lamarche because one would want to make use of previous feedback and ideas (as taught by Hakimi) to result in relevant suggestions. One would be motivated to do this because one would want to use knowledge to auto generate suggestions such that people would not have to think of suggestions that would not be relevant to prior accumulated feedback. For these reasons one would be motivated to modify Hakimi with Lamarche.
Per claims 2 and 12, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi further teaches evaluating the at least one design document and the product to identify one or more design characteristics comprises: determining a geometry of a computer-generated model representing at least one portion of the product in Fig 5 where a portion of the product is shown as the body of a vehicle and in par 057 where computer-aided design is taught: “he machine-assisted collaborative product design mobile application 510 also includes a metrics section 530 for each historical design. For example, a computer aided design (CAD) designer persona 540 is shown including a metrics graph 542, in which there is no corresponding bias score.”
Per claims 6 and 16, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi further teaches wherein identifying the one or more prior design feedback associated with the at least one component related to the product structure node of the product structure identified for the product comprises: applying a product design data model to the one or more design characteristics to identify a plurality of prior design feedback along with a confidence level for each prior design feedback, the product design data model being trained on a plurality of prior design feedback received during a plurality of prior product designs for a plurality of products, and the product design data model being trained to correlate one or more prior design feedback with the one or more design characteristics in par 052: “Using a machine learning algorithm, the simulation engine generates a series of scores from each persona for the design description. In some aspects of the present disclosure, the stakeholder simulation engine 314 also maintains representations of previous interactions with the user. These previous interactions may be iterative updates to the current design or may reflect past designs. In some aspects of the present disclosure, the stakeholder simulation engine 314 also learns about how the user responds to stakeholder feedback from these interactions and may tailor the framing of the feedback depending on the user's response to previous feedback.” For characteristics, par 053: “At block 454 of the product design process 450 of FIG. 4, the product design is analyzed to determine how the product design rates based on pre-configured design attributes. For example, at block 460, the current design is compared to past iterations of the design as well as other designs from the same user. At block 456, the product design attribute ratings are compared to each persona model. At block 458, products scores are updated. At block 470, a summary of visualizations is generated.”
Then, Hakimi teaches and selecting the one or more related prior design feedback from the plurality of related prior design feedback in par 062: “The stakeholder simulation engine 314 may also maintain representations of previous interactions with the user, as shown in FIG. 5. These previous interactions may be iterative updates to the current design or may reflect past designs. the stakeholder simulation engine 314 may also learn about how the user responds to stakeholder feedback from these interactions and may tailor the framing of the feedback depending on the user's response to previous feedback.”
Per claims 7 and 17, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 6 and 16, above. Hakimi further teaches wherein selecting the one or more prior design feedback from the plurality of prior design feedback comprises: selecting the one or more prior design feedback assigned a high priority level during the product design in par 065: “The method 600 may also include characterizing the user across a set of demographic dimensions. The method 600 may further include identifying a profile of another person with whom the user wants to build greater shared understanding.” With the teaching in par 062, the different dimensions that identify a profile of another person with whom the user wants to build greater shared understanding teaches assigned a high priority level during the product design.
Per claims 8 and 18, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 6 and 16, above. Hakimi further teaches wherein selecting the one or more prior design feedback from the plurality of prior design feedback comprises: identifying the one or more prior design feedback from the plurality of prior design feedback that is generated during a feedback conversation that takes longer than a priority feedback time period in par 052: “In some aspects of the present disclosure, the stakeholder simulation engine 314 also maintains representations of previous interactions with the user. These previous interactions may be iterative updates to the current design or may reflect past designs.”
Hakimi does not teach that takes longer than a priority feedback time period.
Lamarche teaches that takes longer than a priority feedback time period in par 069: “These persona journey maps 250 can provide a developmental history associated with the persona 162 over time. For example, during operation and as illustrated in FIG. 8, when the persona analytics module 118 updates a root persona 162 with a first set of real-time data 138, the persona analytics module 118 can create an updated persona 252 which is related to the root persona 164 via a tag or metadata 254 included in the updated persona 252.” Under a broadest reasonable interpretation, the developmental history teaches longer than a priority feedback time period because Lamarche teaches real-time data which teaches a priority feedback time period.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the collaborative design based on prior feedback teaching of Hakimi with the using prior feedback that is relevant to make a design suggestion teaching of Lamarche because one would want to make use of previous feedback and ideas (as taught by Hakimi) to result in relevant suggestions. One would be motivated to do this because one would want to use knowledge to auto generate suggestions such that people would not have to think of suggestions that would not be relevant to prior accumulated feedback. For these reasons one would be motivated to modify Hakimi with Lamarche.
Claim(s) 3 5, 13, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hakimi et al., US PGPUB 20230185997 A1 ("Hakimi") in view of LaMarche US PGPUB 20200160359 A1 ("Lamarche"), further in view of Deal, US PGPUB 20140101079 A1 (“Deal”)
Per claims 3 and 13, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi does not teach evaluating the at least one design document and the product to identify one or more design characteristics comprises: parsing a document metadata of the at least one design document.
Deal teaches collaborative problem solving for product design. See abstract.
Deal teaches evaluating the at least one design document and the product to identify one or more design characteristics comprises: parsing a document metadata of the at least one design document in par 0429: “In one particular embodiment, background material is brought to the attention of agents in dialogues by aligning metadata extracted from dialogues with metadata extracted from a background item. Machine-agent indexing includes file attributes and processing attributes that enable machines agents to download, open, and process archive items. In one particular embodiment, metadata includes agent appraisals of reference items.” Background item teaches under a broadest reasonable interpretation design document because in pars 010-011 item and background material teach information in the problem solving process which teaches a design document (material relevant to the design).
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the collaborative design based on prior feedback teaching of Hakimi with the parsing document metadata of a design document teaching of Deal because Deal teaches in par 051: “gents use metadata as a tool for identifying and retrieving information. Agent needs for metadata vary by the criteria they use to select information item. For example, a machine agent may seek to access a stored piece of information by data type or data size. Human agents may employ semantics or contextual cues as aids to associative retrieval. In one embodiment, human and machine participants and the MDPSA apply metadata to information articles for the purpose of retrieval. Examples of metadata include information-item creation name, keywords, data type, author name, thumbnail representations, creation date, agent name, contribution date and time, scoring, and number of times the information article was accessed.” This information would be relevant to the design process as it has keywords, contribution date, and author date, which give context to the design process. Therefore one would be motivated to find and include this information to have a more complete picture of the design document.
Per claims 5 and 15, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi does not teach wherein evaluating the at least one design document and the product to identify one or more design characteristics comprises: identifying a related electronic workspace associated with the product design within the electronic collaborative system; analyzing a workspace metadata associated with the related electronic workspace; and determining one or more design trends from the workspace metadata.
Deal teaches wherein evaluating the at least one design document and the product to identify one or more design characteristics comprises: identifying a related electronic workspace associated with the product design within the electronic collaborative system in par 0426: “Personal workspace content is archived with other instance materials when an individual decision-making activity has concluded. Group work spaces are provided for collaborative, problem-solving activities.”
Deal then teaches analyzing a workspace metadata associated with the related electronic workspace in par 0427: “The training creates an instance-specific catalog of relevant metadata that are characteristic of the problematic situation. Trained algorithms are used to analyze agent inputs to identify and cull redundant inputs from a forum as shown in FIG. 9. Algorithms are further trained by analyzing agent inputs to the problem solving process. While sifting agent inputs, catalog attributes are identified and additional attributes are catalogued.”
Deal then teaches and determining one or more design trends from the workspace metadata in par 0427: “In one embodiment, the catalog is used to identify information contained in agent inputs that is applicable to a particular child dialogue as specified by agents or by computational analyses. The identified, relevant input is inserted into the specified child dialogue as though it was contributed by a participating agent. The applicable information becomes part of the dialogue into which it was inserted, and is subject to subsequent agent discussion and selection.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the collaborative design based on prior feedback teaching of Hakimi with the parsing document metadata of a design document teaching of Deal because Deal teaches in par 051: “gents use metadata as a tool for identifying and retrieving information. Agent needs for metadata vary by the criteria they use to select information item. For example, a machine agent may seek to access a stored piece of information by data type or data size. Human agents may employ semantics or contextual cues as aids to associative retrieval. In one embodiment, human and machine participants and the MDPSA apply metadata to information articles for the purpose of retrieval. Examples of metadata include information-item creation name, keywords, data type, author name, thumbnail representations, creation date, agent name, contribution date and time, scoring, and number of times the information article was accessed.” This information would be relevant to the design process as it has keywords, contribution date, and author date, which give context to the design process. Therefore one would be motivated to find and include this information to have a more complete picture of the design document.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hakimi et al., US PGPUB 20230185997 A1 ("Hakimi") in view of LaMarche US PGPUB 20200160359 A1 ("Lamarche"), further in view of Johnson et al., US PGPUB 20040225475 A1 (“Johnson”).
Per claims 9 and 19, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi does not teach generating the at least one recommendation for the product design comprises: evaluating the one or more prior design feedback and the prior design decision to determine one or more design risks associated with the product design; and offering the recommendation for the product design to address at least one design risk of the one or more design risks based on the prior design decision.
Johnson teaches a method for performing failure mode. See abstract.
Johnson teaches generating the at least one recommendation for the product design comprises: evaluating the one or more prior design feedback and the prior design decision to determine one or more design risks associated with the product design in par 023: “FIG. 3 is a block diagram of an exemplary embodiment of an overall process for performing FMEA during product design and field service. The design team members may be located at more than one physical location and application software located on the host system 104 is utilized to perform the collaboration in order to create a consensus FMEA for the product. The design team members are logged on to user systems 102 that are connected, via the network 106, to the host system 104 that includes the FMEA collaboration application software as well as access to the FMEA database. Referring to step 302 in FIG. 3, each design team member, or product expert, independently identifies and enters into the computer a list of different fault modes 206 that could occur.” Under a broadest reasonable interpretation the entries in the FMEA database are feedback related to design risks.
Then, Johnson teaches and offering the recommendation for the product design to address at least one design risk of the one or more design risks based on the prior design decision in par 024: “Once consensus is reached, or the FMEA owner has made a decision in the event that consensus cannot be reached, the FMEA owner enters a new entry into the consensus FMEA database. At step 306 in FIG. 3, corrective actions 228 are designed for the highest RPN 232 items in the consensus FMEA. The RPN 232 can be a number derived by the system as the product of severity and occurrence indexes. For purposes such as the design of monitoring and measurement systems, an extended RPN 232, including product detectability and data availability index values can also be used. The corrective actions 228 are added to the consensus FMEA database. The corrective actions 228 can include improvement of design such as features built into the product or repair procedures. The corrective action 228 field in the consensus FMEA may be updated at a later time to make a design improvement or to suggest a manufacturing process corrective action 228.” The corrective actions teach recommendation for the … to address at least one design risk.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the collaborative design teaching of Hakimi with the design risk teaching of Johnson because Johnson teaches in par 003 that: “A typical FMEA report can contain hundreds of entries. Utilizing a paper process for generating a FMEA report can make it difficult for the FMEA report to be disseminated, maintained and updated.” This problem exists in the art, and Johnson’s teaching in par 0014 is the motivation to combine: “an electronic interface to a FMEA database is made available on a web-site, along with an on-line dialog that extracts information from the product experts (e.g., the original design engineers and experienced field engineers). The information from all the product experts is reconciled and provided for dissemination, review and subsequent updating of the FMEA database.” As Johnson’s teaching is for a database that allows for ideas and solutions to be disseminated, one would be motivated to modify Hakimi with Johnson so that ideas would be shared more effectively.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hakimi et al., US PGPUB 20230185997 A1 ("Hakimi") in view of LaMarche US PGPUB 20200160359 A1 ("Lamarche"), further in view of Lai et al., US PGPUB 20240235872 A1 (“Lai”).
Per claims 10 and 20, which are similar in scope, Hakimi and Lamarche teach the limitations of claims 1 and 11, above. Hakimi does not teach generating the at least one recommendation for the product design comprises: generating a natural language summary for the one or more prior design feedback and the prior design decision.
Lai teaches providing a summary for a virtual meeting. See abstract.
Lai teaches generating the at least one recommendation for the product design comprises: generating a natural language summary for the one or more prior design feedback and the prior design decision in par 088: ‘Such one or more models may be trained to take as input labeled audio files or utterances, and output one or more candidate transcriptions of the audio file or utterance. In some embodiments, the summary generator system may pre-process the received audio input for input into the neural network, e.g., to filter out background noise and/or normalize the signal, or such processing may be performed by the machine learning model. In some embodiments, in generating the candidate transcriptions, the voice processing application may analyze the received audio signal to identify phonemes (i.e., distinguishing units of sound within a term) within the signal, and utilize statistical probability techniques to determine most likely next phonemes in the received query. For example, the model may be trained on a large vocabulary of words, to enable the model to recognize common language patterns and aid in the ability to identify candidate transcriptions of voice input. Additionally, or alternatively, transcription of the audio signal may be achieved by external transcription services (e.g., Amazon Transcribe by Amazon, Inc. of Seattle, WA and Google Speech-to-Text by Google, Inc. of Mountain View, CA). The transcription of audio is discussed in more detail in U.S. patent application Ser. No. 16/397,004, filed Apr. 29, 2019, which is hereby incorporated by reference herein in its entirety.” See pars 089-090. See also par 130 where this is for users who work on the same task simultaneously such as product designs. Under a broadest reasonable interpretation, Lai teaches prior feedback and decision because Lai teaches summarizing a meeting of product design, and Lai’s teaching could occur during the prior feedback and decision period.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the product design feedback steps of Hakimi with the summarizing of prior meeting teaching of Lai because Lai teaches in par 003: “With so much time being spent participating in remote virtual meetings, it is likely that each user has, at one time or another, experienced a certain break in the presence (BIP). For example, any sudden decrease in data rate or increase in communication delay can adversely affect the users' experience (e.g., interrupt a video stream), which may cause a BIP event that can be detrimental to the user's experience and interfere with the goals of the collaborative meeting.” As a meeting may not happen continuously for everyone, Lai’s teaching assists the collaborative process through providing a summary despite a BIP. As this would help a collaborative process one would be motivated to modify Hakimi with Lai.
Therefore, claims 1-3, 5-12, and 14-20 are rejected under 35 USC 103.
Response to Remarks:
35 USC 101
Applicant argues:
101 rejection of the record for at least the following reasons.
On pages 3 and 4 of the Office Action, the Examiner asserts that claims 1 and 11 constitute a method of organizing human activity, specifically a method of managing personal behavior or relationships or interactions between people, because the claims allegedly define the specifics of collaborating between people to arrive at a recommendation based on decisions made by people.
The Applicant submits that the claims as amended are directed to a technical solution that addresses a problem necessarily rooted in computer technology. The Examiner's assertion that the claims arrive at a recommendation based on decisions made by people removes the technical aspects from the claimed solution. The Applicant submits that the claims as amended do not actually recite the judicial exception. The MPEP at 2106.04, citing the Supreme Court, states that "[t]he 'directed to' inquiry, therefore, cannot simply ask whether the claims involve a patent- ineligible concept, because essentially every routinely patent-eligible claim involving physical products and actions involves a law of nature and/or natural phenomenon". See Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1335, 118 USPQ2d 1684, 1688 (Fed. Cir. 2016). It cautions that Examiners should be careful to distinguish claims that recite an exception (which require further eligibility analysis) and claims that merely involve an exception (which are eligible and do not require further eligibility analysis).
In the application as filed, the Applicant explains that in collaborative design projects, multiple users may collaborate to generate information that can be useful during a current design process, such as historical user feedback and/or messages. However, due to the unstructured format of such feedback and complexity in identifying similarities between products, it can be challenging to identify when user feedback for a different product may be relevant and useful to a current design process (see e.g., paragraphs [0049]-[0050], application as published). To distill the claimed features down to merely "arriv[ing] at a recommendation based on decisions made by people" disregards the technical steps recited by the amended claims to solve the technical problem.
The claimed features are not directed at a method of managing personal behavior or relationships or interactions between people, and should not be categorized as subject matter related to managing personal behavior or relationships or interactions between people at all or social activities, teaching, or following rules or instructions. Rather, amended claims 1 and 11 recite a technical solution directed at "automatically generating at least one recommendation for improving a product design within an electronic collaborative system having a plurality of electronic workspaces within which a different collaborative design process takes place".
Applicant has described here what is described in the specification and claims, and identified by Examiner: a human design process that uses computers in an apply it fashion. Nowhere has Applicant identified a problem necessarily rooted in computer technology. The claims are not distilled, that is inaccurate. The abstract ideas are, using the exact claim language minus the additional elements, describing human activities with some applied broad scope technology that is not a practical application. Applicant’s arguments have been considered but actually reinforce the finding by Examiner, as Applicant has essentially agreed with Examiner on the human activity finding:
“the Applicant explains that in collaborative design projects, multiple users may collaborate to generate information that can be useful during a current design process, such as historical user feedback and/or messages”
Examiner agrees with Applicant that this is a collaborative design process. Understood that this is people collaborating, a human activity. Feedback is people responding. Messages – people communicating. All of this is human activity.
Applicant has referred to the technical steps to solve a technical problem, but the claims are nearly entirely human activity, which is to say, under a broadest reasonable interpretation, human activity. Therefore the abstract idea is affirmed and the arguments are unpersuasive.
Applicant argues:
For completeness, in the case that the Examiner disagrees with the Applicant's above analysis under the First Prong of Step 2A, the Applicant submits, without acquiescing to the Examiner's rejection of the record, that the claimed subject matter is directed to patent-eligible subject matter under the Second Prong of Step 2A.
On page 4 of the Office Action, the Examiner asserts that the claims do not recite additional elements that integrate the judicial exception into a practical application. Specifically, the Examiner asserts that the additional elements amount to applying a generic computer or other machinery to the alleged abstract ideas.
The Applicant disagrees with the Examiner's analysis under Step 2A Prong 2 of the 35 U.S.C. § 101 rejection of the record for at least the following reasons.
As stated in MPEP 2106.04(d)(1), one way to demonstrate that an alleged judicial exception is integrated into a practical application is when the claimed invention improves the functioning of a computer or improves another technology or technical field. The Applicant submits that the claimed technology is directed to an improvement in the field of product designs within electronic collaborative systems.
The application as published discusses at paragraphs [0049] and [0050] technical problems associated with the use of collaborative systems during a product design process:
[0049] A collaborative system can enable collaboration between multiple users during a product design process. A collaborative design project typically involves various design documents for a product being developed. For complex products, multiple levels of design documents and multiple design documents for various components may be involved.
Multiple users may collaborate to solve various design issues during a product design
process.
[0050] Historical user feedback and/or messages between users during the collaborative product design process may include information that can be useful during a current design process. It can be challenging to locate the relevant information in the historical user feedback. The user feedback can include different formats of unstructured data (e.g., user input comments, item status, outcome descriptions, ticket status etc.). The user feedback can be related to different products and in some cases the user feedback for a different product may not be useful to the current design process/product. It can be challenging to identify cases in which the user feedback for a different product may be relevant and useful
to a current design process/product.
Amended claims 1 and 11 are directed to automatically generating recommendation for improving a product design within an electronic collaborative system. For example, in amended claims 1 and 11, a product structure defining hierarchical relationships between components of a product is identified. At least some design characteristics are defined from the product structure and used to identify related electronic workspaces. Prior design feedback associated with at least one component related to a product structure node of the product structure can then be identified, and a relevance level of the prior design feedback can be determined. The claimed features then require that at least one recommendation for the product design be generated based on the relevance level. Accordingly, amended claims 1 and 11 provide a practical application for improving a product design within the electronic collaborative system.
Accordingly, the Applicant disagrees with the Examiner's analysis under Step 2A Prong 2, and in view of the foregoing, the Applicant submits that the claimed subject matter, as a whole, is integrated into a practical application.
Step 2B: The claimed subject matter, as a whole, amounts to significantly more than the judicial exception.
Again, for completeness, in the case that the Examiner disagrees with the Applicant's above analysis under the Second Prong of Step 2A, the Applicant submits, without acquiescing to the Examiner's rejection of the record, that the claimed subject matter is directed to patent-eligible subject matter under Step 2B.
On pages 4 to 5 of the Office Action, the Examiner asserts that the additional elements do not amount to significantly more to the alleged judicial exception for the same reasons as there is allegedly not a practical application.
The Applicant submits that the elements of amended claims 1 and 11, considered both individually and as an ordered combination, are sufficient to ensure that the claims as a whole amount to significantly more than the alleged exception itself under Step 2B for at least the same reasons as discussed above under Prong 2 of Step 2A. In particular, the amended claims provide an improvement to the field of product design within an electronic collaborative system.
In view of at least the foregoing, it is submitted that independent claims 1 and 11 are directed to patent eligible subject matter and the subject matter of dependent claims 2-10 and 12-20 is also patent eligible at least due to their dependencies from independent claims 1 and 11, respectively. Accordingly, withdrawal of the rejections raised under 35 U.S.C. § 101 is requested.
Applicant cites paragraphs 49 and 50 but these are descriptions of communications difficulties between people with no relevance to technical solutions to technical problems. Applicant is advised as to what a technical solution to a technical problem is per the guidance:
If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide 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. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art. For example, in McRO, the court relied on the specification’s explanation of how the particular rules recited in the claim enabled the automation of specific animation tasks that previously could only be performed subjectively by humans, when determining that the claims were directed to improvements in computer animation instead of an abstract idea. McRO, 837 F.3d at 1313-14, 120 USPQ2d at 1100-01. In contrast, the court in Affinity Labs of Tex. v. DirecTV, LLC relied on the specification’s failure to provide details regarding the manner in which the invention accomplished the alleged improvement when holding the claimed methods of delivering broadcast content to cellphones ineligible. 838 F.3d 1253, 1263-64, 120 USPQ2d 1201, 1207-08 (Fed. Cir. 2016).
MPEP 2106.05(a).
Here, there is no improvement described, implicitly or otherwise. The problems described in pars 049-050 are problems of organizing human activity, specifically, messages and other communications about a design project. While it is conceivable that there could be technical problems in doing this, they are no described here, and Applicant is limited to the evidence submitted (here, the original disclosure).
Therefore, for these reasons the arguments are unpersuasive and the rejection is maintained.
35 USC 103
The Applicant submits that the cited references, whether alone or in combination, fail to
describe or suggest at least all the features of each of amended independent claims 1 and 11. Specifically, the cited references do not describe or suggest, at least, identifying a product structure for the product, the product structure defining one or more hierarchical relationships between one or more components of the plurality of components of the product, and defining at least one design characteristic of the one or more design characteristics from the product structure; identifying one or more related electronic workspaces of other collaborative design processes associated with the one or more design characteristics identified from the at least one design document and the product; from the one or more related electronic workspaces, identifying one or more prior design feedback associated with at least one component related to a product structure node of the product structure identified for the product, the one or more prior design feedback comprising one or more user feedback inputs received during the other collaborative design processes conducted within the one or more related electronic workspaces-in respect of a different product design; determining a relevance level of the one or more prior design feedback by evaluating at least a prior design process and a prior design decision resulting from the one or more prior design feedback, wherein determining the relevance level of the one or more prior design feedback comprises: analyzing the one or more prior design feedback to identify a set of key design contributions to the prior design decision, and assigning a high priority level to the one or more prior design feedback identified to be the set of key design contributions; and generating the at least one recommendation for the product design based at least on the relevance level of the prior design process and the prior design decision, as required in each of independent claims
1 and 11.
Applicant’s argument amounts to a general allegation of patentability because Applicant has not specifically identified where the rejection is incorrect in citing Hakimi in view of secondary arts. See 37 C.F.R. 1.111. “A general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references does not comply with the requirements of this section.” While Applicant then goes on to describe Hakimi and Lamarche in general terms as different from Applicant’s claims, this is insufficient as these references were cited against specific claim teachings.
Hakimi is directed to a system for machine-assisted collaboration using simulated stakeholders. Hakimi explains that a conventional product design process involves multiple stakeholders that engage in a product review process to provide a final product. The differences between the stakeholders can cause friction and disagreements. For example, stakeholders may prioritize different design improvements based on their position in the design process (see e.g., paragraph [0002], Hakimi). A product designer may propose a new design that prioritizes innovation and aesthetics, while an engineer may prioritize feasibility in manufacturing. A sales team member may further propose a new design that prioritizes features that have previously sold well or are based on consumer requests (see e.g., paragraph [0003], Hakimi). As a result, one can feel slighted if their unique insights are lost in the product design process.
In the Hakimi system, detailed personas are used to simulate each stakeholder and their feedback on potential designs, allowing the user to anticipate and better understand the needs of their collaborators (see e.g., paragraph [0021], Hakimi). Through the feedback of these simulated personas, each stakeholder is able to understand how their colleagues perceive potential product features both as individuals and in relation to others (see e.g., paragraph [0022], Hakimi). As described at least with respect to FIG. 4, the Hakimi system receives an input related to the potential product in the form of a written description, image and/or speech (see e.g., paragraph [0052], Hakimi). The Hakimi system then assesses the design based at least on various persona models which were manually selected and configured by the user (see e.g., paragraphs [0048]- [0051], Hakimi). Different metrics, such as clarity score, enthusiasm score, bias score, and more, are then reported for each stakeholder persona (see e.g., paragraph [0054], Hakimi).
While Hakimi discusses receiving feedback from various simulated personas as part of a design process, the Hakimi system targets a different technical problem as well as offers a different solution than the claimed features. The Applicant explains in the application as filed that a collaborative design project typically involves various design documents with multiple users collaborating to solve various design issues. The Applicant explains that it can be challenging to locate relevant information in the historical user feedback, which can include different formats of unstructured data (e.g., user input comments, item status, outcome descriptions, ticket status, etc.). It can also be challenging to identify cases in which the user feedback for a different product may be relevant and useful to a current design process/product. The Hakimi system, on the other hand, involves receiving an input that describes a potential product, which is then tested against various simulated persona models.
The Applicant further submits that LaMarche fails to address the deficiencies of Hakimi.
LaMarche is directed to a user-experience development system including a persona development device configured to exchange information with a user interaction device to allow real-time development of a user persona. The user interaction device is configured as a central device that can facilitate learning from research conducted by various teams (see e.g., paragraph [0024], LaMarche). At the cited paragraphs, LaMarche describes the persona development device receiving a research request from a user interaction device, the research request including keywords or attributes relating to a particular product and a persona believed to be associated with the product (see e.g., paragraph [0044], LaMarche). A persona analytics module is then
configured to extract keywords or attributes from the research request, which can be used to perform a search in a persona database to determine if corresponding attributes exist as part of a persona stored there (see e.g., paragraph [0045], LaMarche).
In view of the foregoing, the Applicant submits that Hakimi and LaMarche, whether alone or in combination, fail to disclose the subject matter of independent claims 1 and 11, and therefore the subject matter of independent claims 1 and 11 is new and non-obvious in view of the cited references. Further, due at least to the dependency from independent claims 1 and 11, it is submitted that the subject matter of claims 2-10 and 12-20 is also new and non-obvious in view of the cited art.
Withdrawal of the rejections raised under 35 USC § 103 is requested.
Applicant’s argument, that Hakimi addresses a “different technical problem” is irrelevant. Nowhere does Applicant cite legal or guidance support that a prior art, which is by the way in the same field of endeavor, that if Hakimi is addressing a different technical problem that it could also not teach the claims. Here none of the arguments specifically show how Hakimi in view of Lamarche do not teach the claim limitations because they do not address the Office action. They only go through and find where Hakimi and Lamarche have some differences from the claims, not what was cited against the claims. This is not persuasive and therefore the rejection stands.
Prior Art Considered Relevant
The following prior art is considered relevant to Applicant’s disclosure but is not relied upon in the rejection:
Nath et al., US 20240020446 A1, teaches in pars 026 and 028 using messages from AI agents to form a collaborative conversation about product design.
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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD W. CRANDALL whose telephone number is (313)446-6562. The examiner can normally be reached M - F, 8:00 AM - 5:00 PM.
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, Anita Coupe can be reached at (571) 270-3614. 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.
/RICHARD W. CRANDALL/ Primary Examiner, Art Unit 3619
Prosecution Insights