DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Applicant’s communications filed on 11/17/2025 have been considered.
Claims 1-15 have been amended.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
Applicant’s arguments filed with respect to the rejection of claims under 35 USC 101 have been fully considered but they are not persuasive.
Applicant argues that the claims, as amended, reflect an improvement to the functioning of a computing device by “proactively filtering a list of candidate products according to the first information and subsequently requesting additional information as it related to a specific selected candidate product,” with support at Applicant’s specification ([0022-0024]) (Remarks Pages 10-11). This argument has been considered and is not persuasive. The specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. MPEP 2106.04(d)(1). The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art, and conversely, if the specification explicitly sets forth an improvement but in a conclusory manner the examiner should not determine the claim improves technology. MPEP 2106.04. In the instant case, Applicant’s specification provides no explanation of an improvement to the functioning of a computer or other technology. This is reflected in Applicant’s specification ([0022-0024]), describing Applicant’s invention as addressing problems such as the complex, time-consuming process of reviewing data associated with the use of resources in order to enable a requestor to have access to said resource. While the cited portion of the specification further states that the invention can more quickly and efficiently grant access to a resource by reducing the ‘depth’ or rigor of such a determination by automatically retrieving and verifying information (see at least [0024]), this merely represents a conclusory statement. These statements (particularly at [0022-0024]) do not provide any detail as to how the claimed invention is providing any improvement to the functioning of the computer or other technology, making the statements conclusory. Furthermore, proactively filtering a list of candidate products amounts to an improvement in the claimed abstract idea, rather than a technological improvement. Accordingly, the claims do not amount to integration of the judicial exception with a practical application, and therefore the claims amount to mere instructions to implement an abstract idea in a computing environment. The rejection has been maintained.
Applicant argues that the claims amount to an inventive concept because “the claims… recite technical improvements… in a way that is not merely well-understood, routine, and conventional, such that at least the claimed combination of elements thus amounts to significantly more than any such purported judicial exception” (Remarks Page 11). This argument has been considered and is not persuasive. The previous Office Action, filed 5/16/2025, does not indicate that the claims represent well-understood, routine, and conventional activity under Prong 2, Step 2B analysis, but rather that the claims amount to mere instructions to apply the abstract idea in a computing environment, as further discussed in the above paragraph. It is further noted that, for Prong 2, Step 2A analysis of the previous Office Action, it was not asserted that the claimed limitations amount to insignificant, extra-solution activity, and therefore similarly Step 2A analysis did not indicate that the claims amount to well-understood, routine or conventional activity, and accordingly these arguments are rendered moot. The claims recite additional elements including a system, the system comprises: a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the system to…; a client device, wherein the client device is associated with a requestor; automatically obtaining information over a network; automatically determining; a computer-implemented method; a client computing device and a determiner server. While these elements are recited, they are merely act to generally link the abstract idea to a computing environment. The specification at paragraphs [0022-0024] recognizes a problem in the process of reviewing data to enable a user to access resources, and the problem is solved by conventional, generic technology. Accordingly, the claims amount to an improvement in the abstract idea, rather than effecting a change or improvement to an of the claimed technology or other technical area. For example, the independent claims recite the additional elements as performing activities falling under the recited abstract idea (processing, receiving, verifying, obtaining, determining, transmitting information), as indicated via highlighting under the Prong 1 analysis of the current 101 rejection, below. Accordingly, the claim limitations are insufficient to amount to significantly more than the judicial exception.
Applicant’s arguments filed with respect to the rejection of claims under 35 USC 103 have been fully considered but are not persuasive.
Applicant argues that the claims, as amended, overcome the currently cited prior art because “Chang is silent with respect to the claimed ‘verification workflow’… Chang make[s] no indication of both a ‘preliminary request’ and a ‘subsequent request,’ much less ‘first information’ and ‘second information’… used as a part of ‘a verification workflow’” (Remarks Page 13). This argument has been considered but is not persuasive, as Chang has been further cited to disclose the additional functional language introduced in the amended claims. A verification workflow has been interpreted as a series of steps/actions performed for verification. With regards to the claimed verification workflow, the claim defines the workflow as comprising receiving a preliminary request, receiving a subsequent request, and automatically determining an approval of the requestor for the product, thereby concluding the verification workflow. In light of this interpretation, Chang has been further relied upon to teach receiving… as a part of a verification workflow, a preliminary request from a client device, wherein the client device is associated with a requestor, at (Chang [Col 6 Ln 1-53]), disclosing the signing of a smart contract by funder, wherein the smart contract allows the funder to access different aspects of the distributed ledger and view only invoices from an industry of interest. It is noted that receiving a preliminary request as a part of a verification workflow does not impart any detail about the verification workflow itself, other than that a request is received during the workflow. Chang has been further relied upon to teach when the preliminary request is verified, automatically obtaining, by the server from a data provider over a network and based on information within the preliminary request, first information associated with the requestor, and processing, by the server for each product of a set of products, the first information associated with the requestor using a first eligibility rule of a set of eligibility rules… thereby generating a list of candidate products for the preliminary request of the verification workflow, at (Chang, [Col 2 Ln 25-29][Col 5 Ln 36-56][Col 6 Ln 34-65][Col 7 Ln 7-17]), disclosing that, after the smart contract is signed, an indicated industry of interest of the funder is determined and used (as “filtering criteria”) to filter out inappropriate invoices that are not in the correct industry, where the “industry of interest” of the funder determined from the signed smart contract teaches the claimed first information, and the filtering of invoices in order to match said industry of interest teaches the processing… the first information associated with the requestor using a first eligibility rule of a set of eligibility rules. Chang has been further cited to teach receiving… a subsequent request of the verification workflow, wherein the subsequent request includes second information obtained from the requestor by the client device, wherein the second information corresponds to a second eligibility rule for the selected candidate product, at (Chang, [Col 7 Ln 7-17][Col 9 Ln 40-67][Col 15 Ln 58-Col 16 Ln 3]), disclosing that a funder may make an offer once it decides that it is interested in buying an invoice, where the offer includes payment conditions. The supplier of the invoice, on the other hand, may decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and have other types of payment conditions. Accordingly, the supplier selecting to only receive offers including certain payment conditions has been interpreted as the second eligibility rule, which is used to match the supplier with funder offers. Chang has been further cited to teach obtaining, responsive to the subsequent request and over the network, one or more results of a review of the requestor for the selected candidate product based at least in part on an evaluation of the second eligibility rule of the set of eligibility rules based on the second information obtained from the requestor to verify eligibility of the requestor for the candidate product according to the second information, thereby further verifying the requestor following the processing of the first information using the first eligibility rule, and automatically determining… based on the obtained one or more results, an approval of the requestor, thereby concluding the verification workflow, at (Chang, [Col 8 Ln 23-33][Col 9 Ln 50-67][Col 10 Ln 1-19][Col 15 Ln 58-Col 16 Ln 3]), further discussing the supplier receiving offers from funders based on the supplier’s selected filters, and reviewing the offers to subsequently make a selection of an offer. The funder is notified when the supplier selects its offer, and the parties subsequently come to terms on an agreement, which may be performed through automatic negotiation, and which is communicated through the funding marketplace server. The supplier selecting a funder offer and reaching an agreement on terms has been interpreted as concluding the verification workflow, since it verifies the funder offer as meeting the desired criteria of the supplier, and provides notification to the funder that an offer has been selected by the supplier. Chang has been further relied upon to teach transmitting… an indication of the automatically determined approval to the client device, at (Chang, [Col 5 Ln 41-43][Col 12 Ln 47-51]), disclosing the buyer (funder) computer receiving a purchase order and invoice after offering and purchasing a supplier’s invoice.
Previously cited Gudmundsson, on the other hand, has been relied upon to teach wherein the preliminary request includes a credential for the requestor (see at least Gudmundsson [0061][Fig. 3A-3C] the request can include a password used by the authorization server 101 to authenticate the customer), verifying the requestor based upon the credential (see at least [0023] the authorization server can provide the customer identification information and password to the authentication server 107 to verify the identity of the customer prior to providing authorization services), and wherein the subsequent request includes an indication of a candidate product selected from the list of candidate products (see at least [0061][Fig. 3A-3C] the authorization server 101 performs method 200 under the “eligibility” condition and returns, in step 211, a list of the customer's products or services that are eligible for the selected service plan). Accordingly, claim 1 stands rejected in view of the previously recited combination of Chang/Gudmundsson. Claim 8 recites substantially similar subject matter to that recited in claim 1, and stands rejected for similar reasons.
Similarly, in light of the amendments discussed above, and with regards to independent claim 15, Chang has been further cited to teach transmitting… a preliminary request as part of a verification workflow that includes the requestor information and the one or more attributes associated with the product (see at least [Col 2 Ln 25-29][Col 6 Ln 39-50][Col 8 Ln 3-17]), and receiving… a list of candidate products from the determiner server, wherein each candidate product of the list of candidate products has a first associated eligibility rule of the verification workflow that is satisfied by the requestor (see at least [Col 6 Ln 39-51][Col 7 Ln 7-17]. Chang has been further relied upon to teach receiving, from the requestor, a selection of a candidate product from the list of candidate products and additional information for the requestor corresponding to a second eligibility rule of the verification workflow (see at least [Col 7 Ln 7-17][Col 9 Ln 40-67][Col 15 Ln 58-Col 16 Ln 3]). Chang has been further relied upon to teach transmitting… a subsequent request that includes: the selection of the candidate product, and the additional information, wherein the additional information is about the requestor and relates to the selected product, at (Chang, [Col 9 Ln 40-67][Col 15 Ln 58-Col 16 Ln 3]). Chang has been further relied upon to teach receiving… a decision associated with the subsequent request for the product, wherein the decision includes a full approval decision associated with the product based at least in part on the second eligibility rule of a set of eligibility rules associated with the product and the additional information for the requestor, thereby concluding the verification workflow, at (Chang, [Col 8 Ln 23-33][Col 10 Ln 1-19]), where the selection of a funder offer by the supplier according to the supplier’s criteria is performed, indicating approval of the funder according to the supplier’s preferences. Chang has been further cited to teach determining, by the client computing device, an indication of the decision (see at least [Col 5 Ln 41-43][Col 12 Ln 47-51]). Gudmundsson, on the other hand, has been relied upon to teach wherein the preliminary request comprises a credential for a requestor (see at least Gudmundsson [0023]), a selection of a candidate product from the list of candidate products (see at least [0054][0061][Fig. 3A-3C]), and displaying an indication of the decision (see at least [0061]). Accordingly, claim 15 stands rejected in view of the previously recited combination of Chang/Gudmundsson
In light of the amendments noted above, the following is further noted:
With regards to amended claim 2, Chang has been further cited to teach wherein the preliminary request includes: a product scenario, wherein the product scenario includes a description of at least one product being requested without specifying a particular product, at (Chang, [Col 5 Ln 65-Col 6 Ln 7][Col 6 Ln 39-53][Col 7 Ln 7-16]), disclosing the signing of the smart contract by the funder, which includes funding criteria that allows the funder only to see invoices from companies of interest, without specifying an individual invoice. With regards to amended claim 3, Chang has been further cited to teach wherein the information associated with the requestor includes verification information for authenticity obtained from the computing device of the data provider over the network, at (Chang, [Col 2 Ln 25-29][Col 6 Ln 39-53]), disclosing that the smart contract is cryptographically signed by the funder’s system, where verification is provided through the provision of information via the blockchain-based system of Chang. Gudmundsson, on the other hand, has been cited to teach wherein the preliminary request includes identification information of the requestor (see at least Gudmundsson [0023]). With regards to amended claim 4, Chang is further cited to teach wherein the review includes determining whether the first information and the second information satisfy the set of eligibility rules for the selected product, at (Chang, [Col 6 Ln 34-50][Col 9 Ln 50-67][Col 15 Ln 58-Col 16 Ln 3]), disclosing the filtering of invoices based on funder criteria specified in the signed smart contract, an offer provided by the funder, and the supplier filtering funder offers, based on the information provided by the funders, based on the supplier’s own criteria in order to decide on a particular offer to select. With regards to claim 7, Chang has been further relied upon to teach automatically transmitting, based on the subsequent request, a combination of the first information and the second information associated with the product over the network for evaluating the requestor, at (Chang, [Col 6 Ln 34-50][Col 7 Ln 7-17][Col 15 Ln 58-Col 16 Ln 3]), disclosing the signing of the smart contract such that the funder’s system would only have access to those funding requests which are related to its industry of interest, in order to make an offer for an invoice comprising payment conditions. Chang is then further relied upon to teach receiving, in response to the transmitting, the one or more results, at (Chang, [Col 8 Ln 23-33][Col 9 Ln 40-67]), disclosing the supplier making a selection of a funder offer, and the funder receiving notification that an offer has been selected by the supplier.
Dependent claims 9-14 and 16-20 stand rejected for similar reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite an abstract idea. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories. See MPEP 2106.03. Claims 1-7 and 15-20 are directed towards a process. Claims 8-14 are directed towards a machine. Therefore, claims 1-20 are directed to one of the four statutory categories (Step 1: YES, regarding claims 1-20).
Under Step 2A of the MPEP, it is determined whether the claims are directed to a judicially recognized exception. See MPEP 2106.04. Step 2A is a two-prong inquiry.
Under Prong 1, it is determined whether the claim recites a judicial exception. In determining whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception.
Taking Claim 8 as representative, claim 8 recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including:
processing a request for a product,
receive, as part of a verification workflow, a preliminary request from a requestor and wherein the preliminary request includes a credential for the requestor;
verifying the requestor based on the credential;
when the preliminary request is verified, obtain, from a data provider and based on information within the preliminary request, first information associated with the requestor;
process, for each product of a set of products, the first information associated with the requestor using a first eligibility rule of a set of eligibility rules associated with the product, thereby generating a list of candidate products for the preliminary request of the verification workflow, wherein the list of candidate products is a subset of the set of products;
receive a subsequent request of the verification workflow, wherein the subsequent request includes:
an indication of a candidate product selected from the list of candidate products; and
second information obtained from the requestor, wherein the second information corresponds to a second eligibility rule of the set of eligibility rules for the selected candidate product;
obtain, responsive to the subsequent request, one or more results of a review of the requestor for the selected candidate product based at least in part on an evaluation of the second eligibility rule of the set of eligibility rules based on the second information obtained from the requestor to verify eligibility of the requestor for the candidate product according to the second information, thereby performing subsequent verification of the requestor according to the workflow following the processing of the first information using the first eligibility rule;
determine, by the system based on the obtained one or more results, an approval of the requestor for the product, thereby concluding the verification workflow for the requestor; and
transmit an indication of the determined approval.
Claim 1 recites the same limitations believed to be abstract as recited in claim 8.
Claim 15 additionally recites the following limitations believed to be abstract:
a method for processing a request for a product, the method comprising:
receiving requestor information associated with a requestor for the product;
receiving one or more attributes associated with a potential product to be requested;
transmitting, a preliminary request as part of a verification workflow that includes the requestor information and the one or more attributes associated with the product, wherein the preliminary request comprises a credential for a requestor;
receiving a list of candidate products, wherein each candidate product of the list of candidate products has a first associated eligibility rule of the verification workflow that is satisfied by the requestor;
receiving, from the requestor, a selection of a candidate product from the list of candidate products and additional information for the requestor corresponding to a second eligibility rule of the verification workflow;
transmitting a subsequent request that includes: the selection of the candidate product; and
the additional information, wherein the additional information is about the requestor and relates to the selected product;
receiving a decision associated with the subsequent request for the product, wherein the decision includes a full approval decision associated with the product based at least in part on the second eligibility rule of a set of eligibility rules associated with the product and the additional information for the requestor, thereby concluding the verification workflow; and
displaying an indication of the decision.
Claim 1, as exemplary, recites the abstract idea of approving a product request according to eligibility rules. These recited limitations fall within the "Certain Methods of Organizing Human Activities" Grouping of abstract ideas as it relates to commercial interactions of sales activities or behaviors. Accordingly, the claim recites an abstract idea. See MPEP 2106.04.
Accordingly, under Prong One of Step 2A of the Alice/Mayo test, claims 1, 8 and 15 recite an abstract idea (Step 2A, Prong One: YES).
Under Prong 2, it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception.
Claim 1 recites additional elements beyond the judicial exception(s), including a system, the system comprises: a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the system to…; a client device, wherein the client device is associated with a requestor; automatically obtaining information over a network; and automatically determining. Claim 8 recites the same additional elements as recited in claim 1. Claim 15 recites the same additional elements as recited in claim 1, and additionally recites a computer-implemented method; a client computing device and a determiner server.
These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. As such, these computer-related limitations are not found to be sufficient to integrate the abstract idea into a practical application. Claims 1, 8 and 15 specifying that the abstract idea of approving a product request according to eligibility rules is executed in a computer environment merely indicates a field of use in which to apply the abstract idea because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer. As such, under Prong Two of Step 2A of the Alice/Mayo test, when considered both individually and as a whole, the limitations of claims 1, 8 and 15 are not indicative of integration into a practical application (Step 2A, Prong Two: NO).
Since claims 1, 8 and 15 recite an abstract idea and fail to integrate the abstract idea into a practical application, claims 1, 8 and 15 are “directed to” an abstract idea (Step 2A: YES). Accordingly, the judicial exception is not integrated into a practical application.
Next, under Step 2B, the instant claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, the additional elements of a system, the system comprises: a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the system to…; a client device, wherein the client device is associated with a requestor; automatically obtaining information over a network; automatically determining; a computer-implemented method; a client computing device and a determiner server amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Therefore when considering the additional elements alone, and in combination, there is no inventive concept in the claim, and thus the claim is not patent eligible (Step 2B: NO).
Dependent claims 2-7, 9-14 and 16-20, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because they do not add “significantly more” to the abstract idea. As for dependent claims 2-6, 9-13, 16-17 and 19, these claims recite limitations that further define the same abstract idea noted in independent claims 1, 8 and 15, and do not recite any additional elements other than what is disclosed in independent claims 1, 8 and 15. Therefore, claims 2-6, 9-13, 16-17 and 19 are considered patent ineligible for the reasons given above.
As for dependent claims 7, 14, 18 and 20, these claims recite limitations that further define the abstract idea noted in independent claims 1, 8 and 15. Additionally, they recite the following additional limitations:
automatically transmitting… to a computing device of a reviewer over the network;
receiving, from the requestor and via a user interface of the client computing device; and
transmit a request… to at least one reviewer server over a network.
The additional elements of automatically transmitting to a computing device of a reviewer; a user interface of the client computing device; and transmit a request to at least one reviewer server over a network are all recited at a high level of generality such that they amount to no more than instructions to apply the judicial exception in a generic technological environment. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Accordingly, under the Alice/Mayo test, claims 1-20 are ineligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over previously cited Chang (US 10,956,973 B1) in view of previously cited Gudmundsson (US 2015/0348149 A1).
Regarding Claim 1, Chang discloses A computer-implemented method of processing a request for a product, the method comprising ([Col 4 Ln 29-45]):
receiving, by a server as part of a verification workflow, a preliminary request from a client device, wherein the client device is associated with a requestor ([Col 6 Ln 1-25] the information about the invoice to be sold, is transferred to funding marketplace server 120. Funding marketplace server 120 then optionally and preferably extracts, at least metadata about the invoice to be sold, the industry of the supplier who wishes to sell the invoice, and other basic information, and writes it to distributed ledger 124… once a copy is written to one location, for example, a funding marketplace server 120, this change is automatically securely, non-falsifiably, that is completely accurately, replicated to other entities who are interested in this information, such as in this example, funder's system 130; [Col 6 Ln 26-38] Funder's system 130, then optionally and preferably uses an underwriting engine 134, to review distributed ledger 124 in order to determine which invoices may be of interest. Optionally in order to prevent funder's system 130 from seeing information to which it is not entitled, a smart contract 132 is set up between funder's system 130 and funding marketplace server 120 with cryptographic keys or digital signatures to access different aspects of the distributed ledger 12; [Col 6 Ln 39-53] smart contract 132 may be cryptographically signed by funder’s system, and subsequently funder’s system may only see invoices from companies of interest);
verifying, by the server, the requestor ([Col 2 Ln 25-29] verification is provided through provision of information through a cryptocurrency or a digital currency, blockchain-based network, or any other system which features a distributed ledger; [Col 6 Ln 26-38] a smart contract 132 is set up between funder's system 130 and funding marketplace server 120 with cryptographic keys or digital signatures to access different aspects of the distributed ledger 12);
when the preliminary request is verified, automatically obtaining, by the server from a data provider over a network and based on information within the preliminary request, first information associated with the requestor ([Col 2 Ln 25-29] verification is provided through provision of information through a cryptocurrency or a digital currency, blockchain-based network, or any other system which features a distributed ledger; [Col 6 Ln 34-50] smart contract 132 is cryptographically signed by funder’s system 130 and funding marketplace server 120, and is automatically replicated to funding marketplace server 120… funder’s system may indicate an interest of the funder in a particular industry, such as Construction… smart contract would then filter out inappropriate invoices that are not in the correct industry; [Col 6 Ln 54-65] smart contract 132 therefore also enables the protection of confidential information and privacy of non-public companies, and also may prevent unauthorized access to same, with self-enforcing Smart Contract Technology. Such technology reduces the ability of funder systems 130 to obtain information for which they are not authorized, for example to avoid data “scraping.”; [Col 7 Ln 7-16] funding criteria on the smart contract include the funder’s industry of interest… see [Col 5 Ln 36-56] funder’s system 130 operates a smart contract 132);
processing, by the server for each product of a set of products, the first information associated with the requestor using a first eligibility rule of a set of eligibility rules associated with the product, thereby generating a list of candidate products for the preliminary request of the verification workflow, wherein the list of candidate products is a subset of the set of products ([Col 6 Ln 34-51] smart contract 132 is cryptographically signed by funder's system 130 and funding marketplace server 120, and is automatically securely, non-falsifiably, that is completely accurately, replicated to funding marketplace server 120. Then in that case, funder's system 130 may optionally only see invoices from companies which were indicated previously to be of interest, for example, from a particular industry such as Construction versus, for example, Fashion. If funder's system 130 had only indicated an interest in Construction, not interested in Fashion, then optionally and preferably, smart contract 132 would filter out inappropriate invoices: inappropriate because the supplier is not in the correct industry; [Col 7 Ln 7-17] funder's system 130 would only have access to those funding requests on distributed ledger 124 which are related to the industry of interest if in fact that is one of the filtering criteria on smart contract 132);
receiving, by the server from the client device, a subsequent request of the verification workflow, wherein the subsequent request includes: second information obtained from the requestor by the client device, wherein the second information corresponds to a second eligibility rule for the selected candidate product ([Col 7 Ln 7-17] funder's system 130 would only have access to those funding requests on distributed ledger 124 which are related to the industry of interest if in fact that is one of the filtering criteria on smart contract 132. Once funder's system 130 decides it is interested in potentially buying the invoices, it makes an offer. It often preferably makes an offer through communication to funding marketplace server 120; [Col 9 Ln 40-67] if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account… the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions) (Note: The supplier’s preferences for offers have been interpreted as a second eligibility rule, and the information with a funding request from a funder system, such as payment conditions, have been interpreted as the second information); and
obtaining, responsive to the subsequent request and over the network, one or more results of a review of the requestor for the selected candidate product based at least in part on an evaluation of the second eligibility rule of the set of eligibility rules based on the second information obtained from the requestor to verify eligibility of the requestor for the candidate product according to the second information, thereby further verifying the requestor following the processing of the first information using the first eligibility rule ([Col 9 Ln 50-67] The supplier then receives offers from various funders based on its own filters, and makes a selection in stage 214… the supplier in this case may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions which meet supplier's own conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions) (Note: The supplier’s selection of a funder’s offer, from among multiple offers, to accept for a funding request, based on funder-specified information including payment conditions, has been interpreted as one or more results of a review of the requestor for the selected candidate product to verify eligibility, as only a funder offer with payment conditions satisfying those specified by the supplier will be selected);
automatically determining, by the server based on the obtained one or more results, an approval of the requestor for the product, thereby concluding the verification workflow ([Col 8 Ln 23-33] In stage 216, at the funder's system, the funder is notified when the supplier selects its offer. At stage 218, the funder enters into agreement and provides the funds minus the fees, to the supplier as previously described. Again, there may be multiple entities involved in negotiation. The funder system may communicate directly to the supplier, may optionally communicate through the funding marketplace server, may also optionally communicate through distributed ledger; [Col 10 Ln 1-19] agreements may take place through automatic negotiation); and
transmitting, by the server, an indication of the automatically determined approval to the client device ([Col 5 Ln 41-43] funder’s system 130 operates a distributed ledger 124, smart contract 132, and underwriting engine 134; [Col 12 Ln 47-51] On the buyer side, the flow may optionally be performed as follows. Buyer computer A 106 issues the purchase order 366 and receives the invoice 368 as shown, through P2P system 110A. Buyer computer A 106 then approves the invoice 372 at P2P system 110A);
But does not explicitly disclose wherein the preliminary request includes a credential for the requestor; verifying the requestor based upon the credential; wherein the subsequent request includes an indication of a candidate product selected from the list of candidate products
Gudmundsson, on the other hand, teaches wherein the preliminary request includes a credential for the requestor ([0021] the authorization server 101 can communicate with an authentication server 107 to ensure that authorization information is provided only to authenticated users by authenticating identifying information (including passwords) received in authorization requests; [0023] the request can include a password used by the authorization server 101 to authenticate the customer. In situations in which a password is received, the authorization server can provide the customer identification information and password to the authentication server 107 to verify the identity of the customer prior to providing authorization services);
verifying the requestor based upon the credential ([0023] the request can include a password used by the authorization server 101 to authenticate the customer. In situations in which a password is received, the authorization server can provide the customer identification information and password to the authentication server 107 to verify the identity of the customer prior to providing authorization services); and
wherein the subsequent request includes an indication of a candidate product selected from the list of candidate products ([0061][Fig. 3A-3C] the application server 103 generates a second authorization request to determine which of the customer's lines of service are eligible for the upgrade. The application server 103 may thus generate and transmit to the authorization server 101 a second product authorization request identifying the selected wireless service plan. In response to receiving the request, the authorization server 101 performs method 200 under the “eligibility” condition and returns, in step 211, a list of the customer's products or services that are eligible for the selected service plan).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the system, as taught by Chang, wherein the product request includes a credential for the requestor, verifying the requestor based upon the credential, and wherein the subsequent request includes an indication of a candidate product selected from the list of candidate products, as taught by Gudmundsson, 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 results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chang, to include the teachings of Gudmundsson, in order to provide a more efficient manner of authorizing customers for particular products or services (Gudmundsson, [0003]).
Regarding Claim 2, Chang and Gudmundsson teach the limitations of claim 1.
Chang further discloses wherein the preliminary request includes: a product scenario, wherein the product scenario includes a description of at least one product being requested without specifying a particular product ([Col 5 Ln 65-Col 6 Ln 7] funding marketplace server 120 receives information about the invoice to be sold, and extracts at least metadata about the invoice, the industry of the supplier, which are both examples of information that do not specify the particular terms of the invoice; [Col 6 Ln 39-53] smart contract 132 may be cryptographically signed by funder’s system, and subsequently funder’s system may only see invoices from companies of interest; [Col 7 Ln 7-16] funding criteria on the smart contract include the funder’s industry of interest);
But does not explicitly disclose wherein the preliminary request includes identification information of the requestor.
Gudmundsson, on the other hand, discloses wherein the preliminary request includes identification information of the requestor ([0023] The authorization request includes customer identification information such as an account number or other unique identifier associated with the customer, or information identifying the customer as a new/potential customers).
It would have been obvious to one of ordinary skill in the art to include in the computer-implemented method, as taught by Chang, wherein the preliminary request includes identification information of the requestor, as taught by Gudmundsson, for the same reasons discussed above with respect to claim 1.
Regarding Claim 3, Chang and Gudmundsson teach the limitations of claim 1.
Chang further discloses wherein the first information associated with the requestor includes verification information for authenticity obtained from the data provider over the network ([Col 2 Ln 25-29] verification is provided through provision of information through a cryptocurrency or a digital currency, blockchain-based network, or any other system which features a distributed ledger; [Col 6 Ln 39-53] smart contract 132 may be cryptographically signed by funder’s system).
Regarding Claim 4, Chang and Gudmundsson teach the limitations of claim 1.
Chang further discloses wherein the review includes determining whether the first information and the second information satisfy the set of eligibility rules for the selected product ([Col 6 Ln 34-50] smart contract 132 is cryptographically signed by funder’s system 130… funder’s system may indicate an interest of the funder in a particular industry, such as Construction… smart contract would then filter out inappropriate invoices that are not in the correct industry; [Col 9 Ln 50-67] The supplier then receives offers from various funders based on its own filters, and makes a selection in stage 214… the supplier in this case may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions which meet supplier's own conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions).
Regarding Claim 5, Chang and Gudmundsson teach the limitations of claim 1.
Chang further discloses wherein the approval for the product is further determined based on information associated with the requestor obtained from the data provider based on the subsequent request ([Col 17 Ln 26-31] the smart contract may be validated according to criteria set by the funder, and optionally each time a funding request could potentially be funded by a particular smart contract owned by a particular funder … see [Col 5 Ln 36-56] funder’s system 130 operates a smart contract 132).
Regarding Claim 6, Chang and Gudmundsson teach the limitations of claim 2.
Chang further discloses further comprising: retrieving, based on the product scenario, one or more products ([Col 6 Ln 39-53] smart contract 132 is cryptographically signed by funder's system 130 and funding marketplace server 120, and is automatically securely, non-falsifiably, that is completely accurately, replicated to funding marketplace server 120. Then in that case, funder's system 130 may optionally only see invoices from companies which were indicated previously to be of interest, for example, from a particular industry such as Construction versus, for example, Fashion. If funder's system 130 had only indicated an interest in Construction, not interested in Fashion, then optionally and preferably, smart contract 132 would filter out inappropriate invoices);
retrieving one or more eligibility rules associated with the one or more products ([Col 6 Ln 34-38] smart contracts have predetermined rules based on predefined inputs between two or more parties on a distributed ledger);
selecting, based on the one or more eligibility rules, one or more eligible products from the one or more products ([Col 6 Ln 39-53] via the smart contract, funder’s system 130 may optionally only see invoices from companies which were indicated previously to be of interest);
generating the list of candidate products, wherein the list of candidate products includes the determined one or more candidate products ([Col 11 Ln 10-17] smart contract may review the distributed ledger, determine which invoice or invoices are of interest, and then filter this request to the funder system, in order to make certain that criteria are correct and also funding amounts are available); and
transmitting the list of candidate products to the client device ([Col 11 Ln 10-14] the smart contract sends the filtered list of invoices to the funder system).
Regarding Claim 7, Chang and Gudmundsson teach the limitations of claim 1.
Chang further discloses further comprising: automatically transmitting, based on the subsequent request, a combination of the first information and the second information associated with the product over the network for evaluating the requestor ([Col 6 Ln 34-50] smart contract 132 is cryptographically signed by funder’s system 130 and funding marketplace server 120, and is automatically replicated to funding marketplace server 120; [Col 7 Ln 7-17] funder's system 130 would only have access to those funding requests on distributed ledger 124 which are related to the industry of interest if in fact that is one of the filtering criteria on smart contract 132. Once funder's system 130 decides it is interested in potentially buying the invoices, it makes an offer. It often preferably makes an offer through communication to funding marketplace server 120; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions); and
receiving, in response to the transmitting, the one or more results ([Col 9 Ln 40-67] The supplier then receives offers from various funders based on its own filters, and makes a selection in stage 214… if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account… the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions… see [Col 8 Ln 23-33] In stage 216, at the funder's system, the funder is notified when the supplier selects its offer).
But does not explicitly disclose automatically transmitting to a computing device of a reviewer for evaluating the requestor; and receiving the one or more results from the computing device of the reviewer.
Gudmundsson, on the other hand, discloses automatically transmitting to a computing device of a reviewer for evaluating the requestor; ([0023] The method 200 begins in step 201 with the authorization server 101 receiving an authorization request. The authorization request includes customer identification information such as an account number or other unique identifier associated with the customer… the authorization request includes identification of one or more specific products for which the customer seeks to obtain authorization. In cases in which no specific products are identified in the request, the authorization server 101 performs authorization for all products so as to provide to the customer information on those products for which the customer is authorized); and
receiving the one or more results from the computing device of the reviewer ([0061] In response to receiving the request, the authorization server 101 performs method 200 under the “eligibility” condition and returns, in step 211, a list of the customer's products or services that are eligible for the selected service plan. The application server 103 generates a display screen for display to the user via the website including the product eligibility information).
It would have been obvious to one of ordinary skill in the art to include in the computer-implemented method, as taught by Chang, automatically transmitting to a computing device of a reviewer for evaluating the requestor; and receiving the one or more results from the computing device of the reviewer, as taught by Gudmundsson, for the same reasons discussed above with respect to claim 1.
Claim 8 is directed to a system. Claim 8 recites limitations that are substantially parallel in nature to those addressed above for claim 1 which is directed towards a method. The combined system of Chang/Gudmundsson teaches the limitations of claim 1 as noted above. Chang further discloses A system for processing a request for a product, the system comprises: a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the system to (Chang: [Col 12 Ln 52-Col 13 Ln 6]). Claim 8 is therefore rejected for the reasons set forth above in claim 8 and in this paragraph.
Claim 9 recites a system comprising substantially similar limitations as claim 2. The claim is rejected under substantially similar grounds as claim 2.
Claim 10 recites a system comprising substantially similar limitations as claim 3. The claim is rejected under substantially similar grounds as claim 3.
Claim 11 recites a system comprising substantially similar limitations as claim 4. The claim is rejected under substantially similar grounds as claim 4.
Claim 12 recites a system comprising substantially similar limitations as claim 5. The claim is rejected under substantially similar grounds as claim 5.
Claim 13 recites a system comprising substantially similar limitations as claim 6. The claim is rejected under substantially similar grounds as claim 6.
Claim 14 recites a system comprising substantially similar limitations as claim 7. The claim is rejected under substantially similar grounds as claim 7.
Regarding Claim 15, Chang discloses A computer-implemented method for processing a request for a product, the method comprising ([Col 4 Ln 29-45]):
receiving, by a client computing device, requestor information associated with a requestor for the product ([Col 6 Ln 26-38] in order to prevent funder's system 130 from seeing information to which it is not entitled, a smart contract 132 is set up between funder's system 130 and funding marketplace server 120 with cryptographic keys or digital signatures to access different aspects of the distributed ledger 124; [Col 6 Ln 39-47] smart contract 132 is cryptographically signed by funder's system 130 and funding marketplace server 120, and is automatically securely, non-falsifiably, that is completely accurately, replicated to funding marketplace server 120. Then in that case, funder's system 130 may optionally only see invoices from companies which were indicated previously to be of interest, for example, from a particular industry such as Construction versus, for example, Fashion);
receiving one or more attributes associated with a potential product to be requested ([Col 6 Ln 34-38] smart contracts are software programs with predetermined rules based on predefined inputs between two or more parties on a distributed ledger, triggers a corresponding action when a condition specified in the code is met; [Col 6 Ln 39-53] funder's system 130 may optionally only see invoices from companies which were indicated previously to be of interest, for example, from a particular industry such as Construction versus, for example, Fashion. If funder’s system 130 had only indicated an interest in construction, smart contract 132 would filter out inappropriate invoice);
transmitting, to a determiner server, a preliminary request as part of a verification workflow that includes the requestor information and the one or more attributes associated with the product ([Col 2 Ln 25-29] verification is provided through provision of information through a cryptocurrency or a digital currency, blockchain-based network, or any other system which features a distributed ledger; [Col 6 Ln 39-50] smart contract 132 is cryptographically signed by funder's system 130 and funding marketplace server 120, and is automatically securely, non-falsifiably, that is completely accurately, replicated to funding marketplace server 120. Then in that case, funder's system 130 may optionally only see invoices from companies which were indicated previously to be of interest, for example, from a particular industry such as Construction versus, for example, Fashion; [Col 8 Ln 3-17] funding rates and terms are preferably determined by the market through automation of funder's underwriting criteria and smart contract … information gathered through funding marketplace server 120 may optionally be used to determine price and risk);
receiving by the client computing device, a list of candidate products from the determiner server, wherein each candidate product of the list of candidate products has a first associated eligibility rule of the verification workflow that is satisfied by the requestor ([Col 6 Ln 39-51] after signing smart contract 132 via funder’s system 130, it is securely replicated to the funding marketplace server 120… smart contracts filter invoices so that only invoices of interest are shown, for example a smart contract may exclude invoices from companies in particular industries such as construction or fashion; [Col 7 Ln 7-17] funder's system 130 would only have access to those funding requests on distributed ledger 124 which are related to the industry of interest if in fact that is one of the filtering criteria on smart contract 132);
receiving, from the requestor, a selection of a candidate product and additional information for the requestor corresponding to a second eligibility rule of the verification workflow ([Col 7 Ln 7-17] funder's system 130 would only have access to those funding requests on distributed ledger 124 which are related to the industry of interest if in fact that is one of the filtering criteria on smart contract 132. Once funder's system 130 decides it is interested in potentially buying the invoices, it makes an offer. It often preferably makes an offer through communication to funding marketplace server 120; [Col 9 Ln 40-67] if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account… the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions);
transmitting, to the determiner server, a subsequent request that includes: the selection of the candidate product ([Col 7 Ln 7-17] Once funder's system 130 decides it is interested in potentially buying the invoices, it makes an offer. It often preferably makes an offer through communication to funding marketplace server 120; [Col 9 Ln 40-67] if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account); and
the additional information, wherein the additional information is about the requestor and relates to the selected product ([Col 9 Ln 40-67] if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account… the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions);
receiving, from the determiner server, a decision associated with the subsequent request for the product, wherein the decision includes a full approval decision associated with the product based at least in part on the second eligibility rule of a set of eligibility rules associated with the product and the additional information for the requestor, thereby concluding the verification workflow ([Col 8 Ln 23-33] In stage 216, at the funder's system, the funder is notified when the supplier selects its offer. At stage 218, the funder enters into agreement and provides the funds minus the fees, to the supplier as previously described. Again, there may be multiple entities involved in negotiation. The funder system may communicate directly to the supplier, may optionally communicate through the funding marketplace server, may also optionally communicate through distributed ledger; [Col 10 Ln 1-19] agreements may take place through automatic negotiation); and
determining, by the client computing device, an indication of the decision ([Col 5 Ln 41-43] funder’s system 130 operates a distributed ledger 124, smart contract 132, and underwriting engine 134; [Col 12 Ln 47-51] On the buyer side, the flow may optionally be performed as follows. Buyer computer A 106 issues the purchase order 366 and receives the invoice 368 as shown, through P2P system 110A. Buyer computer A 106 then approves the invoice 372 at P2P system 110A).
But does not explicitly disclose wherein the preliminary request comprises a credential for a requestor; a selection of a candidate product from the list of candidate products; and displaying an indication of the decision.
Gudmundsson, on the other hand, discloses wherein the preliminary request comprises a credential for a requestor ([0023] the request can include a password used by the authorization server 101 to authenticate the customer. In situations in which a password is received, the authorization server can provide the customer identification information and password to the authentication server 107 to verify the identity of the customer prior to providing authorization services);
a selection of a candidate product from the list of candidate products ([0061][Fig. 3A-3C] the user may select via the website an option to upgrade the customer's wireless service plan to one of the products presented to the user following the “eligibility” authorization… see [0054] The qualify condition can also be applied in a situation in which a customer has chosen a product for purchase, and a final authorization verification is performed to ensure that the customer is authorized for the product); and
displaying an indication of the decision ([0061] The application server 103 generates a display screen for display to the user via the website including the product eligibility information. The product eligibility information can, for example, notify the customer that only the customer's lines of service associated with mobile telephones are eligible for a new telephone service plan, while lines of service associated with tablet computers are not eligible for the selected plan).
It would have been obvious to one of ordinary skill in the art to include in the computer-implemented method, as taught by Chang, wherein the preliminary request comprises a credential for a requestor; a selection of a candidate product from the list of candidate products; and displaying an indication of the decision, as taught by Gudmundsson, 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 results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chang, to include the teachings of Gudmundsson, in order to provide a more efficient manner of authorizing customers for particular products or services (Gudmundsson, [0003]).
Regarding Claim 16, Chang and Gudmundsson teach the limitations of claim 15.
Chang further discloses wherein the selected product enables the requestor to access a resource matching the one or more attributes associated with the products ([Col 9 Ln 24-26] the selected invoice or invoices and the supplier/buyer information are added to the database; [Col 9 Ln 27-31] in stage 210, the funder’s system filters new supplier requests on the distributed ledger according to the underwriting criteria through the smart contract).
Regarding Claim 17, Chang and Gudmundsson teach the limitations of claim 15.
Chang further discloses wherein the transmitting the subsequent request causes the determiner server to obtain, over a network, verification information associated with the requestor and the product ([Col 2 Ln 25-29] verification is provided through provision of information through a cryptocurrency or a digital currency, blockchain-based network, or any other system which features a distributed ledger; [Col 5 Ln 36-39] funding marketplace server 120 includes a distributed ledger 124; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions), and
to determine whether to approve the subsequent request ([Col 9 Ln 40-67] the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions).
Regarding Claim 18, Chang and Gudmundsson teach the limitations of claim 15.
Chang further discloses further comprising: the additional information associated with the requestor ([Col 9 Ln 40-67] if the underwriting criteria are met, the funder’s system issues an offer to the supplier’s account… the supplier may optionally decide that it only wishes to receive offers from funders which give at least 90 cents on every dollar of the invoice being sold, and/or have other types of repayment conditions; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions); and
transmitting, to the determiner server, the additional information ([Col 15 Ln 4-15] In stage 404, the funder sets up a smart contract to select the funding request based on underwriting criteria… once the metadata has been shown and the funding system then indicates, according to its underwriting criteria, that it's interested in the funding request, then optionally and preferably more details about the funding request are shown including, for example, the supplier, the buyer, and optionally also credit and other information which has been provided to the funding marketplace server; [Col 15 Ln 58-Col 16 Ln 3] funder offers include payment conditions));
But does not explicitly disclose displaying a request for the additional information associated with the requestor; and receiving, from the requestor and via a user interface of the client computing device, the additional information.
Gudmundsson, on the other hand, discloses displaying a request for the additional information associated with the requestor ([0020] the user accesses an application executing on the user device 111a-d, or executing on the application server 103 via a user interface provided on the user device 111a-d. The application obtains identification information from the user, the identification information including a unique identifier for the user and, optionally, a password, or information providing basic user information (e.g., information identifying a new/potential customer)); and
receiving, from the requestor and via a user interface of the client computing device, the additional information ([0020] the user accesses an application executing on the user device 111a-d, or executing on the application server 103 via a user interface provided on the user device 111a-d. The application obtains identification information from the user, the identification information including a unique identifier for the user and, optionally, a password; [0023] The method 200 begins in step 201 with the authorization server 101 receiving an authorization request. The authorization request includes customer identification information such as an account number or other unique identifier associated with the customer, or information identifying the customer… the request can include a password used by the authorization server 101 to authenticate the customer).
It would have been obvious to one of ordinary skill in the art to include in the computer-implemented method, as taught by Chang, displaying a request for the additional information associated with the requestor, and receiving, from the requestor and via a user interface of the client computing device, the additional information, as taught by Gudmundsson, for the same reasons discussed above with respect to claim 15.
Regarding Claim 19, Chang and Gudmundsson teach the limitations of claim 15.
Chang further discloses wherein the decision includes one of: a full approval, a conditional approval, or a rejection ([Col 8 Ln 23-33] In stage 216, at the funder's system, the funder is notified when the supplier selects its offer. At stage 218, the funder enters into agreement and provides the funds minus the fees, to the supplier as previously described; [Col 15 Ln 40-42] if the funding marketplace server fails to validate a particular match between a funder and supplier, the transaction terminates in stage 412) (Examiner notes that “rejection” has been interpreted as refusing to accept an offer from a funder).
Regarding Claim 20, Chang and Gudmundsson teach the limitations of claim 15.
Chang does not explicitly disclose wherein the transmitting the subsequent request causes the determiner server to transmit a request for reviewing the request for the product to at least one reviewer server over a network.
Gudmundsson, on the other hand, discloses wherein the transmitting the subsequent request causes the determiner server to transmit a request for reviewing the request for the product to at least one reviewer server over a network ([0061] the user may select via the website an option to upgrade the customer's wireless service plan to one of the products presented to the user following the “eligibility” authorization. In response to the selection, the application server 103 generates a second authorization request to determine which of the customer's lines of service are eligible for the upgrade. The application server 103 may thus generate and transmit to the authorization server 101 a second product authorization request identifying the selected wireless service plan. In response to receiving the request, the authorization server 101 performs method 200 under the “eligibility” condition and returns, in step 211, a list of the customer's products or services that are eligible for the selected service plan).
It would have been obvious to one of ordinary skill in the art to include in the computer-implemented method, as taught by Chang, wherein the transmitting the subsequent request causes the determiner server to transmit a request for reviewing the request for the product to at least one reviewer server over a network, as taught by Gudmundsson, for the same reasons discussed above with respect to claim 15.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZACHARY R DONAHUE whose telephone number is (571)272-5850. The examiner can normally be reached M-F 8a-5p.
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, Marissa Thein can be reached at (571) 272-6764. 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.
/ZACHARY RYAN DONAHUE/Examiner, Art Unit 3689
/MARISSA THEIN/Supervisory Patent Examiner, Art Unit 3689