DETAILED ACTION
Status of the Application
The following is a non-Final Office Action. In response to Examiner's communication of October 6, 2025, Applicant, on November 20, 2025, amended claims 1, 8, 9, 18, & 19. Claims 1-20 are now pending in this application and have been rejected below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on November 20, 2025 has been entered.
Response to Amendment
Applicant's amendments are sufficient to overcome the 35 USC 112, second paragraph, rejections set forth in the previous action. Therefore, these rejections are withdrawn.
Applicant's amendments are not sufficient to overcome the 35 USC 101 rejections that the claims are directed to an abstract idea set forth in the previous action. Therefore, these rejections are maintained below.
Applicant's amendments render moot the 35 USC 103 rejections set forth in the previous action. Therefore, new grounds for rejection necessitated by Applicant’s amendment are set forth below.
Response to Arguments - 35 USC § 101
Applicant’s arguments with respect to the 35 USC 101 rejections for being directed to an abstract idea have been fully considered, but they are not persuasive.
Applicant argues that (1), in view of the Memorandum titled Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101 reminding Examiner’s they should only make a rejection when it is more likely than not (i.e., more than 50%) that the claim is ineligible under 35 U.S.C. 101, in the rejection alleging "could all be reasonably interpreted as a human making observations of information regarding a feature request and a price, a human performing an evaluation... and a human implementing the selected feature by the human performing a task mentally and/or with a pen and paper; therefore, the claims recite mental processes," inclusion of what the claim can recite/how alternatively the claim functions can be performed and what the human can/could do are precisely the improper considerations in broadest reasonable interpretation (BRI) that the memo is designed to guard against, and (2) the rejection has summarized the entire claim as, "Each of the above limitations manage sales and marketing activities and provide instructions or rules to follow to manage the human behavior completing feature requests based on the human behavior of people requesting features," and summarily concluded that the entire claim is this characterization and no more, and therefore the claim is directed to an abstract idea, and this manner of formulating the rejection is contrary to "Analysis of claim as a whole.” Examiner respectfully disagrees.
Pursuant to 2019 Revised Patent Subject Matter Eligibility Guidance, in order to determine whether a claim is directed to an abstract idea, under Step 2A, we first (1) determine whether the claims recite limitations, individually or in combination, that fall within the enumerated subject matter groupings of abstract ideas (mathematical concepts, certain methods of organizing human activity, or mental processes), and (2) determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55. Next, if a claim (1) recites an abstract idea and (2) does not integrate that exception into a practical application, in order to determine whether the claim recites an “inventive concept,” under Step 2B, we then determine whether any of the additional elements beyond the recited abstract idea, individually and in combination, are significantly more than the abstract idea itself. 84 Fed. Reg. 56.
Under Prong 1 of Step 2A, claim 1, and similarly claims 2-20, recites “[a] … method comprising: enabling … with a crowdsourced feature implementation, the enabling comprising: receiving a plurality of requests, the plurality of requests including a set of priced requests and an unpriced request, the set of priced requests including a feature request and a price corresponding to the feature request, wherein the priced request comprises an option to limit a visibility of at least one of (i) the feature request and (ii) the price corresponding to the feature request, wherein the option is set by an originator of the feature request, and wherein the visibility is limited by the option to one of (i) only the originator and (ii) the originator and another user; validating the feature request, the validating determining an implementation cost of the feature request; associating with the unpriced request, … for computing a price reduction for each of the plurality of requests, an estimated value as a missing price: reducing, in the data …, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the missing price to a reduced second value; computing using (i) the reduced first and second values in the data … and (ii) the implementation cost, a value for a return on investment of the feature request; selecting, using the value for the return on investment of the feature request, the feature request for implementation; and … according to the selected feature request at the reduced first value for the feature request as a result of crowdsourced aggregation of the feature request and the unpriced request.” Claims 1-20, in view of the claim limitations, recite the abstract idea of receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature.
Regarding (1) Applicant’s assertion that inclusion of what the claim can recite/how alternatively the claim functions can be performed and what the human can/could do are precisely the improper considerations in broadest reasonable interpretation (BRI) that the memo is designed to guard against, a claim recites mental processes when the claim "can be performed in the human mind, or by a human using a pen and paper,” when the claim recites “concepts performed in the human mind” (including “observations, evaluations, judgments, and opinions”), wherein “[i]f the claim, under its broadest reasonable interpretation, covers the claim being practically performed in the mind but for the recitation of generic computer components,” then the claim is in the mental process category. MPEP 2106.04(a)(2)III, 84 Fed. Reg. 52 n.14. Here, as a whole, in view of the claim limitations, but for the computer components and systems performing the claimed functions, the broadest reasonable interpretation of the recited receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature could all be reasonably interpreted as a human making observations of information regarding a feature request, a price and an option to limit visibility, a human performing an evaluation and using judgment based on the observed information to validate the request by determining an implementation cost and select the feature based on a return on investment computed using the cost and price, and a human implementing the selected feature by the human performing a task mentally and/or with a pen and paper.
Specifically with respect to Applicant’s assertion that what the claim can recite/how alternatively the claim functions can be performed and what the human can/could do is somehow improper, Examiner’s explanation of why the claims recite mental processes is specifically a reference to the definitions of mental processes in the MPEP and Federal Register describing that mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea the claim and a mental process covers the claim being practically performed in the mind but for the recitation of the generic computer components. See MPEP 2106.04(a)(2)III, 84 Fed. Reg. 52 n.14 (emphasis added). Therefore, contrary to Applicant’s assertions, the claims recite a mental process in view of the definitions and standards required by the USPTO set forth in the MPEP and Federal Register.
Regarding (2) Applicant’s assertion Examiner’s rejection that summarily concluded that the entire claim is this characterization and no more, a claim recites certain methods of organizing human activity when the claim recites fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions). MPEP 2106.04(a)(2)II, 84 Fed. Reg. at 52 (emphasis added). Here, in the present claims, each of the above limitations manage sales and marketing activities of receiving requests and determining and computing costs, price, reduced price, return on investment of feature, selecting a feature based on the return on investment, and implementing the selected feature of the request at the computed price, and further, these limitations provide instructions or rules to follow to manage the human behavior implementing feature requests based on the human behavior of people requesting features and selecting to limit visibility of the price.
Specifically with respect to Applicant’s assertion that Examiner’s rejection that summarily concluded that the entire claim is this characterization and no more, Applicant’s assertion mischaracterizes Examiner’s rejection and quotes merely one sentence while ignoring the vast majority of the nearly four page rejection. The one sentence quoted by Applicant in prong 1 of Step 2A specifically references the limitations an earlier paragraph of prong 1 of Step 2A that is ignored by Applicant that specifically identifies each of the limitations in detail that recite a certain method of organizing human activity, and this one sentence referred to by Applicant is an explanation of why the identified limitations recite a certain method of organizing human activity. Examiner’s explanation is a specific reference to the definition of a certain method organizing activity set forth in the MPEP and Federal Register describing a certain method of organizing human activity includes commercial or legal interactions, including marketing or sales activities or behaviors, and managing personal behavior or relationships or interactions between people, including following rules or instructions. See MPEP 2106.04(a)(2)II, 84 Fed. Reg. at 52. Accordingly, despite Applicant’s mischaracterization of the rejection, the claims recite a certain method of organizing human activity in view of the definitions and standards required by the USPTO set forth in the MPEP and Federal Register.
Accordingly, despite Applicant’s assertions, since the claims recite a certain method of organizing human activity and mental processes, the claims recite an abstract idea under the first prong of Step 2A.
Applicant argues that Examiner should reconsider and withdraw the present rejection under § 101 in consideration of the Appeals Review Panel’s (ARP) reasoning in Ex Parte Desjardins because the instant claims clearly and unequivocally recite logical structures and processes that have been recognized as sufficient for patent-eligibility by Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1339 (Fed. Cir. 2016) as well as the ARP in Ex parte Desjardins and the instant claims are simultaneously rejected under §103, as was the case in Id. and which the ARP expressly calls as traditional, appropriate, and proper tools for limiting patent protection, not §101. Examiner respectfully disagrees.
Unlike the claims at issue in Enfish and Ex parte Desjardins, the present claims are not directed to an improvement in computer technology. The claims do not address a problem specifically arising in computer technology and the claimed solution is not necessarily rooted in computer technology, but rather the claims address the problem of determining costs, price, reduced price, return on investment of product feature in response to feature requests and selecting a product feature to implement based on the return on investment, which is a business problem addressed by business when deciding to produce a product and a price that should be charged for the product long before the advent of computers. Adding the generic recitation of “software development management system,” “in data stored in a memory device,” and “generating code of a software feature” provide nothing more than implementing the abstract idea using generic computer components and generally linking the abstract idea to a field of use, which does not make the claims directed to an improvement in computer technology and is not otherwise sufficient to transform an abstract idea into a patent eligible invention.
With respect to Applicant’s assertion that Examiner should withdraw the present rejection because the instant claims are simultaneously rejected under §103, which is the traditional, appropriate, and proper tool for limiting patent protection, not §101, the search for an inventive concept under § 101 is distinct from demonstrating novel and non-obviousness. See SAP America Inc. v. Investpic, LLC, No. 2017-2081, slip op. at 2-3 (Fed Cir. May 15, 2018) (citing Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1315 (Fed. Cir. 2016). Even novel and newly discovered judicial exceptions are still exceptions, despite their novelty. July 2015 Update, p. 3; see SAP America at 2. As discussed in SAP America, no matter how much of an advance the claims recite, when “the advance lies entirely in the realm of abstract ideas, with no plausibly alleged innovation in the non-abstract application realm,” “[a]n advance of that nature is ineligible for patenting.” Id. at 3. In Step 2B, “[w]hat is needed is an inventive concept in the non-abstract application realm.” Id. at 11. For the reasons set forth below, the claimed invention is directed to an abstract idea without significantly more, and thus, the claims must be rejected under 35 U.S.C. 101.
Applicant argues the integrate alleged abstract ideas into a practical application, provide a specific technological improvement solving a technical problem, and deliver a concrete benefit because the claimed invention is directed to an improvement to computer-related technology, specifically, "software development management system" by reciting "enabling a software development management system with a crowdsourced feature implementation,” "associating with the unpriced request, in data stored in a memory device and configured for computing a price reduction for each of the plurality of requests, an estimated value as a missing price [i.e., manipulating], in data stored in a memory device and configured for computing a price reduction [i.e., a computer data structure] configured for computing a price reduction for each of the plurality of requests [i.e., manipulating] associating...an estimated value as a missing price [i.e., outputting]... reducing, in the data stored in the memory device, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the missing price to a reduced second value [i.e., a specifically designed non-generic operation of a non-generic computer, a modification of a specific technological solution not performable as a mental exercise even with the aid of pen and paper] generating code of a software feature according to the selected feature request at the reduced first value for the feature request as a result of crowdsourced aggregation of the feature request and the unpriced request [i.e., an improvement of a technological field of endeavor].” Examiner respectfully disagrees.
As noted above, pursuant to 2019 Revised Patent Subject Matter Eligibility Guidance, in order to determine whether a claim is directed to an abstract idea, under Step 2A, we first (1) determine whether the claims recite limitations, individually or in combination, that fall within the enumerated subject matter groupings of abstract ideas (mathematical concepts, certain methods of organizing human activity, or mental processes), and (2) determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55. Next, if a claim (1) recites an abstract idea and (2) does not integrate that exception into a practical application, in order to determine whether the claim recites an “inventive concept,” under Step 2B, we then determine whether any of the additional elements beyond the recited abstract idea, individually and in combination, are significantly more than the abstract idea itself. 84 Fed. Reg. 56.
Aside from the generic recitations of generic computer components referred to by Applicant of “software development management system,” “in data stored in a memory device,” and “generating code of a software feature” that provide nothing more than implementing the abstract idea using generic computer components and generally linking the abstract idea to a field of use, each of the remaining features referred to by Applicant are not additional elements beyond the recited abstract idea, but rather the elements referred to by Applicant are abstract elements that are part of the recited abstract idea because these aside from the aforementioned generic computer components, the features referred to by Applicant recite certain methods of organizing human activity that manage sales and marketing activity of pricing features of a product and also recite mental processes that can be performed mentally observing information, preforming an evaluation, and using judgement to generate prices mentally and/or with a pen and paper.
Specifically, under Prong 1 of Step 2A, claim 1, and similarly claims 2-20, recites recites “[a] … method comprising: enabling … with a crowdsourced feature implementation, the enabling comprising: receiving a plurality of requests, the plurality of requests including a set of priced requests and an unpriced request, the set of priced requests including a feature request and a price corresponding to the feature request, wherein the priced request comprises an option to limit a visibility of at least one of (i) the feature request and (ii) the price corresponding to the feature request, wherein the option is set by an originator of the feature request, and wherein the visibility is limited by the option to one of (i) only the originator and (ii) the originator and another user; validating the feature request, the validating determining an implementation cost of the feature request; associating with the unpriced request, … for computing a price reduction for each of the plurality of requests, an estimated value as a missing price: reducing, in the data …, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the missing price to a reduced second value; computing using (i) the reduced first and second values in the data … and (ii) the implementation cost, a value for a return on investment of the feature request; selecting, using the value for the return on investment of the feature request, the feature request for implementation; and … according to the selected feature request at the reduced first value for the feature request as a result of crowdsourced aggregation of the feature request and the unpriced request.” Claims 1-20, in view of the claim limitations, recite the abstract idea of receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature.
Each of the above limitations manage sales and marketing activities of receiving requests and determining and computing costs, price, reduced price, return on investment of feature, selecting a feature based on the return on investment, and implementing the selected feature of the request at the computed price, and further, these limitations provide instructions or rules to follow to manage the human behavior implementing feature requests based on the human behavior of people requesting features and selecting to limit visibility of the price; thus, the claims recite certain methods of organizing human activity. In addition, as a whole, in view of the claim limitations, but for the computer components and systems performing the claimed functions, the broadest reasonable interpretation of the recited receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature could all be reasonably interpreted as a human making observations of information regarding a feature request, a price and an option to limit visibility, a human performing an evaluation and using judgment based on the observed information to validate the request by determining an implementation cost and select the feature based on a return on investment computed using the cost and price, and a human implementing the selected feature by the human performing a task mentally and/or with a pen and paper; therefore, the claims recite mental processes.
Accordingly, since the claims recite a certain method of organizing human activity and mental processes, the claims recite an abstract idea under the first prong of Step 2A.
Under Prong 2 of Step 2A, the claims recite the additional elements beyond the recited abstract idea of “[a] computer-implemented method,” “enabling a software development management system,” “in data stored in a memory device,” and “generating code of a software feature“ in claim 1, and similarly claims 9 and 19; however, individually and when viewed as an ordered combination, and pursuant to the broadest reasonable interpretation, each of the additional elements are computing elements recited at high level of generality implementing the abstract idea on a computer (i.e. apply it), and thus, are no more than applying the abstract idea with generic computer components. Further, with respect to the additional element beyond the recited abstract idea of “generating code of a software feature“ recited in claim 1, 9, & 19, this limitation also merely generally links the abstract idea to generic technical field of use.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception under Step 2B. As noted above, the aforementioned additional elements beyond the recited abstract idea, as an order combination, are no more than mere instructions to implement the idea using generic computer components (i.e. apply it), and further, generally link the abstract idea to a field of use, which is not sufficient to amount to significantly more than an abstract idea; therefore, the additional elements are not sufficient to amount to significantly more than an abstract idea. Additionally, these recitations as an ordered combination, simply append the abstract idea to recitations of generic computer structure performing generic computer functions that are well-understood, routine, and conventional in the field as evinced by Applicant’s Specification at [0054]-[0056], [0060]-[0061] (describing the present invention can be implemented by a computer environment including a desktop computer or any form of computer known or to be developed, any type of processor known or to be developed, any type of memory known or to be developed, and any type of non-volatile persistent storage known or to be developed). Furthermore, as an ordered combination, these elements amount to generic computer components performing repetitive calculations, receiving or transmitting data over a network, which, as held by the courts, are well-understood, routine, and conventional. See MPEP 2106.05(d); July 2015 Update, p. 7.
Looking at these limitations as an ordered combination adds nothing additional that is sufficient to amount to significantly more than the recited abstract idea because they simply provide instructions to use a generic arrangement of generic computer components and recitations of generic computer structure that perform well-understood, routine, and conventional computer functions that are used to “apply” the recited abstract idea. Thus, the elements of the claims, considered both individually and as an ordered combination, are not sufficient to ensure that the claims as a whole amount to significantly more than the abstract idea itself.
Response to Arguments - Prior Art
Applicant’s arguments with respect to the 35 USC 101 rejections for being directed to an abstract idea have been fully considered, but they are now moot in view of new grounds for rejection necessitated by Applicant’s amendments.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1, and similarly claims 2-20, recites “[a] … method comprising: enabling … with a crowdsourced feature implementation, the enabling comprising: receiving a plurality of requests, the plurality of requests including a set of priced requests and an unpriced request, the set of priced requests including a feature request and a price corresponding to the feature request, wherein the priced request comprises an option to limit a visibility of at least one of (i) the feature request and (ii) the price corresponding to the feature request, wherein the option is set by an originator of the feature request, and wherein the visibility is limited by the option to one of (i) only the originator and (ii) the originator and another user; validating the feature request, the validating determining an implementation cost of the feature request; associating with the unpriced request, … for computing a price reduction for each of the plurality of requests, an estimated value as a missing price: reducing, in the data …, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the missing price to a reduced second value; computing using (i) the reduced first and second values in the data … and (ii) the implementation cost, a value for a return on investment of the feature request; selecting, using the value for the return on investment of the feature request, the feature request for implementation; and … according to the selected feature request at the reduced first value for the feature request as a result of crowdsourced aggregation of the feature request and the unpriced request.” Claims 1-20, in view of the claim limitations, recite the abstract idea of receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature.
Each of the above limitations manage sales and marketing activities of receiving requests and determining and computing costs, price, reduced price, return on investment of feature, selecting a feature based on the return on investment, and implementing the selected feature of the request at the computed price, and further, these limitations provide instructions or rules to follow to manage the human behavior implementing feature requests based on the human behavior of people requesting features and selecting to limit visibility of the price; thus, the claims recite certain methods of organizing human activity. In addition, as a whole, in view of the claim limitations, but for the computer components and systems performing the claimed functions, the broadest reasonable interpretation of the recited receiving a feature request including priced and unpriced requests with an option to limit visibility of the request and/or price set by the originator and/or another party, validating the request including determining an implementation cost, associating the unpriced request with an estimated price, reducing the price of the priced and unpriced requests, computing a return on investment using the reduced price, selecting the feature for implementation based on a return on investment computed using the cost and price, and implementing the selected feature could all be reasonably interpreted as a human making observations of information regarding a feature request, a price and an option to limit visibility, a human performing an evaluation and using judgment based on the observed information to validate the request by determining an implementation cost and select the feature based on a return on investment computed using the cost and price, and a human implementing the selected feature by the human performing a task mentally and/or with a pen and paper; therefore, the claims recite mental processes. Further, with respect to the dependent claims, aside from the additional elements beyond the recited abstract idea addressed below under the second prong of Step 2A and 2B, the limitations of dependent claims 2-8, 10-18, & 20 recite similar further abstract limitations to those discussed above that narrow the abstract idea recited in the independent claims because, aside from the computer components and systems performing the claimed functions the limitations of claims recite mental processes that can be practically performed mentally by observing, evaluating, and judging information mentally and/or with a pen and paper and recite a certain method of organizing human activity that manages business interactions and the sales and marketing activity. Accordingly, since the claims recite a certain method of organizing human activity and mental processes, the claims recite an abstract idea under the first prong of Step 2A.
This judicial exception is not integrated into a practical application under the second prong of Step 2A. In particular, the claims recite the additional elements beyond the recited abstract idea of “[a] computer-implemented method,” “enabling a software development management system,” “in data stored in a memory device,” and “generating code of a software feature“ in claim 1, “[a] computer program product comprising one or more computer readable storage medium, and program instructions collectively stored on the one or more computer readable storage medium, the program instructions executable by a processor to cause the processor to perform operations comprising,” “enabling a software development management system,” “in data stored in a memory device,” and “generating code of a software feature“ in claim 9, “[a] computer system comprising a processor and one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions executable by the processor to cause the processor to perform operations comprising,” “enabling a software development management system,” “in data stored in a memory device,” and “generating code of a software feature“ in claim 19; however, individually and when viewed as an ordered combination, and pursuant to the broadest reasonable interpretation, each of the additional elements are computing elements recited at high level of generality implementing the abstract idea on a computer (i.e. apply it), and thus, are no more than applying the abstract idea with generic computer components. Further, with respect to the additional element beyond the recited abstract idea of “generating code of a software feature“ recited in claim 1, 9, & 19, this limitation also merely generally links the abstract idea to generic technical field of use. Moreover, aside from the aforementioned additional elements, the remaining elements of dependent claims 2-8, 10-18, & 20 do not integrate the abstract idea into a practical application because these claims merely recite further limitations that provide no more than simply narrowing the recited abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception under Step 2B. As noted above, the aforementioned additional elements beyond the recited abstract idea, as an order combination, are no more than mere instructions to implement the idea using generic computer components (i.e. apply it), and further, generally link the abstract idea to a field of use, which is not sufficient to amount to significantly more than an abstract idea; therefore, the additional elements are not sufficient to amount to significantly more than an abstract idea. Additionally, these recitations as an ordered combination, simply append the abstract idea to recitations of generic computer structure performing generic computer functions that are well-understood, routine, and conventional in the field as evinced by Applicant’s Specification at [0054]-[0056], [0060]-[0061] (describing the present invention can be implemented by a computer environment including a desktop computer or any form of computer known or to be developed, any type of processor known or to be developed, any type of memory known or to be developed, and any type of non-volatile persistent storage known or to be developed). Furthermore, as an ordered combination, these elements amount to generic computer components performing repetitive calculations, receiving or transmitting data over a network, which, as held by the courts, are well-understood, routine, and conventional. See MPEP 2106.05(d); July 2015 Update, p. 7. Moreover, aside from the aforementioned additional elements, the remaining elements of dependent claims 2-8, 10-18, & 20 do not transform the recited abstract idea into a patent eligible invention because these claims merely recite further limitations that provide no more than simply narrowing the recited abstract idea.
Looking at these limitations as an ordered combination adds nothing additional that is sufficient to amount to significantly more than the recited abstract idea because they simply provide instructions to use a generic arrangement of generic computer components and recitations of generic computer structure that perform well-understood, routine, and conventional computer functions that are used to “apply” the recited abstract idea. Thus, the elements of the claims, considered both individually and as an ordered combination, are not sufficient to ensure that the claims as a whole amount to significantly more than the abstract idea itself. Since there are no limitations in these claims that transform the exception into a patent eligible application such that these claims amount to significantly more than the exception itself, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 9-11, & 19 are rejected under 35 U.S.C. 103 as being unpatentable over Batca, et al. (US 20180025306 A1), hereinafter Batca, in view of Cao, et al. (US 20090222319 A1), hereinafter Cao, in further view of Mohsen (US 20210090168 A1), hereinafter Mohsen.
Regarding claim 1, Batca discloses a computer-implemented method comprising enabling a software development management system with a crowdsourced feature implementation, the enabling comprising: (Abstract, [0003], [0012]):
receiving a plurality of requests, the plurality of requests including a set of priced requests …, the set of priced requests including a feature request and a price corresponding to the feature request ([0032], [0040], the roadmap server 105 running the decision analysis tool 110 may perform one or more of the functions described herein, including: obtaining cost/benefit data about each offering, wherein the cost/benefit data is e.g., the sales data, [0034], [0053], an enterprise user may input sales data into their user device 125a communicated from the user device 125a to the sales server 115, where in the sales data may be revenue of the item, wherein the of a sales item is a new software program requested by a client of the enterprise and may include data such as: software program identifier and sales revenue of the software program, [0044], an enterprise user communicates with a group of customers and determines from customer input that a software enhancement is desired in the market, and the user provides input to a user device 125a to define sales data of a sales item for the software enhancement in the database of the sales server 115), …;
validating the feature request, the validating determining an implementation cost of the feature request ([0034], [0053], an enterprise user may input sales data into their user device 125a communicated from the user device 125a to the sales server 115, where in the sales data may be revenue of the item development cost of the item; testing cost of the item; delivery cost of the item; post-sale debugging cost of the item);
associating with the … request, in data stored in a memory device configured for computing a price reduction for each of the plurality of requests, an estimated value as a … price;
reducing, in the data stored in the memory device, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the … price to a reduced second value ([0051], the sales data for sales items associated with a sales offering my include discounts that are offered by the sales team to bring more money to the front of the agile development iteration, offering a discount for the up-front payment);
computing using (i) the reduced first and second values in the data stored in the memory device and (ii) the implementation cost, a value for a return on investment of the feature request ([0012], [0014], a score (e.g., a monetary score) is determined for each offering using cost/benefit data associated with items that are linked to the respective offerings, a ranked list of the offerings may be updated in real time according to the updated scores of the various offerings, and the ranked list of offerings may be used by the enterprise in the decision making process of determining the most promising offerings (e.g., in monetary terms of return on investment) for which to allocate development resources, wherein the cost/benefit data used to determine the score of each offering may include at least one selected from the group consisting of: development cost; testing cost; delivery cost; revenue of the offering; discounts, [0032], after obtain cost/benefit data about each offering, the decision analysis tool 110 may generate a score (e.g., monetary score) for each offering based on the cost/benefit data; generate a list of the offerings ranked according to score, [0038], [0041], the decision analysis tool 110 generates a score (e.g., a monetary score) for each offering in the ranked list using the sales data/based on the cost/benefit data (e.g., sales data associated with sales items linked to the offering), [0046], the system computes a return on investment using an estimate of the implementation cost of the recommendation);
selecting, using a return on investment of the feature request, the feature request for implementation ([0038], [0041], the decision analysis tool 110 generates a score (e.g., a monetary score) for each offering in the ranked list using the sales data/based on the cost/benefit data (e.g., sales data associated with sales items linked to the offering), and the ranked list of offerings may be used by the enterprise in the decision making process of determining the most promising offerings (e.g., in monetary terms of return on investment) for which to allocate development resources, [0049], the highest ranked offering being selected as the next developed offering in the enterprise, [0066], the method further includes selecting for investment the highest ranking items on the list at the time of selection; and reselecting a new item that comes on the list at a higher rank if development has not already begun on the previously selected item); and
generating code of a software feature ([0034], an example of a sales item is a new software program that is requested by a client of the enterprise, [0044], the sales item may be for a software enhancement) according to the selected feature request at the reduced first value for the feature request as a result of crowdsourced aggregation of the feature request and the unpriced request ([0047], as soon as recommendations (e.g., offerings) are created or updated, the development team can use the system to: select one recommendation for implementation and enter the actual cost of implementation; alert the team that the recommendation has been implemented).
While Batca discloses all of the above, including receiving a plurality of requests, the plurality of requests including a set of priced requests …, the set of priced requests including a feature request and a price corresponding to the feature request …; …
associating with the … request, in data stored in a memory device configured for computing a price reduction for each of the plurality of requests, an estimated value as a … price;
reducing, in the data stored in the memory device, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the … price to a reduced second value (as above), Batca does not necessarily disclose the following remaining elements, which however, are taught by further teachings in Cao.
Cao teaches receiving a plurality of requests, the plurality of requests including a set of priced requests and an unpriced request, the set of priced requests including a feature request and a price corresponding to the feature request ([0037], at 214, self-pricing is determined, e.g., given the usage forecast, the cost of provider and provider's desired profit margin, the consumer may choose usage intervals, and the system can calculate one or more prices for each interval, and similarly, the consumer may input several prices, and the system and method of the present disclosure can propose the usage range at each price) …; …
associating with the unpriced request, in data stored in a memory device configured for computing a price reduction for each of the plurality of requests, an estimated value as a missing price;
reducing, in the data stored in the memory device, a value corresponding to the price to a reduced first value and reducing the estimated value corresponding to the missing price to a reduced second value ([0044], [0046], the piecewise pricing model of the present disclosure may calculate incentive per schedule attainment, e.g., given a price incentive (e.g., less 10% of reference price), consumers may be willing to accept later completion date of service).
Batca and Cao are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering software products to customers. At the time the invention was effectively filed, it would have been obvious to one of ordinary skill in the art to include in the system of Batca the ability to receive and reduce a plurality of requests including a set of priced requests and an unpriced request, as taught by Walker, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the combination would produce the predictable results of receiving and reducing a plurality of requests including a set of priced requests and an unpriced request, as claimed. Further, it would have been obvious to one of ordinary skill in the art to have modified Batca with the aforementioned teachings of Cao in order to produce the added benefit of providing better and more accurate pricing and resulting in much improved profit. [0014].
Further, While Batca discloses all of the above, including receiving a plurality of requests (as above), Batca does not necessarily disclose the following remaining elements, which however, are taught by further teachings in Mohsen.
Mohsen teaches receiving a plurality of requests, wherein the priced request comprises an option to limit a visibility of at least one of (i) the feature request and (ii) the price corresponding to the feature request, wherein the option is set by an originator of the feature request, and wherein the visibility is limited by the option to one of (i) only the originator and (ii) the originator and another user ([0075], a buyer 101A may choose to not have their buyer identifier of their buyer identifier data record 152 displayed with a buy offer they provided to the system 100 when the system 100 displays the available sell offers and/or buy offers, [0081], hidden buy offer 148 may be provided by a second buyer 101A (may be the same or different as the first buyer 101A) via a communication engine 131, wherein the hidden buy offer 148 may have a hidden buy offer 148 price 149A, hidden buy offer quantity 149B and/or buyer identifier 152 that may not be displayed to the user 101 based on input received from the second buyer 101A when the user 101 submits a query to the system 100 for the first deliverable 141).
Batca and Mohsen are analogous fields of invention because both address the problem of determining price of offering products, including software products to customers. At the time the invention was effectively filed, it would have been obvious to one of ordinary skill in the art to include in the system of Batca the ability to receive a plurality of requests including an option to limit a visibility, as taught by Mohsen, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately,