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, and one of ordinary skill in the art would have recognized that the combination would produce the predictable results of receiving a plurality of requests including an option to limit a visibility, 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 Mohsen in order to produce the added benefit of reducing the challenge of buying and selling deliverables for both buyers and sellers and addressing the need for novel methods for exchanging deliverables, and allowing a plurality of users to confidently complete transactions and exchange deliverables. [0003], [0007].
Regarding claim 9, this claim is substantially similar to claim 1, and is, therefore, rejected on the same basis as claim 1. While claim 9 is directed to a computer program product comprising computer readable storage medium and program instructions collectively stored on the readable storage medium executable by a processor to cause the processor to perform operations, Batca discloses a computer program product, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Regarding claim 10, the combined teachings of Batca, Cao, and Mohsen teach the computer program product of claim 9 (as above). Further, Batca discloses wherein the stored program instructions are stored in a computer readable storage device in a data processing system, and wherein the stored program instructions are transferred over a network from a remote data processing system ([0017]-[0018], computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network, a network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device, and the computer readable program instructions may execute partly on the user's computer and partly on a remote computer or entirely on the remote computer or server).
Regarding claim 11, the combined teachings of Batca, Cao, and Mohsen teach the computer program product of claim 9 (as above). Further, Batca discloses wherein the stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded in response to a request over a network to a remote data processing system for use in a computer readable storage device associated with the remote data processing system ([0017]-[0018], computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network, a network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device, and the computer readable program instructions may execute partly on the user's computer and partly on a remote computer or entirely on the remote computer or server), further comprising: program instructions to meter use of the program instructions associated with the request; and program instructions to generate an invoice based on the metered use ([0067], a service provider, such as a Solution Integrator, could offer to perform the processes described herein, and the service provider can create, maintain, deploy, support, etc., the computer infrastructure that performs the process steps of the invention for one or more customers, these customers may use technology, and in return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement).
Regarding claim 19, this claim is substantially similar to claim 1, and is, therefore, rejected on the same basis as claim 1. While claim 19 is directed to a computer system comprising a processor and computer readable storage media storing program instructions executable by the processor to cause the processor to perform operations comprising, Batca discloses a system, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Claims 2-4, 12-14, & 20 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, and Desai, et al. (US 20100228604 A1), hereinafter Desai.
Regarding claim 2, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 1 (as above). Further, while Batca discloses further comprising: determining, using a … similarity analysis, that the feature request and a second feature request have … similarity to each other ([0046], the automated linking of an item to an offering, wherein the support engineer opens a recommendation (e.g., creates an offering) targeting the development team to improve the error message of a problem ticket from a client of the enterprise, the system then operates to: link the current problem ticket to the offering; search for existing problem tickets associated with the same error message, discovering that there have been five similar problem tickets a month for the past year for this same confusing error message); and aggregating, into the feature request, the second feature request ([0046], the system operates to: search for existing problem tickets associated with the same error message, discovering that there have been five similar problem tickets a month for the past year for this same confusing error message; link the identified problem tickets associated with this particular error message to the recommendation (e.g., offering); update the potential value (e.g., score) of the recommendation based on the data associated with the newly linked problem tickets; optionally compute a return on investment using an estimate of the implementation cost of the recommendation; optionally alert the target team in the event the computed return on investment exceeds a predefined threshold value for identifying promising recommendations), Batca does not necessarily expressly disclose the similarity is determined using a natural language processing similarly analysis, which however, are taught by further teachings Desai.
Desai teaches determining, using a natural language similarity analysis, that the feature request and a second feature request have above a threshold similarity to each other (Abstract, [0084], [0124]-[0128], the system receives demand group modeling data including a product listing, available econometric data and product information, attributes may then be assigned to the products based upon product identifiers, size, flavor, brand, and product descriptions utilizing natural language processing, the products may then be clustered according to the attributes, a confidence score may be generated for each product indicating how well that product fits within the demand group, these confidence scores may be compared against a threshold, and products with scores below the threshold may be flagged for user review, wherein this occurs when the product attribute information is insufficient to accurately determine which group to assign the given product to); and aggregating, into the feature request, the second feature request ([0124]-[0128], after clustering of products according to a threshold of similarity between product attributes, rules are applied to the product clusters to generate the demand groups, and these demand groups may be provided to downstream price optimization systems for the generation of optimized prices).
Batca and Desai are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 determine, using a natural language similarity analysis, that the feature request and a second feature request have above a threshold similarity to each other, and aggregate, into the feature request, the second feature request, as taught by Desai, 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 determining, using a natural language similarity analysis, that the feature request and a second feature request have above a threshold similarity to each other, and aggregating, into the feature request, the second feature 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 Desai in order to produce the added benefit of properly pricing these products and increase revenue while reducing costs. [0005]-[0006].
Regarding claim 3, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 2 (as above). Further, while Batca discloses wherein aggregating, into the feature request, the second feature request ([0046]-[0047], the system operates to: search for existing problem tickets associated with the same error message, discovering that there have been five similar problem tickets a month for the past year for this same confusing error message; link the identified problem tickets associated with this particular error message to the recommendation (e.g., offering); update the potential value (e.g., score) of the recommendation based on the data associated with the newly linked problem tickets) comprises adding a second price corresponding to the second feature request to the price, a sum of the second price and the price used in computing the return on investment of the feature request ([0044], the user determines from customer input that a software enhancement is desired in the market and determines that the enterprise could sell the software enhancement immediately to three customers resulting in a particular estimated revenue over a time period, [0047], as soon as recommendations (e.g., offerings) are created, the development team can use the system to: compute actual extra revenue/profit associated with the tasks in the same category as those linked to the recommendation), Desai teaches the following claim limitations.
Desai teaches wherein aggregating, into the feature request, the second feature request ([0124]-[0128], after clustering of products according to a threshold of similarity between product attributes, rules are applied to the product clusters to generate the demand groups, and these demand groups may be provided to downstream price optimization systems for the generation of optimized prices) comprises adding a second price corresponding to the second feature request to the price, a sum of the second price and the price used in computing the return on investment of the feature request ([0128], these demand groups may be provided to downstream price optimization systems for the generation of optimized prices [0066], an optimization engine computes an optimal set of prices that meet a rule, wherein if the rule specifies the maximization of profit, the optimization engine would find a set of prices that cause the largest difference between the total sales and the total cost of all products being measured).
Batca and Desai are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 aggregate, into the feature request, the second feature request comprises adding a second price corresponding to the second feature request to the price, a sum of the second price and the price used in computing the return on investment of the feature request, as taught by Desai, 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 aggregating, into the feature request, the second feature request comprises adding a second price corresponding to the second feature request to the price, a sum of the second price and the price used in computing the return on investment of the feature 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 Desai in order to produce the added benefit of properly pricing these products and increase revenue while reducing costs. [0005]-[0006].
Regarding claim 4, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 3 (as above). Further, while Batca discloses wherein the second price is an estimated price ([0044], the user determines from customer input that a software enhancement is desired in the market and determines that the enterprise could sell the software enhancement immediately to three customers resulting in a particular estimated revenue over a time period, [0046]-[0047], the system operates to: search for existing problem tickets associated with the same error message, discovering that there have been five similar problem tickets a month for the past year for this same confusing error message; link the identified problem tickets associated with this particular error message to the recommendation (e.g., offering); update the potential value (e.g., score) of the recommendation based on the data associated with the newly linked problem tickets, and as soon as recommendations (e.g., offerings) are created, the development team can use the system to: compute extra revenue/profit associated with the tasks in the same category as those linked to the recommendation), Desai teaches the following claim limitations.
Desai teaches wherein the second price is an estimated price ([0128], these demand groups may be provided to downstream price optimization systems for the generation of optimized prices, [0066], an optimization engine computes an optimal set of prices that meet a rule, wherein if the rule specifies the maximization of profit, the optimization engine would find a set of prices that cause the largest difference between the total sales and the total cost of all products being measured).
Batca and Desai are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 for the second price to be an estimated price, as taught by Desai, 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 the second price being an estimated price, 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 Desai in order to produce the added benefit of properly pricing these products and increase revenue while reducing costs. [0005]-[0006].
Regarding claims 12-14, these claims are substantially similar to claim 2-4, and are, therefore, rejected on the same basis as claims 2-4. While claims 12-14 are directed to a computer program product comprising computer readable storage medium and program instructions collectively stored on the readable storage medium executable by a processor to cause the processor to perform operations, Batca discloses a computer program product, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Regarding claim 20, this claim is substantially similar to claim 2, and is, therefore, rejected on the same basis as claim 2. While claim 20 is directed to a computer system comprising a processor and computer readable storage media storing program instructions executable by the processor to cause the processor to perform operations comprising, Batca discloses a system, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Claims 5 & 15 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, and Walker, et al. (US 20140224878 A1), hereinafter Walker.
Regarding claim 5, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 1 (as above). Further, while Batca discloses further comprising: determining that the return on investment is above a cap value; and … the return on investment to a value less than the cap value ([0046], the system operates to: the potential value (e.g., score) of the recommendation based on the data associated with the newly linked problem tickets; compute a return on investment using an estimate of the implementation cost of the recommendation; optionally alert the target team in the event the computed return on investment exceeds a predefined threshold value for identifying promising recommendations), Batca does not necessarily expressly disclose reducing the return on investment to a value less than the cap, which however, are taught by further teachings Walker.
Walker teaches determining that the return on investment is above a cap value; and reducing, by reducing the price, the return on investment to a value less than the cap value ([0098]-[0099] at step 806A, it is determined whether the profit margin for the primary product is high. Of course, the definition of a high profit margin is relative, e.g., a retailer may set a threshold amount at or above which the profit margin is to be considered high and below which the profit margin is considered to be low, and if the profit margin of the primary product is determined to be sufficiently high, a more deeply discounted package price is calculated at step 807A, a threshold amount or percentage or a range of acceptable amount or percentages within which the package profit margin is to be considered acceptable, and at step 810A, a determination is made as to whether the profit margin of the package is acceptable to the retailer).
Batca and Walker are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 determine that the return on investment is above a cap value; and reduce, by reducing the price, the return on investment to a value less than the cap value, 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 determining that the return on investment is above a cap value; and reducing, by reducing the price, the return on investment to a value less than the cap value, 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 Walker in order to produce the added benefit of encouraging customers to increase expenditures per visit to a retail establishment. [0003].
Regarding claim 15, this claim is substantially similar to claim 5, and is, therefore, rejected on the same basis as claim 5. While claim 15 is directed to a computer program product comprising computer readable storage medium and program instructions collectively stored on the readable storage medium executable by a processor to cause the processor to perform operations, Batca discloses a computer program product, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Claims 6-8 & 16-18 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, and Alexa, et al. (US 20220147988 A1), hereinafter Alexa.
Regarding claim 6, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 1 (as above). Further, while Batca discloses further comprising: proposing, subsequent to the selecting, an automated transaction in which completion of implementation of the feature request triggers … ([0012], 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, [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; [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), Batca does not necessarily expressly disclose the remaining following limitations, which however, are taught by further teachings Alexa.
Alexa teaches further comprising: proposing, subsequent to the selecting, an automated transaction in which completion of implementation of the feature request triggers payment of the price ([0030], campaign server may create a blockchain ledger, with an initial block in the chain being directed to the details of the product, the blockchain ledger includes a smart contract identifying terms and conditions for the sale or pre-sell of the product, and buyers may visit the campaign server to review the product, a buyer that desires to purchase the product may submit a purchase order, including a purchase quantity, [0115], the buyer—from regions preselected by the brand company, receives the brand's product information on the platform's “new products page” and enters the desired order contract quantity 205, the surety amount of the required #n tokens is then transferred from the buyer's wallet towards the contract, and when the green-light Campaign™ event is a success and the product quantity quota has been met by one or more buyers, winning participants to this deal or contracts are notified by the platform, [0120], in 501, a buyer requests a transaction with a brand company. A transaction can involve cryptocurrency); and recording, subsequent to receiving an approval of the automated transaction, the automated transaction in a distributed ledger ([0030], the campaign server may update the blockchain ledger with the buyer's information, including the purchase quantity, and the blockchain ledger may be updated for each buyer that submits a purchase order to the campaign server, [0115], winning participants to this deal or contracts are notified by the platform and the remaining funds (the remaining funds is the originally agreed amount minus the surety amount) are transferred from buyers' wallets/electronic accounts to the smart contract, wired or debited in currency directly from buyers' financial account, within a specified time, and the smart contract executes and transfers funds to respective wallets of brand company and the company sponsoring the platform, [0120], in 502, the requested transaction is broadcast to a P2P network of computers known as nodes, each with a copy of a ledger that contains blocks of transactions, in 503, the network validates the transaction using known algorithms, in 504, once verified, the transaction is combined with the other transactions to create a new block of data in the electronic distributed ledger, and in 505, the transaction is deemed complete and the blockchain has a permanent record of the entire transaction between the buyer and the brand company).
Batca and Alexa are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 propose, subsequent to the selecting, an automated transaction in which completion of implementation of the feature request triggers payment of the price, and record, subsequent to receiving an approval of the automated transaction, the automated transaction in a distributed ledger, as taught by Alexa, 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 proposing, subsequent to the selecting, an automated transaction in which completion of implementation of the feature request triggers payment of the price, and recording, subsequent to receiving an approval of the automated transaction, the automated transaction in a distributed ledger, 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 Alexa in order to produce the added benefit of improving the accuracy and accessibility of purchase records and the ease of use and efficiency of contract enforcement. [0034], [0183].
Regarding claim 7, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 6 (as above). Further, while Batca discloses further comprising: performing, subsequent to the completion of implementation of the feature request, the automated transaction … ([0012], 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, [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; [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), Batca does not necessarily expressly disclose the remaining following limitations, which however, are taught by further teachings Alexa.
Alexa teaches further comprising: performing, subsequent to the completion of implementation of the feature request, the automated transaction, the performing triggering payment of the price ([0030], the campaign server may update the blockchain ledger with the buyer's information, including the purchase quantity, and the blockchain ledger may be updated for each buyer that submits a purchase order to the campaign server, [0115], winning participants to this deal or contracts are notified by the platform and the remaining funds (the remaining funds is the originally agreed amount minus the surety amount) are transferred from buyers' wallets/electronic accounts to the smart contract, wired or debited in currency directly from buyers' financial account, within a specified time, and the smart contract executes and transfers funds to respective wallets of brand company and the company sponsoring the platform, [0120], in 502, the requested transaction is broadcast to a P2P network of computers known as nodes, each with a copy of a ledger that contains blocks of transactions, in 503, the network validates the transaction using known algorithms, in 504, once verified, the transaction is combined with the other transactions to create a new block of data in the electronic distributed ledger, and in 505, the transaction is deemed complete and the blockchain has a permanent record of the entire transaction between the buyer and the brand company).
Batca and Alexa are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 perform, subsequent to the completion of implementation of the feature request, the automated transaction, the performing triggering payment of the price, as taught by Alexa, 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 performing, subsequent to the completion of implementation of the feature request, the automated transaction, the performing triggering payment of the price, 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 Alexa in order to produce the added benefit of improving the accuracy and accessibility of purchase records and the ease of use and efficiency of contract enforcement. [0034], [0183].
Regarding claim 8, the combined teachings of Batca, Cao, and Mohsen teach the computer-implemented method of claim 1 (as above). Further, while Batca discloses further comprising: releasing … an implementation of the feature request to the originator of the feature request ([0012], 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, [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, [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), Batca does not necessarily expressly disclose the remaining following limitations, which however, are taught by further teachings Alexa.
Alexa teaches further comprising: releasing, responsive to receipt of payment of the price, an implementation of the feature request to the originator of the feature request ([0030], the campaign server may update the blockchain ledger with the buyer's information, including the purchase quantity, the blockchain ledger may be updated for each buyer that submits a purchase order to the campaign server, and when the campaign is over, and in particular if the minimum order quantity has been reached, the campaign server may execute the contract created on the blockchain ledger, which obligates the seller to manufacture and ship the product, and the buyer to purchase the product, [0115], winning participants to this deal or contracts are notified by the platform and the remaining funds (the remaining funds is the originally agreed amount minus the surety amount) are transferred from buyers' wallets/electronic accounts to the smart contract, wired or debited in currency directly from buyers' financial account, within a specified time, and the smart contract executes and transfers funds to respective wallets of brand company and the company sponsoring the platform, [0120], in 502, the requested transaction is broadcast to a P2P network of computers known as nodes, each with a copy of a ledger that contains blocks of transactions, in 503, the network validates the transaction using known algorithms, in 504, once verified, the transaction is combined with the other transactions to create a new block of data in the electronic distributed ledger, and in 505, the transaction is deemed complete and the blockchain has a permanent record of the entire transaction between the buyer and the brand company).
Batca and Alexa are analogous fields of invention because both address the problem of determining costs, revenue, and profits of offering 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 release, responsive to receipt of payment of the price, an implementation of the feature request to an originator of the feature request, as taught by Alexa, 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 releasing, responsive to receipt of payment of the price, an implementation of the feature request to an originator of the feature 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 Alexa in order to produce the added benefit of improving the accuracy and accessibility of purchase records and the ease of use and efficiency of contract enforcement. [0034], [0183].
Regarding claims 16-18, these claims are substantially similar to claim 6-8, and are, therefore, rejected on the same basis as claims 6-8. While claims 16-18 are directed to a computer program product comprising computer readable storage medium and program instructions collectively stored on the readable storage medium executable by a processor to cause the processor to perform operations, Batca discloses a computer program product, as claimed. Abstract, [0004]-[0005], [0015]-[0021].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES A GUILIANO whose telephone number is (571)272-9859. The examiner can normally be reached Mon-Fri 10:00 am - 6:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached at 571-272-6045. 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.
CHARLES GUILIANO
Primary Examiner
Art Unit 3623
/CHARLES GUILIANO/Primary Examiner, Art Unit 3623
Prosecution Insights