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 January 28, 2026.
Claims 1-20 are pending and have been examined.
Election/Restrictions
Applicant’s election without traverse of claims 1-20 in the reply filed on January 28, 2026 is acknowledged.
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-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 providing a recommendation for a product design, the method comprising: receiving at least one design document related to a product; evaluating the at least one design document to identify one or more design characteristics associated with at least one of the product and a design process related to the product; identifying one or more related prior design feedback associated with the one or more design characteristics from a historical design data storage, the one or more related 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; evaluating the one or more related prior design feedback and a related prior design decision resulting from the one or more related prior design feedback to determine a relevance level of the related prior design decision for the product design; and generating the recommendation for the product design based at least on the relevance level of the related prior design decision.
Claim 11:
providing a recommendation for a product design, 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; evaluate the at least one design document to identify one or more design characteristics associated with at least one of the product and a design process related to the product; identify, from the design data storage, one or more related prior design feedback associated with the one or more design characteristics; evaluate the one or more related prior design feedback and a related prior design decision resulting from the one or more related prior design feedback to determine a relevance level of the related prior design decision for the product design; and generate the recommendation for the product design based at least on the relevance level of the related 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 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 a collaborative system
Claim 11 recites:
A system for
within a collaborative system
a design data storage operable to store
And a processor configured to
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. 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-10 and 12-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-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 method for providing a recommendation for a product design within a collaborative system, the method comprising: receiving at least one design document related to a product 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 to identify one or more design characteristics associated with at least one of the product and a design process related to the product 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).
Hakimi then teaches identifying one or more related prior design feedback associated with the one or more design characteristics from a historical design data storage, the one or more related 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 (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 evaluating the one or more related prior design feedback and a related prior design decision resulting from the one or more related prior design feedback to determine a relevance level of the related prior design decision for the product design; and generating the recommendation for the product design based at least on the relevance level of the related prior design decision.
Lamarche teaches user experience development based on persona prototypes . See par 009.
Lamarche teaches evaluating the one or more related prior design feedback and a related prior design decision resulting from the one or more related prior design feedback to determine a relevance level of the related prior design decision for the product design 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 recommendation for the product design based at least on the relevance level of the related 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 wherein evaluating the at least one design document 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 related prior design feedback associated with the one or more design characteristics from the historical design data storage comprises: applying a product design data model to the one or more design characteristics to identify a plurality of related prior design feedback along with a confidence level for each related 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 related prior design feedback from the plurality of related prior design feedback comprises: selecting the one or more related 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 related prior design feedback from the plurality of related prior design feedback comprises: identifying the one or more related prior design feedback from the plurality of related prior design feedback that is generated during a feedback conversation 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 wherein evaluating the at least one design document 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 wherein evaluating the at least one design document 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 to identify one or more design characteristics comprises: identifying a workspace associated with the product design within the collaborative system; analyzing a workspace metadata associated with the workspace; and determining one or more design trends from the workspace metadata.
Deal teaches wherein evaluating the at least one design document to identify one or more design characteristics comprises: identifying a workspace associated with the product design within the 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 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) 4 and 14 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 De Biswas, US PGPUB 20130144566 A1 (“Biswas”).
Per claims 4 and 14, 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 to identify one or more design characteristics comprises: identifying a product structure for the product, the product structure defining one or more hierarchical relationships between the product and one or more subcomponents of the product.
Biswas teaches a real time collaborative design platform. See abstract.
Biswas teaches wherein evaluating the at least one design document to identify one or more design characteristics comprises: identifying a product structure for the product in par 0110: “The third-party user interface may therefore include a depiction of the 3D model space and/or version selection as described herein along with a separate region for component editing, analysis, and the like. To the extent that component data in the 3D model space may be stored in a different format than that required by the third-party model editor, format transformation may be performed in substantially real-time as component(s) are downloaded from and/or uploaded to the 3D model space from the third-party user interface.”
Biswas then teaches the product structure defining one or more hierarchical relationships between the product and one or more subcomponents of the product in par 0110: “in an embodiment, a user interface may include a first portion that represents information, including graphic or hierarchical information about one or more sub-components in the 3D model space, and a second portion for editing the one or more sub-components with a model editing software that is separate from the 3D model space, wherein the user can control downloading of the one or more sub-components from the 3D model space for editing with the model editing software and uploading of a new version of the one or more sub-components from the model editing software to the 3D model space.”
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 collaboration based on feedback of Hakimi with the structure and sub component teaching of Biswas because one would be motivated to have actual design details included in the product collaboration, which is described in Hakimi (design document can be image), so that the details can be investigated. This would make collaboration more effective. For these reasons one would be motivated to modify Hakimi with Biswas.
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 wherein generating the recommendation for the product design comprises: evaluating the one or more related prior design feedback and the related 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 related prior design decision.
Johnson teaches a method for performing failure mode. See abstract.
Johnson teaches wherein generating the recommendation for the product design comprises: evaluating the one or more related prior design feedback and the related 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 related 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 wherein generating the recommendation for the product design comprises: generating a natural language summary for the one or more related prior design feedback and the related prior design decision.
Lai teaches providing a summary for a virtual meeting. See abstract.
Lai teaches wherein generating the recommendation for the product design comprises: generating a natural language summary for the one or more related prior design feedback and the related 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-20 are rejected under 35 USC 103.
Prior Art Considered Relevant
The following prior art is considered relevant to Applicant’s disclosure but is not relied upon in the above rejection:
UXPin Studio Blog, 12 Design Collaboration Tools for Fast and Organized Work [online], available at: < https://www.uxpin.com/studio/blog/design-collaboration-tool/ > published on July 26th, 2023.
Teaches several design collaboration tools.
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