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 .
DETAILED ACTION
This Office Action is in response to an AMENDMENT entered December 09, 2025 for the patent application 17/901,757.
Continued Examination Under 37 C.F.R. §1.114
A request for continued examination ("RCE") under 37 C.F.R. §1.114, including the fee set forth in 37 C.F.R. §1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 C.F.R. §1.114, and the fee set forth in 37 C.F.R. §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 August 13, 2025 has been entered.
Acknowledgements
The Declaration filed on 12/09/2025 under 37 CFR 1.131 has been considered but is ineffective to overcome the Demeyer and Mukherjee references due to the following reasons:
The evidence submitted is insufficient to establish a conception of the invention prior to the effective date of the Demeyer and Mukherjee references. While conception is the mental part of the inventive act, it must be capable of proof, such as by demonstrative evidence or by a complete disclosure to another. Conception is more than a vague idea of how to solve a problem. The requisite means themselves and their interaction must also be comprehended. See Mergenthaler v. Scudder, 1897 C.D. 724, 81 O.G. 1417 (D.C. Cir, 1897). “Conception is the mental part of the inventive act, but it must be capable of proof, as by drawings, complete disclosure to another person, etc.” MPEP 715). Therefore the 37 CFR 1.131 has been considered but is infective to overcome the Demeyer and Mukherjee references and the Office Actions dated 05i01/2024, 08/26/2024, 03/13/2025.
Information Disclosure Statement
The Information Disclosure Statements (IDS) submitted on August 13, 2025 and December 09, 2025 were filed in compliance with the provisions of 37 CFR 1.97. Accordingly, these Information Disclosure Statements are being considered by the Examiner.
Status of Claims
Claims 1, 2, 4 and 11 are pending in the application.
Claims 1, 2, 4 and 11 are currently amended in the application.
Claims 3 and 5 - 10 are cancelled in the application without prejudice or disclaimer.
Response to Arguments
Applicant’s arguments filed December 09, 2025 with respect to claims 1, 2, 4 and 11 have been fully considered but are moot in view of the new ground(s) of rejections.
A review of the claims and updated search necessitated the rejections below.
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.
Claim(s) 1, 2, 4 and 11 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 2, 4 and 11 are either directed to a method or system or computer readable medium, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method claim 1 as the claim that represents the claimed invention for analysis. Claim 1 recites the limitations of:
( A ) registering a user for the cloud-base software application;
( B ) receiving data from the user;
( C ) receiving a request to apply for cloud-based software cost reimbursement from the user;
( D ) processing said request for cloud-based software cost reimbursement automatically and programmatically;
( E ) processing payments of a customer of the user, thus reimbursing the cloud-based software provider from those customer payments before the user has control of them;
( F ) generating customizable terms and conditions for an electronic payment schedule, said terms and conditions including a cost structure upon software usage metrics, and recording agreement of the user to said terms and conditions;
( G ) computing and processing authorization of a payment from payment funds of the customer, said computing and processing authorization of a payment evaluating usage metrics and applying pricing thereto;
( H ) including licensing incentive functions within said terms and conditions; and
( I ) presenting licensing incentive details to the user upon the user registering a new account and upon updating an existing account, and recording acceptance by the user of a structured incentive for payment reimbursement to the software provider; and
( J ) collecting a portion of the payment and sending it to said user following user compliance with said terms and conditions; and
( K ) disbursing a remainder of the payment to the software provider automatically and programmatically.
These limitations without the bolded limitations above, cover performance of the limitations as certain methods of organizing human activity under their broadest reasonable interpretation.
More specifically, these limitations cover performance of the limitations as a fundamental economic practice such.
In summary, if claim 1 limitations, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. (Step 2A-Prong 1: YES. The claims are abstract).
The use of the cloud-based software or any of the bolded limitations in claim 1 are just applying generic computer components to the recited abstract limitations.
Therefore, the above mentioned judicial exception is not integrated into a practical application by merely applying generic computer components (bolded elements).
Furthermore, the “receiving” and “processing” steps are recited at a high level of generality and amounts to mere data gathering/transmitting, which are forms of insignificant extra-solution activity (See MPEP 2106.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
In addition, supported by specification, the computer hardware are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component., see MPEP 2106.05(f), where applying a computer or using a computer is not indicative of a practical application).
Claim 1, limitation ( A ) above in Applicant’s specification para [0044], which discloses “In the alternate embodiment, a user navigates or is directed to a website or application on device and securely signs up or updates their existing account and data is transmitted to databases for the software application online using a device to create a cloud-based software application user account. During the software application account signup data input is transmitted to databases that process it, and the user is presented with the option to securely apply online for a cloud computing cost reimbursement payment model to pay for the software application costs.“.
Also, claim 1, limitation ( C ) – ( E )above in Applicant’s specification para [0016], which discloses “This method of software creates a more integrated and streamlined way to allow a loan borrower to apply for and obtain financing for cloud-based software. The loan application process completes quickly by automatically, programmatically, utilizing affiliated financial, credit, and other applicable data sources. The loan application status is automatically communicated with the loan borrower of the software application where they can rapidly continue with the software usage benefits.“.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Therefore, Claim 1 is directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application).
The claim 1 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements (bolded elements above) amount to no more than mere instructions to apply the abstract idea using generic computer components. In conclusion, merely "applying" the exception using generic computer components cannot provide an inventive concept. Therefore, the claim 1 is not patent eligible under 35 USC 101. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims
Dependent claims 2, 4 and 11 are also rejected under 35 U.S.C. 101.
Regarding claim 2, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 2 states “wherein said processing payments of a customer includes electronic payments of the customer, and wherein said generating customizable terms and conditions has said cost structure upon software usage metrics receiving data from external lead sources and customer interaction, aggregating that data through said usage metrics, and calculating reimbursement to the software provider.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
Regarding claim 4, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 4 states “providing at least one database, said at least one database configured to store and to retrieve the customizable terms and conditions, the data from the user, and the payments of a customer, said at least one database providing a persistent data layer; said processing payments of a customer of the user automatically identifying customer payments; and said generating customizable terms and conditions calculates reimbursement to the software provider following usage metrics established by the cost structure.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
Regarding claim 11, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 11 states “said electronic payment schedule including the payment methods of credit card, debit card, wire transfer, automated clearing house, and mobile payments wherein the payment methods integrate with the terms and conditions for calculating the cost structure in real time and to follow software usage metrics established by the cost structure to deduct cost during said computing and processing authorization of a payment.”. This step amounts to no more than mere data gathering, which is a form of insignificant extra-solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of data gathering to be well- understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
As a result, such limitations do not overcome the requirements as described above. Therefore, claims 2, 4 and 11 are directed to an abstract idea. Thus, claims 1, 2, 4 and 11 are not patent eligible.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 of this title, 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, 2, 4 and 11 are rejected under 35 U.S.C. 103 as being obvious over Michael Demeyer (Pub. # US 2005/0076334 A1 – herein referred to as Demeyer) in view of Partha S. Mukherjee (Pub. # US 2014/0052639 A1 – herein referred to as Mukherjee) and further in view of Don Holm et al. (Pub. # US 2010/0274729 A1 – herein referred to as Holm).
Re: Claim 1, Demeyer discloses a method to allow a user to register for cloud-based software being owned by software provider, said user having a customer, said method comprising:
registering a user for the cloud-base software application (Demeyer, [0044] - Certain functionality modules 106 are protected, meaning that the functionality modules 106 are disabled or otherwise restricted, until all technology modules 107 needed to use the functionality module 106 are registered. For example, unlicensed technology modules 107 may be required to be registered by end user 160 in order to acquire a proper license and relieve the functionality restriction. To relieve the functionality restriction, a registration clearing house 140 is provided to supply software product 110 with the proper relieving mechanism 130. Once registered, software provider 150 may convert an unlicensed technology module 107 into a licensed technology module 107 by compensating a technology holder for the license. Technology modules 107 which are already licensed may also require a registration for the sole purpose of tracking their use.);
receiving data from the user (Demeyer, [0032] - The first party 160 requests registration of the unregistered with the second party 150. Upon receiving the registration request, the second party 150 records the registration and enables the newly registered software by delivering a relieving mechanism to the first party 160. Finally, the second party 150 compensates the fourth party 120 for a license to the actual technology used by the first party 160. Compared to FIG. 2A, the system of FIG. 2B provides compensation to the fourth party 120 only when an end user 160 registers technology owned by the fourth party 120.);
processing payments of a customer of the user, thus reimbursing the cloud-based software provider from those customer payments before the user has control of them (Demeyer, [0079] - The protected software 520 in the third embodiment of the software trading system is the same protected software 520 as in the first and second embodiment. The software 520 can be delivered to the software using entity 414 from the software providing entity 742 by any mechanism such as network downloading, bundled sales, physical delivery, or other known software delivery methods. The software providing entity 742 controls payment for the software using entity 414. It should be understood by one skilled in the art that method of payment is not limited. The software registering entity 746 controls the registration process and the process of relieving a technology limitation for the software using entity 414. The software registering entity 746 can be accessed by the software using entity 414 through a communications network, telephone, mail, voice communications, letter, electronic signature, remote download, storage media delivery, or other known methods.); (Demeyer, [0019] - FIG. 2B is a diagram of one embodiment of a software licensing system in which a third party supplies bundled software to a first party, and a second party records the first party registration information in order to determine payment to a fourth party in exchange for a license to registered technology.);
computing and processing authorization of a payment from payment funds of the customer, said computing and processing authorization of a payment evaluating usage metrics and applying pricing thereto (Demeyer, [0039] - When an end user 160 requests a necessary technology, he will identify himself as a unique and authorized recipient of this technology to the company that provides the technology activation service (in this proposal, the DVD software provider). There are several possible mechanisms for this, including the use of a serial number (provided with initial purchase) or some means of uniquely identifying the computer system 100, such as the Service Code on a Dell personal computer. Based on this identifying information, the appropriate technology is provided to the end user and the software provider 150 is charged for the technology license. Software provider 150 may then choose to recoup the license fees from the hardware producer, or alternatively, a hardware provider 170 may be required to pay license fees to a technology holder 170 based on the end user 160 registration of the software.); (Demeyer, [0037] - FIG. 3 describes the broader aspects of a method for implementing a system as shown in FIGS. 2A-2E. First, a protected software with restricted functionality is provided to a first party (step 200). The first party may, for example, be an end user who has received the software as bundled with a computer system. At step 210, the first party invokes software functionality within the protected software. The restricted functionality requires registration, such as functionality including the playback of DVDs using Dolby Digital decoding. Thus, at step 220 the software determines if registration is required to execute the functionality. If the functionality does not require registration (the "NO" condition), the user may execute the functionality without further action, as represented by step 230. If the functionality does require registration (the "YES" condition), the software is registered with a second or third party (step 240). The second or third party, for instance, may be the hardware provider or software provider. At step 250, the software determines if payment is required to license the newly registered functionality. If a payment is not required (the "NO" condition), as in the system of FIG. 2A, the first party may execute the newly registered software (step 230). If a payment is required (the "YES" condition), the registration triggers a payment to a fourth party from the second or third party (steps 270 and 280). For example, a hardware or software provider may pay a technology holder for the registered technology. Likewise, the registration may trigger a payment from a second party to a third party (step 260). For example, a hardware provider may compensate a soft-ware provider for the registered technology. One skilled in the art would appreciate that depending on the implementation, the payment may actually be made at a later time, even though the first party is authorized immediately to execute the software.);
including licensing incentive functions within said terms and conditions (Demeyer, [0006] - In the context of bundled DVD player software, the prior art system shown in FIG. 1B provides for licensing bundled software between an end user 10, hardware provider 40, a software provider 20, and a technology holder 30. A software provider 20 provides a license for a software product with unlimited functionality to a hardware provider 40 in exchange for compensation. The end user 10 is provided the software product 12 as bundled software included with a computer or computer peripheral supplied by the computer or hardware provider 40. Under the current state of the art, the licensing fees for technologies such as Dolby Digital are paid to the technology holders 40 by the software provider 20 (and/or the hardware provider 40) without regard to the actual use of the licensed technologies by the end user 10. Thus, because usage of the specific features within a software product are not typically tracked, a license to a particular technology is required for each software product 12 sold containing the technology. There fore, there is a discrepancy between the cost of the technology license (by the hardware or software provider 20) and the actual need (by the end user 10), which is disadvantageous for both the end user 10 and software provider 20. For end user 10, the money for the license is wasted if the technology is not used.); and
presenting licensing incentive details to the user upon the user registering a new account and upon updating an existing account, and recording acceptance by the user of a structured incentive for payment reimbursement to the software provider (Demeyer, [0034] - FIG. 2D depicts the broader aspects of a fourth embodiment in which the third party 170 provides the first party 160 with bundled software 110 containing functionality restrictions. The bundled software 110 is produced by the second party 150, and the software 110 incorporates technology requiring a license from a fourth party 120. The first party 160 issues a request to register an unregistered function to the second party 150. Upon receiving the registration request, the second party 150 records the registration and enables the newly registered software by delivering a relieving mechanism to the first party 160. Finally, the third party 170 may compensate a fourth party 120 for the actual technology used by the first party 160. Accordingly, the fourth party 120 may deliver a license to the third party 170.); (Demeyer, [0038] - As a more specific example, referring back to FIG. 2B, the system allows a software provider 150 to license software provided with a computer system 100 or bundled with a computer peripheral for only the technologies required by a end user 160. For example, as a way to reduce wasted license fees, software for playing DVD media can be provided by the hardware provider to an end user 160 with limited functionality, specifically eliminating certain technologies that have associated licensing fees. The end user 160 can, through the Internet or some other electronic or physical mechanism, download or enable these technologies only when needed from the software provider 150. This can occur automatically when the end user 160 first attempts to play a commercial DVD, or on user request at any time prior to this.).
However, Demeyer does not expressly disclose:
receiving a request to apply for cloud-based software cost reimbursement from the user;
processing said request for cloud-based software cost reimbursement automatically and programmatically.
In a similar field of endeavor, Mukherjee discloses:
receiving a request to apply for cloud-based software cost reimbursement from the user (Mukherjee, [0006] - However, the provision of payment services can raise a number of issues. A payment service provider may provide payment services to a number of consumers, and each consumer may regularly use the payment service provider to make payments for purchases. For example, each consumer may use the payment service provider to make payments for purchases several times per month. When the consumers use the payment service provider to make the payment, the payment service provider pays the merchant or individual with whom the purchase was made, and the merchant or individual then pays the payment service provider a fee for the payment service provided. The payment service provider then requests and collects a reimbursement for that payment from a financial institution of the consumer. However, the payment ser vice provider must also pay a fee to the financial institution from which the reimbursement is collected. When this scenario is repeated several time per month for each purchase made by each consumer, these fees paid to the financial institutions from the payment service provider are incurred for each purchase, which adds significant costs to the provision of the on-line payment service. These costs are exacerbated when particular financial institutions that charge higher fees are used for reimbursement for purchases.);
processing said request for cloud-based software cost reimbursement automatically and programmatically (Mukherjee, [0022] - The user device 102 may also include one or more toolbar applications 102b which may be used, for example, to provide user-side processing for performing desired tasks in response to operations selected by the user 112. In one embodiment, the toolbar application 102b may display a user interface in connection with the browser application 102a.).
Therefore, in light of the teachings of Mukherjee, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of Demeyer, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by providing an authorization to collect a reimbursement amount
from a financial institution of the user, wherein the reimbursement amount is at least equal to a cumulative amount of the payments for the plurality of purchases made by the user during the plurality of on-line shopping sessions.
However, Demeyer in view of Mukherjee does not expressly disclose:
generating customizable terms and conditions for an electronic payment schedule, said terms and conditions including a cost structure upon software usage metrics, and recording agreement of the user to said terms and conditions;
collecting a portion of the payment and sending it to said user following user compliance with said terms and conditions; and
disbursing a remainder of the payment to the software provider automatically and programmatically.
In a similar field of endeavor, Holm discloses:
generating customizable terms and conditions for an electronic payment schedule, said terms and conditions including a cost structure upon software usage metrics, and recording agreement of the user to said terms and conditions (Holm, [0141] - Notifications logic 1012 annunciates completion of various stages of approval or other issues of status regarding invoices and disbursement. For example, when an invoice is approved notifications logic 1012 communicates a notification to notifications logic 1023 of payee system 1002. Based on such notifications, a discount may be enabled through discount logic 1016, which is in communication discount logic 1025 of payee system 1002. For example, where an invoice is approved, a discount may be enabled based on an agreement or outstanding dynamic terms offers shown as 1060 that the corresponding payment is made earlier than required under the original terms and conditions. Dynamic terms are additional real-time terms, a set of rules, and/or goal seeker that are established by payer 1060 or payee 1061. These dynamic terms rules 1060 and 1061 are based on business event types (invoice approval, purchase order approval, etc.), a payee or group of payee and a set of new discrete or variable terms. These dynamic term goal seekers allow payer and payee to set desirable outcomes. These dynamic terms can be pre-negotiated up-front or in real-time based on business event types. The approval of these new terms may require digital signature of either payer or payee. Also, third party financial institutions could be involved to provide funding for payee in returns for early discounts.);
collecting a portion of the payment and sending it to said user following user compliance with said terms and conditions (Holm, [0068] - Offer logic 130 makes a request for an offer of different terms other than those established terms associated with a particular transaction. Upon acceptance of the respective offer, the transaction can be effected under the different accepted terms. Thus, offer logic 130 communicates with terms adjustment logic 107 to adjust the terms that will be applied to the particular transaction or transactions. The request for an offer and receipt of the respective response may be made in advance of the event that will trigger payment, according to one embodiment of the invention. Alternatively, at least some portion of the interaction regarding the offer may be made upon receipt of electronic notification of the respective event, such as after receipt of electronic notification that an invoice for the transaction has been approved in payer system 101. Offer logic 130 may include criteria under which offers are accepted. In such an implementation, an offer is accepted only if it meets the configured criteria. Upon acceptance of an offer for newly defined terms, and after the receipt of electronic notification of the respective event, terms adjustment logic 107 calculates a new settlement date and payment amount. A notification is sent to seller system 102 to indicate acceptance of the offer of the newly defined terms.); and
disbursing a remainder of the payment to the software provider automatically and programmatically (Holm, [0131] - Invoice definition engine 1003 and its definition logics are exposed to payee via, global directory and are operative with invoice definition generation/validation 1018 of payee system 1002. The routing/editing logic 1005 includes business logic that governs how an invoice will be processed by AP clerks, and what data entry information will be required to complete the transaction. Routing/editing, logic 1005 can operate differently based on multiple attributes: document type, document value, discount value, etc. Routing/editing logic 1005 acts on HR organization data-base 1008 to define routing/editing/approval work flow based on employee information 1007 and role values 1006. Invoice 1004 is coupled into routing logic 1005. Routing logic 1005 is coupled with employee logic 1007 and role assignment 1006. Routing logic 1005 is coupled with HR data 1008 and with dispute logic 1009, notifications logic 1012 and disbursement logic 1013 of payer system 1001. Notification logic 1012 is configured by the payer, and includes collaborative filtering, and mappings status and notification definitions between internal to external payees. These collaborative filtering and mappings can be designated to a payee or a group of payees.).
Therefore, in light of the teachings of Holm, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of Demeyer in view of Mukherjee, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by providing improved systems to facilitate transactions between buyers and sellers.
Re: Claim 2, Demeyer in view of Mukherjee / Holm discloses the method to allow a user to register for cloud-based software and to pay for the use of the cloud-based software of claim 1
wherein said processing payments of a customer includes electronic payments of the customer (Demeyer, [0059] - While step 314 provides a software provider 150 with registration information 134 for use in tracking usage patterns of technology modules 107, the licensing system of FIG. 4 is additionally used to determine the licensing royalties to be paid for only the technology modules actually used by an end user 160. Specifically, software provider 150 may produce a software product 110 without initially pro viding payment for a license from a technology holder 120. Instead, software provider 150 uses the registration information 134 received in step 314 to determine the royalties to be paid to a technology holder 120. Thus, as shown in step 315, only after the registration of a technology module 107 by an end user 160, software provider 150 provides payment for the license to technology holder 120. It should be appreciated that payment may be made instantaneously, or billed on a periodic basis, through well-known billing methods. It should also be appreciated that hardware provider 170 may also be required to submit a payment to technology holder 120 according to the collected registration information 134.), and
wherein said generating customizable terms and conditions has said cost structure upon software usage metrics receiving data from external lead sources and customer interaction, aggregating that data through said usage metrics, and calculating reimbursement to the software provider (Holm, [0117] - In example 5, a bank is paying the supplier on behalf of two buyers who have received and processed invoices from this supplier. The table shows the trigger events within the buying organizations occurred on day 5 relative to the due date. Adjusting for payment method delay places the early pay opportunity at 23 days. With an effective daily discount rate of 1% (2% for 20 days early 0.1% per day), the effective dis-count rate applied to each invoice is 2.3%. For buyer 1, this translates to a discount of $2,300, and $4,600 for buyer 2. Subtracting the discount amounts from the original invoice amount yields net payments of $97,700 and $195,400 for buyer one and two, respectively. Also note, because the financial institution is making payment to a single supplier in this example, the payments can be consolidated into one or initiated separately depending upon the financial institutions preferences. The financial institution receives $100,000 from buyer 1 on day 60, and $200.000 from buyer 2 on day 50 in addition, note that buyer 1 is not subject to receiving as rebate from the financial institution. Buyer 0.2 in this instance will receive a rebate in the amount of$460, or 10% of the discount capture rate. Note, the bank can apply different methods to the calculation such as adjusting the $460 down based on cost of capital and duration the credit is outstanding, which in this case could be 20 days (50 days-30 days (original due date of invoice). Also note that the numerical or lookup methods discussed in Examples 1-4 can also apply to the banking oriented embodiment of the system.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 4, Demeyer in view of Mukherjee / Holm discloses the method to allow a user to register for cloud-based software and to pay for the use of the cloud-based software of claim1,further comprising:
providing at least one database, said at least one database configured to store and to retrieve the customizable terms and conditions, the data from the user, and the payments of a customer, said at least one database providing a persistent data layer (Holm, [0100] - The following relate to setting up the vendor for financing. The normal vendor terms and conditions are received (block 605). Enrollment is received from the vendor for the additional terms and conditions with the financial institution (block 606). These additional conditions may include event type, discount rate, new term/due, and/or whether fixed or interpolated. Next, the approval is received from the financial institution of the vendor and the additional terms and conditions (block 607). Such approval may be based on various financial criteria regarding the vendor and the terms and conditions. Additionally, the approval may be based on an analysis of the security of basing payment to the vendor on particular events such as electronic approval of the invoice by the buyer or electronic notification of release of payment by the buyer. Based on the particular events selected and the type of notification, an analysis is made of the credit risk and appropriate financing terms are provided.);
said processing payments of a customer of the user automatically identifying customer payments (Holm, [0080] - FIG. 3 shows a block diagram of a system for payment with logic to make offers to a set of entities according to an embodiment of the invention. FIG. 3 includes buyer system 301, seller system A 302, seller system B 303, seller system C 304, and seller system D 305. Also shown in FIG. 3 are set of outcomes 306 and 307 as well as response 308 and 309. Buyer system 301 includes goal seeker logic 313, payment logic 314 and event generation logic 315. Also shown in buyer system 301 are event A 317 and event B 316. Goal seeker logic 313 includes rules 318, selection logic 319 and stop logic 320. Event A 317 and event B 316 each include information regarding the event. For example, event A 317 includes event type 324, identification of the vendor 321, identification of the amount in the transaction 322 and the settlement date 323. Offer request will be sent to proper seller based on vendor identification of the event.); and
said generating customizable terms and conditions calculates reimbursement to the software provider following usage metrics established by the cost structure (Holm, [0141] - Notifications logic 1012 communicates completion of various stages of approval or other issues of status regarding invoices and disbursement. For example, when an invoice is approved notifications logic 1012 communicates a notification to notifications logic 1023 of payee system 1002. Based on such notifications, a discount may be enabled through discount logic 1016, which is in communication discount logic 1025 of payee system 1002. For example, where an invoice is approved, a discount may be enabled based on an agreement or outstanding dynamic terms offers shown as 1060 that the corresponding payment is made earlier than required under the original terms and conditions. Dynamic terms are additional real-time terms, a set of rules, and/or goal seeker that are established by payer 1060 or payee 1061. These dynamic terms rules 1060 and 1061 are based on business event types (invoice approval, purchase order approval, etc.), a payee or group of payee and a set of new discrete or variable terms. These dynamic term goal seekers allow payer and payee to set desirable outcomes. These dynamic terms can be pre-negotiated up-front or in real-time based on business event types. The approval of these new terms may require digital signature of either payer or payee.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 11, Demeyer in view of Mukherjee / Holm discloses the method of tracking a project performed by a customer and disbursing payment for the project to a user of said method of claim 1 further comprising:
said electronic payment schedule including the payment methods of credit card, debit card, wire transfer, automated clearing house, and mobile payments wherein the payment methods integrate with the terms and conditions for calculating the cost structure in real time and to follow software usage metrics established by the cost structure to deduct cost during said computing and processing authorization of a payment (Holm, [0079] - If the new terms have been accepted, and if the trigger event is release of payment scheduled (block 214), then it is determined whether the release of payment occurs before the original due date (block 221). If the release of payment does not occur according to the original due date (block 221), then payment is effected according to the original terms (block 222). If the release of payment is scheduled before the original due date (block 221), and the trigger event is the release of payment scheduled, then discounted early payment is effected (block 220). The early discounted payment may take place upon, or shortly after the trigger event.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN H HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 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, MATTHEW S. GART can be reached on 571-272-39558395. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696