Detailed Action
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Arguments
Informalities — Objections Withdrawn
The Examiner agrees that the amendment to claim 59 and cancellation of claim 53 resolves the informalities raised in the previous office action, and therefore, the objections to those claims are hereby withdrawn.
Non-Statutory Subject Matter — Rejection Withdrawn
The rejection of claims 43–50 under 35 U.S.C. § 101 for encompassing embodiments directed to non-statutory subject matter is hereby withdrawn in response to the Applicant’s narrowing of the claim scope to avoid software per se embodiments.
Subject Matter Eligibility — Rejection Stands
Claims 43–52, 54–61, and 63–65 stand 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. The Applicant’s remarks have been considered, but are not persuasive.
1. The claims are directed to an abstract idea (Step 2A, Prong One). The Applicant argues that the claims are not directed to an abstract idea because they require complex, “matrix-level” cross-scenario evaluations and multidimensional data processing that exceed what can reasonably be performed mentally or with pen and paper. The Examiner respectfully disagrees for several reasons.
Before addressing each of the Applicant’s points in this section, the Examiner points out that this entire section of the Applicant’s arguments ignores half of the rejection, because the rejection identified two different groupings for abstract ideas. Specifically, in the rejection, the Examiner found that the claim was directed to a mental process and methods of organizing human activity. The Applicant’s pen and paper argument is not applicable to the methods of organizing human activity grouping. Thus, regardless of each of the Applicant’s arguments with respect to the mental processes grouping, the rejection stands unchallenged on the “methods of organizing human activity” finding.
Nevertheless, the Examiner also does not find the Applicant’s five arguments concerning the “mental processes” grouping persuasive, either, for the following reasons.
Regarding the Applicant’s argument labeled “First” (Response 10–11), the courts do not distinguish between mental processes performed entirely in the human mind and those requiring a physical aid, such as a pen and paper, to account for variations in memory capacity or the volume of data. The act of determining hypothetical scenarios and outlining a series of steps constitutes a concept that can practically be performed in the human mind. Attempting to overcome the mental process exception by pointing to combinatorial complexity relies on the “draftsman’s art” rather than a genuine technological limitation, which the Supreme Court has explicitly cautioned against. See Alice Corp. v. CLS Bank Int’l, 573, U.S. 208, 224 (2014).
Regarding the Applicant’s argument labeled “Second,” the Examiner respectfully disagrees that evaluating each step of each scenario to determine key interactions based on requirements and criteria requires analyzing a multidimensional set of inputs, resulting in a matrix-level computational process. (See Response 11).
Evaluating steps to determine interactions based on success criteria fundamentally describes an observation, evaluation, or judgment, all of which the courts strictly classify as mental processes. While the claim language employs sophisticated terminology to describe the claimed invention, the actual limitations, such as “determine a plurality of scenarios,” “evaluate the series of steps,” and “evaluate the plurality of scenarios to determine common needs and unique needs,” describe fundamental cognitive tasks. These limitations correspond directly to the mental processes of observation, evaluation, and judgment, which the courts have consistently identified as abstract ideas. Stripped of its formal phrasing, the claim merely describes the routine process a human designer undertakes when reviewing user feedback, identifying overlapping user goals, and structuring a design framework.
Furthermore, categorizing hypothetical people into “personas” and mapping their “activities” and “emotional context” squarely constitutes a method of organizing human activity. The courts do not distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer, nor does the volume or combinatorial nature of the data being processed negate the fundamental nature of the steps as an abstract concept. Because the claims merely recite a series of mental evaluations and organizational tasks dressed in formal terminology, they are directed to an abstract idea.
The underlying process of evaluating whether a step meets specific criteria can be performed mentally or by a human using a pen and paper, regardless of the terminology used to describe the inputs.
Regarding the Applicant’s argument labeled “Third,” the Examiner is not persuaded that evaluating scenarios to determine common and unique needs across personas involves a cross-scenario comparative analysis requiring computational correlation. (See Response 11).
Identifying the overlapping or distinct needs of hypothetical personas is fundamentally a method of managing relationships or interactions between people, which falls squarely within the certain methods of organizing human activity grouping of abstract ideas. Furthermore, performing a comparative analysis to identify commonalities and differences is an evaluation or judgment that can practically be performed in the human mind, confirming its status as an abstract mental process.
Regarding the Applicant’s argument labeled “Fourth,” the Examiner respectfully disagrees that the recitation of generating structured scenario data sets configured as frameworks for end-user interaction is a data-processing function that requires computational implementation. (See Response 11–12).
A process of organizing information, or generating data by taking existing information and organizing it into a new form, is exactly the kind of abstract ideas that fall within the abstract ideas judicial exception to 35 U.S.C. § 101. Structuring data into a scenario data set configured as a framework is an example of organizing human activity and mental concepts, and remains an abstract idea regardless of the formal nomenclature applied to the output.
Regarding the Applicant’s argument labeled “Finally,” the Examiner disagrees that generating structured scenario data sets configured as frameworks requires a data-processing function to aggregate and structure information. (See Response 12). The Federal Circuit has held that a process of organizing information, or generating data by taking existing information and organizing it into a new form, is directed to an abstract idea. See Digitech Image Techs., LLC v. Electronics for Imaging, Inc., 758 F.3d 1344, 1350, 111 USPQ2d 1717, 1721 (Fed. Cir. 2014). Structuring data into a scenario data set configured as a framework is a routine process of organizing human activity and mental concepts, and remains an abstract idea regardless of the formal nomenclature applied to the output.
2. No improvement of computer functionality is recited in the claims; improvements to a judicial exception that are merely implemented on a computer is not the same as an improvement to computer functionality.
The Applicant contends that the claimed “scenario data set” provides a specific, non-generic data structure that improves the functioning of user experience design systems, analogous to the self-referential database found eligible in Enfish. (Response 13). The Examiner respectfully disagrees.
To demonstrate an improvement to computer functionality, the claim must do more than merely use a computer as a tool to perform an abstract idea. Accelerating a process when the increased speed comes solely from the capabilities of a general-purpose computer is not sufficient to show an improvement in computer functionality.
Unlike Enfish, where the claimed invention improved the fundamental way a computer stores and retrieves data in memory, the “scenario data set” in this application merely organizes and correlates human-readable information. As the Federal Circuit held in Digitech, a process of organizing information through mathematical correlations or rules is directed to an abstract idea.
The claims here recite generic components (a processor, memory, and graphical user interface) to evaluate and organize data, which represents using a computer environment merely as a tool to execute the abstract idea.
Accordingly, this argument is not persuasive.
3. Nothing in the Applicant’s arguments show that the claim recite significantly more than the judicial exception.
The Applicant contends that the ordered combination of operations (receiving data, determining scenarios, evaluating key interactions, generating a structured framework) represents a specific technical implementation that surpasses routine computer activity, analogous to the rules-based automation in McRO. (Response 14–15). The Examiner respectfully disagrees.
An “inventive concept” cannot be furnished by the unpatentable abstract idea itself. Simply appending fundamental, basic computer functions such as receiving data, displaying information on a GUI, and generating a dataset, and specified at a high level of generality, does not add significantly more to the judicial exception.
The applicant’s reliance on McRO is also misplaced. In McRO, the claims improved an existing technological process (facial expression animation) by utilizing specific, non-conventional rules. In contrast, the steps of gathering interview data and generating a data set in the current claims constitute insignificant extra-solution activity (data gathering) and generally link the abstract idea to a generic technological environment, which fails to transform the claim into an eligible application.
Accordingly, since the Applicant’s arguments concerning subject matter eligibility under 35 U.S.C. § 101 are not persuasive, the rejection stands.
Anticipation — Rejection Stands
Claim(s) 43–47, 50–52, 55–58, 31, and 63 stand rejected under pre-AIA 35 U.S.C. § 102(b) as being anticipated by U.S. Patent Application Publication No. 2010/0031227 A1 (“Cook”). The Applicant’s remarks have been considered in light of the amendment, but are not persuasive.
1. The claims do not require anyone to conduct an interview, and even if they did, Cook discloses such interview data.
Applicant argues that Cook’s data represents “designer-generated modeling” rather than data “obtained through interviews with real people.” This argument is unpersuasive for several reasons.
First, Cook explicitly discloses that the data in the person element is not merely for hypothetical people, and instead, “may be discovered through many resources including user research.” Cook ¶ 16.
Second, Cook 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,” for at least three reasons.
For one, “[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 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.”
Indeed, the Applicant was very careful to use the passive voice with respect to the interviews being “obtained through interviews with real people.” By using the passive voice, the act of obtaining the interviews is not attributed to any particular actor, let alone the claimed system. Said differently, the Applicant did not claim a computer system that conducts interviews; rather, the Applicant merely claimed a computer system configured to receive interview data. The claim places no requirement on how the system covered by the claim obtains this interview data. It describes where the data comes from, but it does not require the source of that data (e.g., recordings of the interviewees) to be an element of the system. The prior art does not need to disclose components that aren’t part of a system to show why such a system existed prior to the effective filing date of the claimed invention.
Additionally, the data that Cook processes and the data recited in the claim is the same data within the broadest reasonable interpretation of the claim; the only difference between Cook’s data and the claimed data is the identity of the person who provided it. The Federal Circuit has repeatedly warned that “a description of the environment in which a claimed invention operates” is not “a limitation on the claimed invention itself.” Nazomi Communications, Inc., v. Nokia Corp., 739 F.3d 1339, 1345 (Fed Cir. 2014) (citing Silicon Graphics, Inc. v. ATI Technologies, Inc., 607 F.3d 784, 794-95 (Fed. Cir. 2010); and Advanced Software Design Corporation v. Fiserv, Inc., 641 F.3d 1368, 1375 (Fed. Cir. 2011)). Cook discloses a system that processes the same data as the claimed invention, thus, Cook does not need to further disclose details about the external environment of the claimed system in order to anticipate it.
Finally, even assuming for the sake of argument that the claim language somehow requires the interview data to be obtained through interviews with real people, any such difference between the data in Cook’s disclosure and the claimed interview data would be a difference in printed matter, and “[w]here 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)).
Any difference between data describing a hypothetical person’s job and data describing an actual person having exactly the same job falls within the purview of printed matter because the difference wholly lies in the “message or meaning” that the data conveys “to a human reader independent of the intended computer system.” MPEP § 2111.05 (subsection III.).
In making these three points, the Examiner notes that the claim language of the interview data being “obtained through interviews with real people” has not been ignored. Rather, it has been analyzed three different ways to determine its legal effect on the claim’s scope, and in this case, the legal effect of interview data “obtained through interviews with real people” is that it is a description of something that cannot be used to distinguish the claimed invention from the prior art.
2. Cook discloses the steps of determining scenarios, evaluating steps, and evaluating scenarios for common/unique needs.
Applicant contends that Cook’s “scenario elements” are merely abstract, technology-agnostic workflow steps lacking the claimed environmental and emotional contexts of real people. (Response 19–20). However, this assertion is directly contradicted by the text of the reference: Cook explicitly discloses that its data models (personas) are defined by elements that include actual “emotion” and “behavior” elements. Cook ¶ 16. Moreover, Cook’s system incorporates “pain point” elements to describe “something that annoys a role or a persona” (a direct disclosure of emotional context) or “prevents a role or a persona from achieving its goals” (a direct disclosure of environmental and situational context). Cook ¶ 18. Because Cook’s scenario elements map paths through tasks performed by these very personas, the scenario information inherently includes the emotional, behavioral, and environmental contexts claimed by Applicant.
3. Cook discloses determining scenarios, evaluating steps, and evaluating scenarios for common/unique needs.
i. Cook discloses determining scenarios based on interview data. Applicant’s argument (Response 21) improperly attempts to narrow the claims by importing limitations from the specification regarding how scenarios are formulated. Under the Broadest Reasonable Interpretation (BRI), the phrase “determine a plurality of scenarios” does not strictly require generating scenarios from scratch. Cook discloses a customer design exploration tool that performs queries on database content to gather a result set of selected customer design elements, which explicitly include “scenario elements.” Cook ¶¶ 17 and 26). Querying a dataset to ascertain which scenarios match specific parameters reads squarely on “determining” a plurality of scenarios. Because Cook’s customer design elements model actual software users based on user research, this data falls within the broad scope of “interview data.”
Furthermore, to the extent this argument attempts to re-litigate the “interview data” discussed earlier, the Examiner’s response to this argument is the same as discussed in subsection 1, above.
ii. Cook discloses evaluating steps to determine key interactions based on requirements and success criteria. The Applicant’s attempt to draw a false dichotomy between “visual highlighting” and “substantive functional analysis” (Response 22) does not persuade the Examiner of error. Cook’s customer design analysis tool operates on selected sets of data to actively compare attributes and highlight selected associations of customer design elements. Cook ¶ 27. In Cook, “scenario elements” describe paths through a task flow, where each task is a “step performed to reach a goal,” and the goal describes a “result to be achieved.” Cook ¶ 17. By comparing these elements to highlight their associations, Cook’s system does indeed evaluate the task flows (the series of steps and requirements) to determine how they achieve their goals (the criteria for success).
Furthermore, Cook explicitly evaluates “use case elements,” which describe “how the user interacts with the system to achieve that goal,” Cook ¶ 17, which maps perfectly to the claimed “key interactions.” Cook also uses “pain point elements” to evaluate what prevents a user from achieving their goals, Cook ¶ 18, which constitutes a direct functional evaluation of the steps against the criteria for success.
iii. Cook discloses evaluating scenarios to determine common and unique needs for personas. Applicant argues that producing reports does not equate to a “computational comparison across multiple scenarios.” (Response 23). Whether or not that is true does not matter, because a “computational comparison across multiple scenarios” is not claimed. The claim language merely says to “evaluate the plurality of scenarios to determine common needs and unique needs for the one or more personas.” The Applicant is attempting to make the claim language sound more complicated than it actually is. At a minimum, when Cook’s system generates a visual comparison between different customer design elements, such as different personas or scenarios, it inherently documents and evaluates where those elements overlap and where they diverge. Comparing elements to identify these overlaps and divergences reads directly on evaluating them to “determine common and unique needs.”
iv. Cook discloses generating scenario data sets configured as frameworks for identifying key interactions. Applicant argues that Cook merely “stores a revised customer design element,” which allegedly falls short of generating a structured analytical framework. (Response 23–24). This ignores the technical realities of Cook’s disclosure. Cook’s application programs actively “produce new composed customer design elements with accurate references to other customer design elements” in the form of transformed Extensible Markup Language (XML) data. Cook ¶¶ 22 and 24. An XML document that aggregates a scenario, its tasks, its goals, and its associated personas constitutes a generated “scenario data set.” Because this structured XML dataset is subsequently utilized by Cook’s exploration and analysis tools to allow developers to further design, compare, and identify interactions, the data set is, by definition, “configured to be used as a framework” for identifying key interactions.
For these reasons, the Examiner is not persuaded to withdraw the rejection of at least the independent claims over Cook’s disclosure.
Moreover, in this Office Action, each and every claim is rejected over the prior art (and under 35 U.S.C. § 101). Accordingly, the application is not in condition for allowance at this time.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosures of the prior-filed application, Application Nos. 61/499,120 and 61/499,417, fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Neither provisional application provides a disclosure for the subject matter of claims 48, 49, 59, 60, 64, or 65.
Claim Rejections – 35 U.S.C. § 112
The following is a quotation of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), first paragraph:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
I. First Ground of Rejection — Written Description Requirement
Claim 65 is rejected under 35 U.S.C. § 112(a) or 35 U.S.C. § 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
The Written Description does not disclose “generate a wireframe for each scenario that summarizes specific features for a given persona in a single common specification” recited in new claim 65. The claim language appears to be inspired by paragraph 185 of the specification as filed, but paragraph 185 does not say that the wireframes themselves summarize specific features for a given persona in a single common specification. Instead, paragraph 185 says that the scenario modeler 116, through its overall process in general, summarizes specific features for a given personas in a single common specification, and that the scenario modeler 116 is also responsible for generating a wireframe for each scenario, but there is nothing in this disclosure that says the wireframes 1210 themselves are what summarize the specific features for the given personas, nor is it even clear how such a summary would be possible via a “wireframe.”
II. Second Ground of Rejection — Enablement Requirement
Claim 65 is rejected under 35 U.S.C. § 112(a) or pre-AIA 35 U.S.C. § 112, first paragraph, as failing to comply with the enablement requirement. The claim contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Specifically, claim 65 recites the limitation of “documenting aggregating scenarios showing overlap and unique need to generate a wireframe for each scenario that summarizes specific features for a given persona in a single common specification.” The specification fails to provide sufficient guidance to enable a person of ordinary skill in the art to perform the computational step of generating a wireframe without undue experimentation.
The examiner has evaluated the specification in light of the factors set forth in In re Wands, 858 F.2d 731, 8 USPQ2d 1400 (Fed. Cir. 1988) to determine that undue experimentation would be required:
1. The amount of direction or guidance presented: The specification provides merely a high-level, functional statement of the desired result. Paragraph [0185] states, “The scenario modeler aggregates the information 1004, 1006 for each scenario to generate a wireframe 1210 for each scenario.” The specification completely fails to disclose how the scenario modeler accomplishes this (e.g., the specific algorithms, data mapping rules, heuristics, or programmatic logic required to convert abstract textual scenario needs into a structural, visual wireframe layout).
2. The presence or absence of working examples: The specification lacks working examples of the algorithmic execution. While Figure 12 provides a conceptual flowchart of the UX design process, there are no technical details, source code snippets, or data structures demonstrating how a wireframe is computationally generated from the aggregated scenario information.
3. The breadth of the claims: Claim 65 broadly recites generating a wireframe based on scenario overlap and unique needs, encompassing any automated or programmatic method of translating scenario data into a structural user interface (UI) across any software platform.
4. The nature of the invention: The invention pertains to computerized tools for user experience (UX) and software interface design, a domain where the automation of visual and structural UI design involves highly complex data transformations.
5. The state of the prior art: While basic wireframing software and data aggregation tools are known in the prior art, the automated programmatic generation of a visual wireframe directly from qualitative scenario needs is a complex undertaking that requires specialized logic.
6. The relative skill of those in the art: The person of ordinary skill in the art is a software developer or UX engineer possessing a high level of skill. However, a high level of skill cannot substitute for a complete lack of technical disclosure regarding the core logic of the claimed transformation.
7. The predictability or unpredictability of the art: The automated translation of abstract data (e.g., “common needs” and “unique needs”) into a structural graphic wireframe is highly unpredictable without explicitly defined mapping rules or algorithms.
8. The quantity of experimentation necessary: Because the specification merely describes the outcome (a generated wireframe) rather than the computational means to achieve it, a POSITA would be required to invent the underlying algorithms and mapping logic from scratch to practice the invention. This constitutes an undue amount of experimentation.
Therefore, because the specification relies on a purely functional statement without disclosing the underlying technical implementation, the specification does not enable the full scope of claim 65.
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.
Claims 43–52, 55–61, and 63–65 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 to correlate each scenario with participating personas and assign a pre-defined score value to each scenario by: aggregating the participating personas having goals correlated to the scenario; and producing a priority score for the scenario by scaling a number of the aggregated personas by a weighing factor based on a perceived importance of success by the participating personas. These added steps are further instances of either an abstract mental process, or, a mathematical process. 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 calculating a score for different scenarios, based on pre-known values for each of the personas implicated in the scenarios (and their pre-known relationships with the scenarios). 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 a statement of intended use for the score calculated in the previous claim. Moreover, this statement of intended use is itself an abstract mental process: they help inform how to prioritize one human-performed task over another.
This judicial exception is not integrated into a practical application. The added limitation merely provides a further description of the abstract idea itself. A claim to multiple judicial exceptions is not any less of a judicial exception.
The claim does not include additional elements sufficient to amount to significantly more than the judicial exception. The added limitation merely provides a further description of the abstract idea itself. A claim to multiple judicial exceptions is not any less of a judicial exception.
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, 55, and 56
Claims 52, 55, and 56 fail to transform their parent claim 51 into a practical application, or add significantly more, for the same reasons that corresponding claims 46, 47, and 50 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.
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 64
Claim 64 is rejected based on the same findings and rationale as provided above for claim 48. While claim 64 uses different language from claim 48, it involves performing exactly the same calculation. Therefore, claim 64 is rejected for the same reason.
Claim 65
Claim 65 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites all of the elements of claim 51, “further comprising documenting aggregating scenarios showing overlap and unique need to generate a wireframe for each scenario that summarizes specific features for a given persona in a single common specification.”
Careful readers of claim 65 will observe that claim 65 does not involve generating the wireframe. Instead, claim 65 merely produces documenting the need for someone else (or some other, unclaimed process) to generate the wireframe.
This judicial exception is identified as the abstract idea of defining and documenting a situation based on collected information. This concept involves organizing information (the scenario information) and generating an explanation, 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). Furthermore, as mentioned above, generating the wireframe is not claimed; what is claimed is merely the process of informing someone about the need for a wireframe.
Additionally, 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 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). Furthermore, as mentioned above, generating the wireframe is not claimed; what is claimed is merely the process of informing someone about the need for a wireframe. Additionally, 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.
Accordingly, claim 65 is rejected under 35 U.S.C. § 101 for failing to recite significantly more than a judicial exception thereof.
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–47, 50–52, 55–58, 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 system, comprising: a computing device comprising a processor and memory;
“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 interface executing on the computing device and 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.
obtained through interviews with real people,
The data in the persona element is not necessarily hypothetical, and instead, “may be discovered through many resources including user research.” Cook ¶ 16. That being said, Cook 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,” for at least three reasons.
First, “[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 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.”
Indeed, the Applicant was very careful to use the passive voice with respect to the interviews being “obtained through interviews with real people.” By using the passive voice, the act of obtaining the interviews is not attributed to any particular actor, let alone the claimed system. Said differently, the Applicant did not claim a computer system that conducts interviews; rather, the Applicant merely claimed a computer system configured to receive interview data. The claim places no requirement on how the system covered by the claim obtains this interview data. It describes where the data comes from, but it does not require the source of that data (e.g., recordings of the interviewees) to be an element of the system. The prior art does not need to disclose components that aren’t part of a system to show why such a system existed prior to the effective filing date of the claimed invention.
Second, the data that Cook processes and the data recited in the claim is the same data within the broadest reasonable interpretation of the claim; the only difference between Cook’s data and the claimed data is the identity of the person who provided it. The Federal Circuit has repeatedly warned that “a description of the environment in which a claimed invention operates” is not “a limitation on the claimed invention itself.” Nazomi Communications, Inc., v. Nokia Corp., 739 F.3d 1339, 1345 (Fed Cir. 2014) (citing Silicon Graphics, Inc. v. ATI Technologies, Inc., 607 F.3d 784, 794-95 (Fed. Cir. 2010); and Advanced Software Design Corporation v. Fiserv, Inc., 641 F.3d 1368, 1375 (Fed. Cir. 2011)). Cook discloses a system that processes the same data as the claimed invention, thus, Cook does not need to further disclose details about the external environment of the claimed system in order to anticipate it.
Third, even assuming for the sake of argument that the claim language somehow requires the interview data to be obtained through interviews with real people, any such difference between the data in Cook’s disclosure and the claimed interview data would be a difference in printed matter, and “[w]here 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)).
Any difference between data describing a hypothetical person’s job and data describing an actual person having exactly the same job falls within the purview of printed matter because the difference wholly lies in the “message or meaning” that the data conveys “to a human reader independent of the intended computer system.” MPEP § 2111.05 (subsection III.).
In making these three points, the Examiner notes that the claim language of the interview data being “obtained through interviews with real people” has not been ignored. Rather, it has been analyzed three different ways to determine its legal effect on the claim’s scope, and in this case, the legal effect of interview data “obtained through interviews with real people” is that it is a description of something that cannot be used to distinguish the claimed invention from the prior art.
wherein the information about each of at least some of the interviewees comprises scenario information describing activities performed by the interviewees;
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 a control program stored in the memory, that, when executed by the processor, is 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 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.
With respect to the GUI itself, Cook discloses that this step (along with all of the other claimed steps that involve the GUI) is performed using an application program 150, such as a web browser, to access application programs on server 110. Cook ¶¶ 29 and 35.
wherein the scenario information includes at least one of activities performed by interviewees, environmental context of the activities, or emotional context of the interviewees;
“An aspect of the report may contain a listing of pain point elements that prevent the matching persona elements from completing their tasks.” Cook ¶ 32.
receive, via the GUI, user inputs defining activities to be performed by one or more hypothetical persons represented as one or more personas; 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.
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 43: 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.
evaluate the plurality of scenarios to determine common and unique needs for the one or more personas;
“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.
for each scenario of the plurality of scenarios, generate a scenario data set comprising
“After revising the customer design element,” i.e., with all of the data discussed above, “the revised customer design element is stored in the database 160 at step 220.” Cook ¶ 33.
As discussed earlier in this rejection and in Cook, the customer design element (or in this case, the revised version thereof) is a container that references several other specific design elements, see Cook ¶¶ 14 and 24, including the ones claimed for the reasons set forth below:
a list of the activities to be performed by the one or more personas,
One component of the revised customer design element may include the persona element, which among other things, includes any number of “goal” elements. Cook ¶ 16. “A 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.
the key interactions,
The customer design element may further include “use case” elements, which “describe a function that a system performs to achieve the user’s goals. Each use case element may describe a particular goal for the user and how the user interacts with the system to achieve that goal.” Cook ¶ 17.
the series of steps,
The customer design element may further include “scenario,” where “[o]ne type of scenario element may be a high level flow through technology and product agnostic steps to perform a task,” while “[a]nother type of scenario element may be a detailed flow through technology and product agnostic steps for performing one or more typical tasks.” Cook ¶ 17.
and the requirements information,
As mentioned above, 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). Cook ¶ 17.
wherein the scenario data set is configured to be used as a framework by a user of the scenario modeler system to identify the key interactions for each step in the scenario.
The customer design elements include “scenario elements,” which “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,” including “a detailed flow through technology and product agnostic steps for performing one or more typical tasks. Use case elements may be used to describe a function that a system performs to achieve the user’s goals. Each use case element may describe a particular goal for the user and how the user interacts with the system to achieve that goal.” Cook ¶ 17. Paragraph 27 then demonstrates how the system’s tools are used to actively identify and analyze the specific interactions.
Claim 44
Cook discloses the scenario modeler system 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 system of claim 44, because such a difference is not functionally related to the claimed scenario modeler.
Claim 45
Cook discloses the scenario modeler system of claim 43,
wherein the control program is further operable to receive, via the GUI, a name for 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 system 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 system 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 50
Cook discloses the scenario modeler system 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 in a scenario modeler system, 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.
obtained through conducting interviews with real people,
The data in the persona element is not necessarily hypothetical, and instead, “may be discovered through many resources including user research.” Cook ¶ 16. That being said, Cook 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,” for at least three reasons.
First, “[c]laim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed.” MPEP § 2111.04 (subsection I.) (emphasis added).
In this case, claim 51does not recite a step of conducting 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.”
Indeed, the Applicant was very careful to use the passive voice with respect to the interviews being “obtained through interviews with real people.” By using the passive voice, the act of obtaining the interviews is not attributed to any particular actor, let alone the system responsible for performing the claimed method. Said differently, the Applicant did not claim a method with a step of conducting interviews; rather, the Applicant merely claimed a method with a step of receiving interview data. The claim places no requirement on how one must obtain this interview data in order to infringe the method. It describes where the data comes from, but it does not require the source of that data (e.g., recordings of the interviewees) to be an element of the system. The prior art does not need to disclose components that aren’t part of a system to show why such a system existed prior to the effective filing date of the claimed invention.
Second, even assuming for the sake of argument that the claim language somehow requires the interview data to be obtained through interviews with real people, any such difference between the data in Cook’s disclosure and the claimed interview data would be a difference in printed matter, and “[w]here 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.
Any difference between data describing a hypothetical person’s job and data describing an actual person having exactly the same job falls within the purview of printed matter because the difference wholly lies in the “message or meaning” that the data conveys “to a human reader independent of the intended computer system.” MPEP § 2111.05 (subsection III.).
In making these two points, the Examiner notes that the claim language of the interview data being “obtained through interviews with real people” has not been ignored. Rather, it has been analyzed three different ways to determine its legal effect on the claim’s scope, and in this case, the legal effect of interview data “obtained through interviews with real people” is that it is a description of something that cannot be used to distinguish the claimed invention from the prior art.
wherein the information about each of at least some of the interviewees comprises scenario information describing activities performed by the interviewees,
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 asked during the interviews;
As previously mentioned, the data in the persona element is not necessarily hypothetical, and instead, “may be discovered through many resources including user research.” Cook ¶ 16.
displaying, by a computing device, 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.
With respect to the GUI itself, Cook discloses that this step (along with all of the other claimed steps that involve the GUI) is performed using an application program 150, such as a web browser, to access application programs on server 110. Cook ¶¶ 29 and 35.
wherein the displayed scenario information includes at least one of activities performed by interviewees, environmental context of the activities, or emotional context of the interviewees;
“An aspect of the report may contain a listing of pain point elements that prevent the matching persona elements from completing their tasks.” Cook ¶ 32.
receiving, via the GUI, user inputs defining a name of the scenario and activities to be performed by one or more hypothetical persons represented as one or more personas;
“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.
determining, by the computing device, 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.
evaluating, by the computing device, the series of steps to determine key interactions for each step, wherein each key interaction is defined based upon requirements information and criteria for success information;
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 43: 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.
evaluating, by the computing device, the plurality of scenarios to determine common needs and unique needs for the one or more personas;
“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.
and for each scenario from the plurality of scenarios, generating, by the computing device, a scenario data set comprising the name of the scenario and a list of the activities to be performed by the one or more personas, the key interactions, the series of steps, and the requirements information,
“After revising the customer design element,” i.e., with all of the data discussed above, “the revised customer design element is stored in the database 160 at step 220.” Cook ¶ 33.
wherein the scenario data set is configured to be used as a framework by a user of the scenario modeler system to identify the key interactions for each step in the scenario.
The customer design elements include “scenario elements,” which “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,” including “a detailed flow through technology and product agnostic steps for performing one or more typical tasks. Use case elements may be used to describe a function that a system performs to achieve the user’s goals. Each use case element may describe a particular goal for the user and how the user interacts with the system to achieve that goal.” Cook ¶ 17. Paragraph 27 then demonstrates how the system’s tools are used to actively identify and analyze the specific interactions.
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.
“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 55
Cook discloses the computer-implemented method of claim 51,
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 one or more hypothetical persons are data models each 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, 58, 61, and 63
Claims 57, 58, 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, 52, 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.
Claim Rejections – 35 U.S.C. § 103
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 pre-AIA 35 U.S.C. § 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 48, 49, 59, 60, and 64 are rejected under pre-AIA 35 U.S.C. § 103(a) as being unpatentable over Cook as applied to claims 43 and 51 above, and further in view of Dr. Charles B. Kreitzberg and Ambrose Little, Usability in Practice – The Power of Personas, MSDN Magazine (April 2009) available at <https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/april/the-power-of-personas>.
Claim 48
Cook teaches the scenario modeler system of claim 43, but does not explicitly anticipate the same assigning a pre-defined score value by aggregating the participating personas having goals correlated to the scenario, and producing a priority score for the scenario by scaling a number of the aggregated personas by a weight factor based on a perceived importance of success by the participating personas.
Kreitzberg, however, teaches exactly this technique, including:
correlate each scenario with participating personas and assign a pre-defined score value to each scenario by:
aggregating the participating personas having goals correlated to the scenario;
As shown in Figure 2, the Kreitzberg reference proposes using personas to help prioritize software features by combining evaluations from all of the participating personas (Elizabeth, Miranda, and Tom) into columns, and organizing their evaluations by the potential goals for each of those personas (“View Item” and “Place Order”). Kreitzberg 8 and 9.
and producing a priority score for the scenario by scaling a number of the aggregated personas by a weighing factor based on a perceived importance of success by the participating personas.
“This simple table illustrates that the View Item capability is far more important to the solution than the Place Order—from the target audience’s perspective. The weightings were established beforehand, probably through the input of marketing, sales, and product management (the business stakeholders).” Kreitzberg 9. Thus, as shown in the table, each Capability is assigned an “Overall” score, by adding the weighted values of each persona’s need for that respective feature.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Cook’s system with Kreitzberg’s technique for prioritizing potential capabilities to develop in a software solution, as discussed above. One would have been motivated to improve Cook’s system with Kreitzberg’s technique because such a technique helps with deciding “what functionality to include,” which features to prioritize, and “thinking about how your target audience would want to achieve a particular goal or task.” Kreitzberg 8.
Claim 49
Cook and Kreitzberg teach the scenario modeler system of claim 48, wherein
the priority score and underlying requirements to implement the scenario allow a user or designer to prioritize tasks.
“The core idea here is that you are using personas to consistently think through and validate the various aspects of the development cycle from the perspective of your target audience. To come to the understanding that Elizabeth values viewing items as a must-have, you have to actually put yourself in her shoes and think about how much she would value that capability. This is far superior to a business analyst, project manager, or even developer generically trying to put a value on the capability using the same scale (which I’ve observed many times in my career). And it can be used to prioritize bug fixes as well, which again would likely be far more realistic prioritization than a general sense of urgency or severity.” Kreitzberg 9.
Claims 59 and 60
Claims 59 and 60 recite a memory with the same programs that are stored on the memory of corresponding system claims 48 and 49, and are therefore rejected over the same findings and rationale as provided above for those claims.
Claim 64
Cook teaches the computer-implemented method of claim 51, but does not explicitly disclose prioritizing each scenario by a priority score based upon a number of applicable personas and a level of importance of the scenario so that each scenario is quantitatively assessed against other scenarios.
Kreitzberg, however, teaches a method comprising:
prioritizing each scenario by a priority score based upon a number of applicable personas and a level of importance of the scenario so that each scenario is quantitatively assessed against other scenarios.
As shown in Figure 2, the Kreitzberg reference proposes using personas to help prioritize software features by combining evaluations from all of the participating personas (Elizabeth, Miranda, and Tom) into columns, and organizing their evaluations by the potential goals for each of those personas (“View Item” and “Place Order”). Kreitzberg 8 and 9.
“This simple table illustrates that the View Item capability is far more important to the solution than the Place Order—from the target audience’s perspective. The weightings were established beforehand, probably through the input of marketing, sales, and product management (the business stakeholders).” Kreitzberg 9. Thus, as shown in the table, each Capability is assigned an “Overall” score, by adding the weighted values of each persona’s need for that respective feature.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve Cook’s system with Kreitzberg’s technique for prioritizing potential capabilities to develop in a software solution, as discussed above. One would have been motivated to improve Cook’s system with Kreitzberg’s technique because such a technique helps with deciding “what functionality to include,” which features to prioritize, and “thinking about how your target audience would want to achieve a particular goal or task.” Kreitzberg 8.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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