Detailed Action
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Information Disclosure Statement
The information disclosure statement filed on October 25, 2023 complies with the provisions of 37 C.F.R. § 1.97, 1.98, and MPEP § 609, and therefore has been placed in the application file. The information referred to therein has been considered as to the merits.
Claim Objections
The Office objects to claims 53 and 59 for having the following informalities:
The present simple tense of “further comprises” and “further causes” in respective claims 53 and 59 disagrees with the present continuous tense of each claim. Therefore, the words “comprises” and “causes” must be changed to “comprising” and “causing.” Alternatively, claim 59 may be corrected by changing the claim to the present simple tense (e.g., “The non-transitory computer readable medium of claim 58, wherein the instructions further cause[[s]] …”).
Appropriate correction is required.
Claim Rejections – 35 U.S.C. § 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.
I. Claims 43–50 include embodiments of non-statutory subject matter (software per se).
Claims 43–50 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to nonstatutory subject matter. The claim fails to fall within any of the four statutory categories of invention: process, machine, manufacture, or composition of matter.
Claim 43 recites a “scenario modeler” comprising components including “a control program running on a computer device.” Under the broadest reasonable interpretation (BRI), the terms “scenario modeler” and “control program” encompass the software code or set of instructions independent of execution or storage on a physical medium. Software expressed merely as code or instructions, detached from any tangible medium or machine execution, represents an idea lacking physical embodiment. Such “software per se” does not fall into the statutory categories of machine, manufacture, or composition of matter, which require a physical or tangible form. See MPEP § 2106.03.
While claim 43 also recites the control program “running on a computer device,” the computer device itself is not an element of the claimed scenario modeler. Therefore, since the BRI of claim 43 covers non-statutory software per se embodiments, the claim is rejected under 35 U.S.C. § 101.
Claims 44–50 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to nonstatutory subject matter for the reasons set forth above with respect to claim 43, from which claims 44–50 directly or indirectly depend. Claims 44–50 incorporate the “scenario modeler” including the “control program” limitation from claim 43, the BRI of which includes non-statutory software per se.
II. Claims 43–61 and 63 fail to recite significantly more than a judicial exception of 35 U.S.C. § 101.
Claims 43–61 and 63 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 43
Claim 43 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a scenario modeler comprising an input, a graphical user interface (GUI), and a control program. The control program is operable to display scenario information, receive inputs defining activities for hypothetical persons, and generate a scenario data set.
This judicial exception is identified as the abstract idea of defining and documenting a scenario based on collected user information. This concept involves organizing information (interview data, user inputs defining activities) and generating a structured output (scenario data set), which falls within the “certain methods of organizing human activity” grouping, see MPEP § 2106.04(a)(2) (subsection II.), specifically related to managing relationships or interactions between people in a design or research context. See MPEP § 2106.04(a)(2) (subsection (II.)(C.)). The steps of displaying information, receiving user inputs defining activities, and generating a data set based on those inputs are fundamental activities related to organizing human interactions and thought processes involved in defining hypothetical situations based on gathered data.
The claimed invention may also be said to fall within the “mental processes” grouping, since, apart from the graphical user interface, the entire process may be performed mentally, or by a human using pen and paper. MPEP § 2106.04(a)(2) (subsection III.).
This judicial exception is not integrated into a practical application because the additional elements simply recite generic computer components and functions used to implement the abstract idea, which are tantamount to mere instructions to apply the judicial exception. See MPEP § 2106.05(f). The claim recites an input for receiving data, a GUI for displaying information and receiving inputs, and a control program running on a computer device. These elements are recited at a high level of generality and perform only their basic functions of receiving, processing, displaying, and generating data. The claim does not specify any particular manner of displaying information, receiving inputs, or generating the data set that improves computer functionality or provides a specific technological solution beyond the automation of the abstract idea itself. The claim as a whole merely provides instructions to apply the abstract idea of defining and documenting a scenario using generic computer components.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements consist of generic computer components (input, GUI, computer device, control program) performing generic functions (receiving data, displaying information, receiving inputs, generating a data set). These generic functions amount to no more than mere instructions to apply the abstract idea using a computer. The steps of receiving interview data and generating a scenario data set constitute insignificant pre-solution and post-solution activity, respectively, that are necessary or conventional for any use of the abstract idea. The claim provides no specific technological improvement or particular application beyond the abstract idea itself. Considered individually and in combination, the additional elements fail to transform the abstract idea into a patent-eligible application.
Claim 44
Claim 44 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 44 depends from claim 43 and adds the limitation that the information about each interviewee comprises interview values corresponding to respective responses to a plurality of interview questions. The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43.
This judicial exception is not integrated into a practical application. The added limitation merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation does not add meaningful limits to the abstract idea or integrate it into a specific practical application beyond the generic computer implementation recited in claim 43. This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The added limitation specifies the content of the data being processed but does not alter the generic nature of the computer implementation or provide an inventive concept beyond the abstract idea recited in claim 43. It remains mere instructions to apply the abstract idea using generic computer components to process a specific type of data.
Claim 45
Claim 45 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 45 depends from claim 43 and adds the limitation that the control program is further operable to receive, via the GUI, a name of a scenario. The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43.
This judicial exception is not integrated into a practical application. The added limitation merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation does not add meaningful limits to the abstract idea or integrate it into a specific practical application beyond the generic computer implementation recited in claim 43. This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The added limitation specifies the content of the data being processed but does not alter the generic nature of the computer implementation or provide an inventive concept beyond the abstract idea recited in claim 43. It remains mere instructions to apply the abstract idea using generic computer components to process a specific type of data.
Claim 46
Claim 46 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 46 depends from claim 45 and adds the limitation that the plurality of activities defines the scenario. The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43.
This judicial exception is not integrated into a practical application. The added limitation merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation does not add meaningful limits to the abstract idea or integrate it into a specific practical application beyond the generic computer implementation recited in claim 43. This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The added limitation specifies the content of the data being processed but does not alter the generic nature of the computer implementation or provide an inventive concept beyond the abstract idea recited in claim 43. It remains mere instructions to apply the abstract idea using generic computer components to process a specific type of data.
Claim 47
Claim 47 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 47 depends from claim 43 and adds the limitation that the scenario data set is in the form of a disk file or part of a database. The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43.
This judicial exception is not integrated into a practical application. Specifying the storage format (disk file or database) for the generated data set is insignificant post-solution activity. It merely names storage media and does not impose a meaningful limit on the abstract idea or integrate it into a specific practical application beyond storing the result of the abstract process. Storage is a fundamental aspect of computers, and fundamental computer features do not transform judicial exceptions into eligible claims.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. Storing data in a file or database is a generic computer function. This limitation fails to provide an inventive concept beyond the abstract idea recited in claim 43.
Claim 48
Claim 48 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 48 depends from claim 43 and adds a second abstract idea to the abstract idea of claim 43, the second abstract idea being a mental process of determining scenarios with steps, evaluating steps for key interactions based on requirements/success criteria, and documenting scenarios showing common/unique needs. The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43, and further adds related abstract analysis and documentation steps. These added steps are further instances of organizing human activity and mental processes. A claim to a combination of two or more abstract ideas is still directed to an abstract idea. See MPEP § 2106.04 (subsection (II.)(B.)).
This judicial exception is not integrated into a practical application. The added limitations describe further abstract steps of analysis and documentation performed by the control program. These steps, like those in claim 43, are implemented using generic computer functions and do not improve computer technology or represent a specific practical application beyond automating the abstract analysis and documentation process itself.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. Determining steps, evaluating interactions based on criteria, and documenting needs are abstract mental or organizational tasks. Implementing these on a computer amounts to mere instructions to apply these further abstract concepts. They do not provide an inventive concept beyond the abstract idea recited in claim 43.
Claim 49
Claim 49 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 49 depends from claim 48 and adds the limitation that the generated scenario data set further comprises the key interactions, the series of steps, and the requirements information. The claim recites the abstract idea of defining, analyzing, and documenting a scenario based on collected user information, as explained for claims 43 and 48.
This judicial exception is not integrated into a practical application. The added limitation merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation does not add meaningful limits to the abstract idea or integrate it into a specific practical application beyond the generic computer implementation recited in claim 43. This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The added limitation specifies the content of the data being processed but does not alter the generic nature of the computer implementation or provide an inventive concept beyond the abstract idea recited in claim 43. It remains mere instructions to apply the abstract idea using generic computer components to process a specific type of data.
Claim 50
Claim 50 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 50 depends from claim 43 and adds the limitation that the hypothetical persons are personas (data models representing a type of human). The claim recites the abstract idea of defining and documenting a scenario based on collected user information, as explained for claim 43.
This judicial exception is not integrated into a practical application. The added limitation defines a term (“hypothetical persons”) used in the context of the abstract scenario definition process by linking it to another abstract concept (“personas” as data models). This definition does not add any concrete element or process step that integrates the abstract idea into a practical application beyond clarifying the terminology used within the abstract framework.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. Defining the hypothetical persons as personas does not add an inventive concept beyond the abstract idea recited in claim 43.
Claim 51
Claim 51 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a method comprising receiving interview data, displaying scenario information, receiving inputs defining a scenario name and activities for hypothetical persons, and generating a scenario data set.
This judicial exception is identified as the abstract idea of defining and documenting a scenario based on collected user information. This concept involves organizing information (interview data, user inputs defining activities) and generating a structured output (scenario data set), which falls within the “certain methods of organizing human activity” grouping, see MPEP § 2106.04(a)(2) (subsection II.), specifically related to managing relationships or interactions between people in a design or research context. See MPEP § 2106.04(a)(2) (subsection (II.)(C.)). The steps of displaying information, receiving user inputs defining activities, and generating a data set based on those inputs are fundamental activities related to organizing human interactions and thought processes involved in defining hypothetical situations based on gathered data.
The claimed invention may also be said to fall within the “mental processes” grouping, since, apart from the graphical user interface, the entire process may be performed mentally, or by a human using pen and paper. MPEP § 2106.04(a)(2) (subsection III.).
This judicial exception is not integrated into a practical application because the additional elements simply recite generic computer components and functions used to implement the abstract idea, which are tantamount to mere instructions to apply the judicial exception. See MPEP § 2106.05(f). The claim recites an input for receiving data, a GUI for displaying information and receiving inputs, and a control program running on a computer device. These elements are recited at a high level of generality and perform only their basic functions of receiving, processing, displaying, and generating data. The claim does not specify any particular manner of displaying information, receiving inputs, or generating the data set that improves computer functionality or provides a specific technological solution beyond the automation of the abstract idea itself. The claim as a whole merely provides instructions to apply the abstract idea of defining and documenting a scenario using generic computer components.
The limitation concerning the format of the data as “interview questions” and including the “name” of a scenario as one of the inputs merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements consist of generic computer components (input, GUI, computer device, control program) performing generic functions (receiving data, displaying information, receiving inputs, generating a data set). These generic functions amount to no more than mere instructions to apply the abstract idea using a computer. The steps of receiving interview data and generating a scenario data set constitute insignificant pre-solution and post-solution activity, respectively, that are necessary or conventional for any use of the abstract idea.
Likewise, the limitations concerning the format of the data as “interview questions” and including the “name” of a scenario as one of the inputs merely provides a further description of the data itself. Limitations to “particular content” alone are never sufficient to transform an abstract idea into an eligible invention, because “information as such is an intangible.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). This limitation represents data gathering or organization inherent in the abstract idea itself.
The claim provides no specific technological improvement or particular application beyond the abstract idea itself. Considered individually and in combination, the additional elements fail to transform the abstract idea into a patent-eligible application.
Claim 52–56
Claims 52–56 fail to transform their parent claim 51 into a practical application, or add significantly more, for the same reasons that corresponding claims 46, 48, 49, 47, and 50 (in that order) failed to transform their respective parent claim 43 into an eligible invention. The reasons set forth in the rejections of those claims are hereby reincoproated by reference, as applied to their corresponding sister claims 52–56.
The only other difference between these claims and the ones above is that these claims are considered to be a “process” at step one of the 35 U.S.C. § 101 analysis. However, because the results of steps 2A and 2B are the same, these claims are deemed ineligible for the same reasons.
Claims 57–61 and 63
Claims 57–61 and 63 each recite a computer-readable medium storing instructions that cause a computer to perform exactly the same method as recited in corresponding claims 51–54, 56, and 55 (in that order). Therefore, the findings from the rejections of those claims are hereby incorporated by reference, mutatis mutandis with respect to the claimed invention being an “article of manufacture” at step 1, rather than a process. However, once again, because the results of steps 2A and 2B are the same, these claims are deemed ineligible for the same reasons.
Claim Rejections – 35 U.S.C. § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and 103 (or as subject to pre-AIA 35 U.S.C. § 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of pre-AIA 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
Claim(s) 43–61 and 63 are rejected under pre-AIA 35 U.S.C. § 102(b) as being anticipated by U.S. Patent Application Publication No. 2010/0031227 A1 (“Cook”).
Claim 43
Cook discloses:
A scenario modeler, comprising:
“The present invention provides systems and methods for providing a structured representation of integration scenarios of software products.” Cook ¶ 8. “FIG. 1 depicts an operating environment 100,” Cook ¶ 10,” with all of the elements of the claimed scenario modeler for the reasons given below.
an input configured to receive, from an interview capture tool, interview data containing information about a plurality of interviewees,
Environment 100 includes an application program 175 (the claimed “input”) on server 110 that is capable of obtaining “atomic customer design elements” previously created or edited by another application program 170 (the claimed “interview capture tool”) to produce “new composed customer design elements.” Cook ¶¶ 23–24.
Each of these composed customer design elements, also known as “roles” or “personas,” thus “contains a set of responsibilities and skills that may model a software user,” and each “describes an example person representative of the roles that typical users assume” (e.g., an IT operator role). Cook ¶¶ 15–16.
The prior art does not need to disclose the act of conducting an interview, nor does the prior art need to disclose whether the people for whom the data describes are “interviewees,” because “[c]laim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure.” MPEP § 2111.04 (subsection I.) (emphasis added).
In this case, claim 43 does not affirmatively recite a step of conducting an interview, nor does claim 43 recite a structure for the scenario modeler that requires the interview data to be received during an interview. It merely recites an input configured to receive the “information” described in the claim. Since Cook’s composed customer design elements (particularly the roles and/or personas) model an entire category of users (i.e., a plurality), and since the claim language does not require an apparatus that conducts the interview, Cook’s composed customer design elements fall within the scope of “interview data containing information about a plurality of interviewees.”
wherein the information about each of at least some of the interviewees comprises scenario information;
These “atomic customer design elements” that application program 175 receives from application program 170 to create the personas “are typically fine grain elements such as a skill, a goal measure, a tool, or a responsibility that are referenced by the composed customer design elements.” Cook ¶ 14. Additionally, the personas may further include “goal, task, use case, and scenario elements” as their customer design elements. Cook ¶ 17. “A task element may be used to describe a step performed to reach a goal,” while “[s]cenario elements may be used to describe paths through a task flow for a given task role or persona that have a structure similar to the structure of tasks.” Cook ¶ 17.
Please note that while Cook’s “scenario elements” most directly anticipate the claimed “scenario information,” any/all of the foregoing examples of customer design elements fall within the broadly claimed scope of that term, based on the numerous examples of “scenario information” provided in the Written Description of this application. (See, e.g., Spec. ¶¶ 50, 51, 107, 182, and 185).
a graphical user interface (GUI);
“Connected to the server 110 through the distributed network 140 are client devices, such as a personal computer 120, and a laptop computer 130.” Cook ¶ 11. For example, the users may access the application programs on the server 110 using an application program 150, such as a web browser. Cook ¶¶ 29 and 35; see also Cook ¶¶ 23, 24, and 33 (describing the users accessing and interacting with other programs on the server 110, in addition to the ones mentioned in paragraphs 29 and 35).
and a control program running on a computer device and operable to:
Reference is now made to FIG. 2, which is a flow diagram 200 of operations performed when server 110 executes one or more application programs 170–190. See Cook ¶¶ 30 and 12.
display the scenario information on the GUI;
“At step 230, a user searches for existing customer design elements stored in the database 160 using a customer design exploration tool 180,” such as “persona elements that model a person that might use the software that that user is developing,” Cook ¶ 31, and “creates reports based on the search results of step 230 using a customer design analysis tool 185.” Cook ¶ 32.
receive, via the GUI, inputs defining activities to be performed by one or more hypothetical persons; and
“Optionally, a user can revise existing customer design elements at step 250 using application program 170 or 175. For example, a user can expand the relationship of a persona by adding a new pain point to that persona. Or, a user could create a new customer design element using existing customer design elements. For example, a user could use application program 175 to select an existing persona element and select additional customer design elements that are needed in the new persona.” Cook ¶ 33.
generate a scenario data set comprising a list of the activities to be performed.
“After revising the customer design element, the revised customer design element is stored in the database 160 at step 220.” Cook ¶ 33.
Claim 44
Cook discloses the scenario modeler of claim 43,
wherein the information about each interviewee comprises interview values corresponding to respective responses to a plurality of interview questions.
“Where the only difference between a prior art product and a claimed product is printed matter that is not functionally related to the product, the content of the printed matter will not distinguish the claimed product from the prior art.” MPEP § 2112.02 (subsection III.) (citing In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. 2004)). In this case, the only difference between the claimed information and Cook’s information is that Cook does not say whether the “atomic customer design elements,” e.g., the “goal, task, use case, and scenario elements” are in the form of a question. However, Cook’s data does not need to be in the form of a question to anticipate the scenario modeler of claim 44, because such a difference is not functionally related to the claimed scenario modeler.
Claim 45
Cook discloses the scenario modeler of claim 43,
wherein the control program is further operable to receive, via the GUI, a name of a scenario.
“Existing customer design elements and work products may be . . . renamed[] or modified in the database 160.” Cook ¶ 22. To facilitate this type of editing, “[t]he server 110 contains an application program 170 that is capable of editing atomic customer design elements,” such as “a simple text editor or a more advanced XML editor.” Cook ¶ 23.
Recall that scenarios are one of the types of customer design elements, see Cook ¶ 17, so putting this together, Cook discloses using a text editor or XML editor to rename customer design elements, one of which may be a scenario.
Claim 46
Cook discloses the scenario modeler of claim 45,
wherein the plurality of activities to be performed by the one or more hypothetical persons defines the scenario.
“Scenario elements may be used to describe paths through a task flow for a given task role or persona that have a structure similar to the structure of tasks.” Cook ¶ 17.
Claim 47
Cook discloses the scenario modeler of claim 43,
wherein the scenario data set is in the form of a disk file or part of a database.
“The database 160 provides persistent storage of customer design elements and related work products, including transformed instances of the XML data representing these elements. New customer design elements and work products may be placed into the database 160.” Cook ¶ 22.
Claim 48
Cook discloses the scenario modeler of claim 43, wherein the control program is further operable to:
determine a plurality of scenarios
“The customer design exploration tool 180 is capable of performing queries or searches on the content of the database 160, gathering a result set holding the selected customer design elements, and returning the results set.” Cook ¶ 26. “For example, a user may want to search for persona elements that model a person that might use the software that that user is developing. The user could search for personas matching a list of customer design elements.” Cook ¶ 31.
Recall that scenarios are one of the types of customer design elements, see Cook ¶ 17, so putting this together, Cook discloses that the customer design exploration tool 180 is operable to search for and return a plurality of scenarios.
with each scenario comprising a series of steps;
These scenario elements “describe paths through a task flow for a given task[,] role[,] or persona,” and the underlying task elements each “describe a step performed to reach a goal.” Cook ¶ 17.
evaluate the series of steps to determine key interactions for each step in the series of steps, wherein each key interaction is defined based upon requirements information and criteria for success information; and
Next, a customer design analysis tool 185 obtains the customer design elements provided by the customer design exploration tool 180—which may include scenario elements as discussed earlier—to “highlight[] selected content elements or selected associations of customer design elements.” Cook ¶ 27.
One such association within the scenario customer design element are the tasks that define the given scenario. Cook ¶ 17. Notably, each task element “may be used to describe a step performed to reach a goal,” while the goal element “may be used to describe a result to be achieved related to the design of a software offering independent of how the goal is achieved.” Cook ¶ 17. Therefore, by retrieving the all of the task and goal elements associated with a matching scenario element, the system determines the same key interactions defined by claim 48: each scenario’s description of “paths through a task flow,” as well as its descriptions of the steps one must perform for each task, fall within the broad scope of “requirements information” (the persona is required to take certain paths and perform certain actions), while the claimed “criteria for success information” is present via the scenario element’s goal element (and/or the goals in its task elements), which describe the result that must be achieved during that scenario by performing the scenario’s tasks.
document the plurality of scenarios to show common and unique needs between the hypothetical persons.
“The output from the customer design analysis tool 185 can include ‘canned’ reports on the selected customer design elements and a more visual comparison on a new custom diagramming surface. For example, a user may be planning to develop a new software program that is going to be used by IT Analysts. The user could use the application program 180 to search for relevant customer design elements, such as role elements similar to an IT Analyst and responsibilities similar to those of an IT Analyst.” Cook ¶ 27.
Claim 49
Cook discloses the scenario modeler of claim 48,
wherein the generated scenario data set further comprises the key interactions, the series of steps, and the requirements information.
“Scenario elements may be used to describe paths through a task flow for a given task,” while each given task thereof “describe[s] a step performed to reach a goal,” and the goal element is “used to describe a result to be achieved related to the design of a software offering independent of how the goal is achieved.” Cook ¶ 17.
Claim 50
Cook discloses the scenario modeler of claim 43,
wherein the hypothetical persons are data models representing a type of human called a persona.
“A persona element is a customer design element that describes an example person representative of the roles that typical users assume. A persona may be defined by responsibility and role elements, plus goal, skill, motivation, emotion, and behavior elements.” Cook ¶ 16.
Claim 51
Cook discloses
A computer-implemented method for generating a scenario, comprising:
“FIG. 2 provides a flow diagram 200 for structured representation of integration scenarios of software products.” Cook ¶ 30.
receiving, via an interview capture tool, interview data containing information about a plurality of interviewees,
“Referring to FIGS. 1 and 2, at step 210, a user creates new atomic and composed customer design elements using application program 170 executing on the server 110.” Cook ¶ 30.
Each of these composed customer design elements, also known as “roles” or “personas,” thus “contains a set of responsibilities and skills that may model a software user,” and each “describes an example person representative of the roles that typical users assume” (e.g., an IT operator role). Cook ¶¶ 15–16.
The prior art does not need to disclose the act of conducting an interview, nor does the prior art need to disclose whether the people for whom the data describes are “interviewees,” because “[c]laim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure.” MPEP § 2111.04 (subsection I.) (emphasis added). In this case, claim 51 does not affirmatively recite a step of conducting an interview, nor does claim 51 recite a structure that requires the interview data to be received during an interview. It merely recites “interview data” comprising “information” that is formatted as described in the claim.
Regarding the claimed “plurality,” since Cook’s composed customer design elements (particularly the roles and/or personas) model an entire category of users (i.e., a plurality), and since the claim language does not require an apparatus that conducts the interview, Cook’s composed customer design elements fall within the scope of “interview data containing information about a plurality of interviewees.”
wherein the information about each of at least some of the interviewees comprises scenario information,
These “atomic customer design elements” that application program 175 receives from application program 170 to create the personas “are typically fine grain elements such as a skill, a goal measure, a tool, or a responsibility that are referenced by the composed customer design elements.” Cook ¶ 14. Additionally, the personas may further include “goal, task, use case, and scenario elements” as their customer design elements. Cook ¶ 17. “A task element may be used to describe a step performed to reach a goal,” while “[s]cenario elements may be used to describe paths through a task flow for a given task role or persona that have a structure similar to the structure of tasks.” Cook ¶ 17.
Please note that while Cook’s “scenario elements” most directly anticipate the claimed “scenario information,” any/all of the foregoing examples of customer design elements fall within the broadly claimed scope of that term, based on the numerous examples of “scenario information” provided in the Written Description of this application. (See, e.g., Spec. ¶¶ 50, 51, 107, 182, and 185).
and the information about each interviewee comprises interview values corresponding to respective responses to a plurality of interview questions;
“Where the only difference between a prior art product and a claimed product is printed matter that is not functionally related to the product, the content of the printed matter will not distinguish the claimed product from the prior art.” MPEP § 2112.02 (subsection III.) (citing In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. 2004)). Importantly, this same doctrine “has been extended to method claims.” See MPEP § 2111.05.
In this case, the only difference between the claimed information and Cook’s information is that Cook does not say whether the “atomic customer design elements,” e.g., the “goal, task, use case, and scenario elements” are in the form of a question. However, Cook’s data does not need to be in the form of a question to anticipate the method of claim 51, because such a difference is not functionally related to the claimed method or to the scenario modeler that performs the claimed method.
displaying the scenario information on a graphical user interface (GUI);
“At step 230, a user searches for existing customer design elements stored in the database 160 using a customer design exploration tool 180,” such as “persona elements that model a person that might use the software that that user is developing,” Cook ¶ 31, and “creates reports based on the search results of step 230 using a customer design analysis tool 185.” Cook ¶ 32.
receiving, via the GUI, inputs defining a name of the scenario and activities to be performed by one or more hypothetical persons; and
“Optionally, a user can revise existing customer design elements at step 250 using application program 170 or 175. For example, a user can expand the relationship of a persona by adding a new pain point to that persona. Or, a user could create a new customer design element using existing customer design elements. For example, a user could use application program 175 to select an existing persona element and select additional customer design elements that are needed in the new persona.” Cook ¶ 33.
In addition, the customer design elements may be “renamed[] or modified in the database 160,” Cook ¶ 22, by a user operating a text or XML editor portion of the user interface. Cook ¶ 23.
generating a scenario data set comprising a list of the activities to be performed.
“After revising the customer design element, the revised customer design element is stored in the database 160 at step 220.” Cook ¶ 33.
Claim 52
Cook discloses the computer-implemented method of claim 51,
wherein the plurality of activities to be performed by the one or more hypothetical persons defines the scenario as a series of steps.
“Scenario elements may be used to describe paths through a task flow for a given task role or persona that have a structure similar to the structure of tasks.” Cook ¶ 17. These scenario elements “describe paths through a task flow for a given task[,] role[,] or persona,” and the underlying task elements each “describe a step performed to reach a goal.” Cook ¶ 17.
Claim 53
Cook discloses the computer-implemented method of claim 52, further comprising:
evaluating the series of steps to determine key interactions for each step in the series of steps, wherein each key interaction is defined based upon requirements information and criteria for success information.
“At step 240, a user creates reports based on the search results of step 230 using a customer design analysis tool 185.” Cook ¶ 32. For this step, a customer design analysis tool 185 obtains the customer design elements provided by the customer design exploration tool 180—which may include scenario elements as discussed earlier—to “highlight[] selected content elements or selected associations of customer design elements.” Cook ¶ 27.
One such association within the scenario customer design element are the tasks that define the given scenario. Cook ¶ 17. Notably, each task element “may be used to describe a step performed to reach a goal,” while the goal element “may be used to describe a result to be achieved related to the design of a software offering independent of how the goal is achieved.” Cook ¶ 17. Therefore, by retrieving the all of the task and goal elements associated with a matching scenario element, the system determines the same key interactions defined by claim 53: each scenario’s description of “paths through a task flow,” as well as its descriptions of the steps one must perform for each task, fall within the broad scope of “requirements information” (the persona is required to take certain paths and perform certain actions), while the claimed “criteria for success information” is present via the scenario element’s goal element (and/or the goals in its task elements), which describe the result that must be achieved during that scenario by performing the scenario’s tasks.
Claim 54
Cook discloses the computer-implemented method of claim 53,
wherein the generated scenario data set further comprises the key interactions, the series of steps, and the requirements information.
“Scenario elements may be used to describe paths through a task flow for a given task,” while each given task thereof “describe[s] a step performed to reach a goal,” and the goal element is “used to describe a result to be achieved related to the design of a software offering independent of how the goal is achieved.” Cook ¶ 17.
Claim 55
Cook discloses the computer-implemented method of claim 54,
wherein the scenario data set is a disk file or part of a database.
“The database 160 provides persistent storage of customer design elements and related work products, including transformed instances of the XML data representing these elements. New customer design elements and work products may be placed into the database 160.” Cook ¶ 22.
Claim 56
Cook discloses the computer-implemented method of claim 51,
wherein the hypothetical persons are data models representing a type of human.
“A persona element is a customer design element that describes an example person representative of the roles that typical users assume. A persona may be defined by responsibility and role elements, plus goal, skill, motivation, emotion, and behavior elements.” Cook ¶ 16.
Claims 57–61 and 63
Claims 57–61 and 63 each recite a computer-readable medium storing instructions that cause a computer to perform exactly the same method as recited in corresponding claims 51–54, 56, and 55 (in that order). Therefore, the findings from the rejections of those claims are hereby incorporated by reference, and taken in conjunction with the further finding that Cook discloses the non-transitory computer-readable medium itself. See Cook ¶ 12 and Cook Claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Patent Application Publication No. 2010/0010872 discloses a system for creating and using personas to facilitate the identification of a best action or choice in response to a particular situation or dilemma.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin R. Blaufeld whose telephone number is (571)272-4372. The examiner can normally be reached M-F 9:00am - 4:00pm ET.
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, James K Trujillo can be reached at (571) 272-3677. 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.
Justin R. Blaufeld
Primary Examiner
Art Unit 2151
/Justin R. Blaufeld/Primary Examiner, Art Unit 2151
Prosecution Insights