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 .
Double Patenting
Claims 2–21 are rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims 1–16 of U.S. Patent No. 12,373,900 B2.
Although the claims are not identical, they are not patentably distinct because the patented claims recite substantially the same computer-implemented performance-contract revenue-projection system, including configuring performance-obligation rules, processing transaction lines, associating performance obligations with revenue-recognition events, processing variable-consideration types and historical transaction data, projecting revenue, correcting or adjusting projected revenue, and reporting the resulting performance-obligation information.
The additional limitations directed to selection of particular variable-consideration types, rollover processing, estimates processing, replacement with an updated performance contract, and storage-medium implementation constitute obvious variations or implementations of the patented variable-consideration and revenue-adjustment framework and do not establish patentable distinctness.
Accordingly, Current Claims 2–21 are rejected for non-statutory obviousness-type double patenting over the claims of U.S. Patent No. 12,373,900 B2.
A statutory same-invention double-patenting rejection under §101 would not be my preferred rejection here. The claim sets contain meaningful wording and scope differences, particularly the newly recited rollover variable-consideration type, estimates variable-consideration type, contract replacement/update, and CRM formulation. OTDP is the cleaner examiner position because it addresses whether those differences are patentably distinct, rather than requiring identity of claimed subject matter.
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 2–21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without reciting additional elements sufficient to integrate the judicial exception into a practical application, and without reciting additional elements that amount to significantly more than the judicial exception.
Independent claims 2, 9, and 16 respectively recite method, system, and non-transitory computer-storage-medium embodiments of substantially the same revenue-recognition and revenue-projection subject matter.
The dependent claims further limit the accounting treatment of variable consideration, correction of projected revenue, contract adjustments, rollover processing, estimates processing, and performance-obligation templates.
I. STEP 1 — STATUTORY CATEGORY
Claim 2 recites a computer-implemented method and therefore falls within the statutory category of a process.
Claim 9 recites a system comprising one or more computers and one or more storage devices and therefore falls within the statutory category of a machine.
Claim 16 recites one or more non-transitory computer storage media and therefore falls within the statutory category of manufacture.
Accordingly, independent claims 2, 9, and 16 satisfy Step 1.
The claims are therefore evaluated under Step 2A of the Alice/Mayo framework.
II. STEP 2A — PRONG ONE
Under Step 2A, Prong One, the Examiner determines whether the claim recites a judicial exception.
A. Independent Claim 2
Claim 2 recites, in pertinent part:
configuring a set of performance obligation rules for evaluating a performance contract containing variable consideration;
receiving rules containing conditions;
obtaining performance-contract information including transaction lines;
applying the performance-obligation rules to associate transaction lines with revenue-recognition events;
selecting a variable-consideration type representing variable consideration of the contract;
obtaining historical transaction data associated with the selected variable-consideration type;
using the revenue-recognition events and historical transaction data to project revenue; and
generating a report representing performance obligations corresponding to the revenue-recognition events.
These limitations, considered under their broadest reasonable interpretation, recite administering the financial/accounting treatment of a performance contract containing variable consideration and projecting revenue attributable to contractual performance obligations.
More particularly, the claim receives rules defining contractual performance obligations, applies those rules to transactions under a contract, classifies variable consideration, considers historical transaction information, determines projected revenue, and reports revenue associated with contractual performance obligations.
These limitations concern commercial and legal interactions, including contractual obligations and financial/accounting activities associated with commercial agreements.
The claimed operations therefore fall within the abstract-idea grouping of certain methods of organizing human activity, particularly commercial or legal interactions.
Certain limitations additionally involve evaluation of information and financial calculations. For example, applying rules and historical transaction data to project revenue constitutes evaluation and calculation of financial information. However, the Examiner principally identifies the exception as the claimed contract administration, revenue-recognition, and financial-accounting process, rather than relying exclusively upon the mental-process grouping.
Accordingly, claim 2 recites an abstract idea.
B. Independent Claim 9
Claim 9 recites substantially the same operations as claim 2 in system form.
The claimed computers: configure performance-obligation rules; receive rule conditions;
obtain contract transaction lines; apply the rules to associate transaction lines with revenue-recognition events; receive selection of a variable-consideration type; obtain historical transaction data; use that information to project contract revenue; and generate a report representing performance obligations.
Accordingly, claim 9 likewise recites the abstract financial/business process of administering contractual performance obligations and variable consideration to determine and report projected revenue.
Merely reciting the underlying business/accounting operations as operations performed by one or more computers does not remove the recited commercial activity from the abstract-idea grouping.
Accordingly, claim 9 recites an abstract idea.
C. Independent Claim 16
Claim 16 recites substantially the same operations as claims 2 and 9, but embodies those operations as computer-program instructions stored on one or more non-transitory computer storage media.
The underlying functionality remains: receiving and applying performance-obligation rules; processing contractual transaction lines; classifying variable consideration; obtaining historical transaction data; projecting revenue; and reporting performance obligations associated with revenue-recognition events.
Accordingly, claim 16 likewise recites the abstract idea of administering financial/accounting obligations arising from a commercial contract and determining projected revenue therefrom.
Thus, independent claims 2, 9, and 16 recite a judicial exception under Step 2A, Prong One.
III. STEP 2A — PRONG TWO
The claims are next evaluated to determine whether additional elements integrate the identified judicial exception into a practical application.
A. Claim 2 — Additional Elements
The additional technological elements of claim 2 include: a server system comprising a plurality of computers; one or more client devices; a communication network; one or more interfaces; and a database communicating over the network.
These elements do not integrate the identified abstract idea into a practical application.
The server system performs the financial/accounting operations. The interfaces receive the user's performance-obligation rules and variable-consideration selection. The database supplies historical transaction information. The communication network communicates the financial information among the recited computer components. The client devices provide access to the interfaces. The claim does not recite a particular improvement in server operation, distributed-computing architecture, database architecture, network communication, data-storage technology, computer security, or user-interface technology.
Rather, these computer components provide the environment and tools through which the underlying contractual accounting and revenue-projection process is carried out.
Nor does the claim recite a particular technological technique for processing historical data that improves the functioning of the computer itself. The historical transaction data is used because of the financial information it represents—namely, to estimate variable consideration and projected contract revenue.
Similarly, the claimed report conveys the result of the underlying financial/accounting analysis.
Accordingly, the additional elements merely implement the judicial exception using computer components and do not integrate the exception into a practical application.
Claim 2 is therefore directed to the judicial exception.
B. Claim 9 — Additional Elements
Claim 9 recites: one or more computers; one or more storage devices storing instructions; client devices; a communication network; interfaces; and a database.
These components perform substantially the same functions discussed regarding claim 2.
The storage devices store instructions implementing the claimed accounting rules and calculations; the computers execute those instructions; the interfaces receive information; the network communicates information; and the database supplies historical transaction information.
The claim does not recite a technological improvement in the functioning of these components.
Rather, the computer architecture is used to automate the underlying business/accounting process.
Accordingly, claim 9 does not integrate the judicial exception into a practical application.
C. Claim 16 — Additional Elements
Claim 16 recites: one or more non-transitory computer storage media; computer program instructions; one or more computers; client devices; interfaces; a communication network; and a database. The storage media merely store instructions causing computers to execute the identified revenue-recognition and revenue-projection process. The claim does not improve computer-storage technology or require a particular technological organization of stored information.
Likewise, the computers, interfaces, network, and database perform their ordinary information-processing roles in implementing the financial/accounting process.
Accordingly, claim 16 does not integrate the abstract idea into a practical application.
IV. DEPENDENT CLAIMS — STEP 2A
Claims 3, 10, and 17 — Correcting Projected Revenue
Claims 3, 10, and 17 further require: determining that projected revenue contains one or more incorrect values; identifying impacted transactions; and automatically adjusting projected revenue based on adjusted variable consideration.
These limitations further refine the underlying accounting process.
Determining that a revenue projection is incorrect, identifying the financial transactions affected by the error, and correcting the projected revenue constitute financial/accounting activities.
Although the correction is performed “automatically,” automation of the financial correction does not itself provide a technological improvement.
The claims do not recite an improvement in error-detection technology, database integrity, computer reliability, or another technical field. Rather, the “incorrect values” are incorrect financial projections, and the resulting correction changes the financial/accounting result.
Accordingly, claims 3, 10, and 17 do not integrate the judicial exception into a practical application.
Claims 4, 11, and 18 — Rollover Variable-Consideration Type
Claims 4, 11, and 18 specify selection of a: rollover variable-consideration type.
The additional limitation further categorizes the type of financial consideration associated with the performance contract.
The claimed classification concerns the accounting treatment of variable consideration rather than an improvement to the computer or another technology.
Accordingly, claims 4, 11, and 18 remain directed to the identified abstract idea.
Claims 5, 12, and 19 — Variable-Consideration Rollover Data
Claims 5, 12, and 19 further require computing: variable consideration rollover data based on an adjustment to the performance contract.
These limitations likewise concern how financial consideration associated with contractual obligations is accounted for following a contractual adjustment. Computing financial rollover data based upon a changed contract further refines the identified abstract accounting process. The claims do not specify a technological improvement in the manner in which the computers calculate, store, retrieve, or communicate data.
Accordingly, these claims do not integrate the exception into a practical application.
Claims 6, 13, and 20 — Replacement Contract
Claims 6, 13, and 20 specify that: the adjustment to the performance contract comprises replacement of the performance contract with an updated performance contract.
Replacing an existing contractual arrangement with an updated contractual arrangement constitutes a commercial/legal activity. Processing the resulting accounting consequences using the recited computers does not transform that activity into a technological improvement.
Accordingly, claims 6, 13, and 20 remain directed to the judicial exception.
Claims 7, 14, and 21 — Rollover and Estimates Types
Claims 7, 14, and 21 specify that the plurality of variable-consideration types includes:
a rollover variable-consideration type; and an estimates variable-consideration type.
These limitations merely classify financial consideration according to alternative accounting treatments.
The particular financial categories do not improve the operation of the recited computers, database, network, or another technological field.
Accordingly, claims 7, 14, and 21 remain directed to the abstract idea.
Claims 8 and 15 — Performance-Obligation Templates
Claims 8 and 15 require: associating transaction lines with a performance obligation template of one or more performance obligation templates.
The performance-obligation template represents contractual/accounting criteria used to categorize transaction lines according to performance obligations.
The claim does not recite a particular technological data structure that improves computer functionality. Rather, the template is used because of the contractual/accounting information represented by the template.
Thus, the template limitation further organizes information according to the underlying contractual revenue-recognition process and does not integrate the judicial exception into a practical application.
Accordingly, claims 8 and 15 remain directed to the judicial exception.
V. CLAIMS AS AN ORDERED COMBINATION — STEP 2A, PRONG TWO
The claims have also been considered as ordered combinations rather than merely as collections of individual limitations.
The claimed sequence generally performs the following: establishes accounting rules for a performance contract; obtains contractual transaction information; associates transactions with revenue-recognition events; identifies the applicable variable-consideration treatment; obtains historical financial information; calculates projected revenue; reports the resulting performance obligations; identifies erroneous projections where applicable; and adjusts the financial results when contractual or variable-consideration circumstances change.
This ordered combination improves the administration and automation of the financial/accounting process, rather than the operation of the underlying computers.
The result of the claimed process is projected and adjusted revenue information concerning contractual performance obligations.
Accordingly, considering all limitations together does not demonstrate that the identified abstract idea has been integrated into a practical application.
VI. STEP 2B — SIGNIFICANTLY MORE
Because claims 2–21 are directed to the identified judicial exception, the claims are evaluated under Step 2B to determine whether the additional elements, individually and as an ordered combination, amount to significantly more than the exception.
The additional technological elements include: server systems; computers;
processors implicit in execution of the computer instructions; storage devices;
non-transitory computer storage media; client devices; user interfaces; communication networks; databases; and computer-program instructions.
As claimed, these components perform their respective information-processing functions in implementing the underlying revenue-recognition and accounting process.
The server/computers execute the rules and calculations.
The interfaces receive accounting rules and user selections.
The database supplies historical transaction information.
The network communicates information.
The storage devices/media store the instructions.
The report presents the resulting financial information.
Nothing in the claims requires a specialized computer architecture or a particular improvement in computer processing, network operation, database functionality, data storage, or graphical-user-interface technology.
The additional elements likewise do not impose a meaningful limitation upon the abstract idea beyond implementing the contractual accounting process in a computerized environment.
Considered as an ordered combination, the computer components automate the process of configuring contractual accounting rules, classifying transactions, estimating variable consideration, projecting revenue, correcting projected values, and reporting the resulting accounting information.
The ordered combination therefore does not transform the character of the claims into patent-eligible applications.
Accordingly, the additional elements, individually and in combination, do not amount to significantly more than the identified judicial exception.
VII. INDEPENDENT CLAIMS 2, 9, AND 16
Accordingly:
Claim 2 is directed to administering performance obligations and variable consideration associated with a contract to project and report revenue, implemented using a server system, client devices, interfaces, a network, and database.
Claim 9 recites substantially the same abstract financial/accounting process implemented as operations of computers and storage devices.
Claim 16 recites substantially the same process embodied as computer-program instructions stored on non-transitory computer storage media.
The change in statutory form among method, system, and computer-storage-medium claims does not materially alter the eligibility analysis because each independent claim recites substantially the same abstract revenue-recognition and contractual accounting functionality.
VIII. DEPENDENT CLAIMS 3–8, 10–15, AND 17–21
The dependent claims do not add limitations sufficient to render the claims eligible.
Claims 3, 10, and 17 further automate correction of projected financial values.
Claims 4, 11, and 18 specify a rollover accounting category.
Claims 5, 12, and 19 calculate rollover data following a contractual adjustment.
Claims 6, 13, and 20 specify replacement of the performance contract with an updated contract.
Claims 7, 14, and 21 specify rollover and estimates categories of variable consideration.
Claims 8 and 15 classify transaction lines using performance-obligation templates.
These limitations further define the underlying contractual/accounting process rather than provide an improvement to computer functionality or another technology.
Thus, claims 2–21 are rejected under 35 U.S.C. 101 as being directed to a judicial exception without reciting additional elements that integrate the judicial exception into a practical application or amount to significantly more than the judicial exception.
Under Step 2A, Prong One, the claims recite a certain method of organizing human activity, particularly commercial/legal interactions involving:
administering contractual performance obligations; accounting for variable consideration; recognizing and projecting revenue associated with contractual transactions; correcting projected revenue; and reporting financial results.
Under Step 2A, Prong Two, the additional server system, computers, client devices, storage devices, interfaces, communication network, database, and computer storage media merely provide the computer environment for carrying out the identified financial/accounting process.
The claims do not, on their face, recite a specific improvement to computer functionality, database technology, distributed processing, networking, data storage, or another technical field. Nor does the claimed combination otherwise meaningfully limit the identified abstract idea so as to integrate the exception into a practical application.
Under Step 2B, the additional computer elements, whether considered individually or as an ordered combination, do not transform the character of the claims into patent-eligible subject matter. Rather, the computer components implement and automate the underlying contractual revenue-recognition and financial-accounting process.
Therefore, claims 2–21 are ineligible under 35 U.S.C. 101.
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.
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 2–21 are rejected under 35 U.S.C. 103 as being unpatentable over US 2009/0216582 A1 (“Oracle ’582”) in view of US 2008/0033873 A1 (“Oracle ’873”), further in view of US 2015/0310570 A1 (“Duetto”), and US 2007/0168209 A1 (“Shah”).
Claim 2 recites a computer-implemented method comprising the following limitations.
“providing, by a server system comprising a plurality of computers to one or more client devices over a communication network, one or more interfaces for configuring a set of one or more performance obligation rules for evaluating a performance contract that includes variable consideration”
Oracle ’582 teaches an enterprise resource management environment for managing performance obligations and teaches that performance-obligation data can be populated and modified through interactions with other systems, devices, and applications.
Oracle ’582 teaches creating a performance-obligation electronic document or other electronic entity for recording criteria relating to the performance obligation and teaches interaction with order-entry, costing, supply-management, and customer-management systems.
Oracle ’582 particularly teaches Release Criteria 308, which stores rules defining how a performance obligation is released, and explains that performance-obligation release criteria may be negotiated at a customer level and modified during maintenance of the obligation (¶¶[0031]-[0034], [0039]-[0046]; Fig. 3–4).
Oracle ’582 therefore teaches computerized configuration and storage of rules/criteria governing performance obligations.
“receiving ... first input data specifying the set of one or more performance obligation rules, each performance obligation rule ... including one or more conditions”
Oracle ’582 teaches storing Release Criteria 308 representing rules governing how performance obligations are released. It further teaches that order information includes criteria governing release of the obligation and that customer-management information can provide negotiated release criteria (¶¶[0039]-[0046]; Figs. 3–4).
Oracle ’582 further teaches modifying release criteria during maintenance of an existing performance obligation (claims 8, 16 and 22).
Thus, Oracle ’582 teaches receiving and maintaining criteria/rules associated with individual performance obligations.
“obtaining ... information associated with the performance contract, the information comprising transaction lines associated with one or more transactions of the performance contract”
Oracle ’582 teaches obtaining information from an order-entry system including what is being sold, price, delivery information, and criteria governing release of the corresponding performance obligation. A single order can generate multiple performance obligations (¶¶[0043]-[0046]; Fig. 4).
Oracle ’582 also teaches obligation identifiers, debit amounts, credit amounts, valuation totals, satisfied valuations, and remaining valuations associated with individual obligations (¶¶[0039]-[0042]).
The order information and associated performance-obligation records correspond to transaction-level accounting information.
“applying ... the set of one or more performance obligation rules to the performance contract to associate the transaction lines with one or more revenue recognition events”
Oracle ’582 teaches applying stored release criteria to performance obligations and reducing/releasing the valuation of an obligation when the applicable criteria are satisfied. The released amount is reflected through the performance-obligation sub-ledger and general ledger (¶¶[0039]-[0046]; claims 6, 12–14).
Oracle ’582 further teaches recognizing the valuation of a performance obligation based upon recognition criteria (claim 13).
Thus, Oracle ’582 teaches associating transaction/order information with performance obligations and applying performance-obligation criteria to determine recognition/release events.
“receiving ... second input selecting, among a plurality of variable-consideration types, a variable-consideration type representing the variable consideration of the performance contract”
Oracle ’582 teaches multiple criteria affecting valuation and maintenance of performance obligations, including fair-market-value changes, costing changes, supply changes, customer-relationship changes, negotiated criteria, and other criteria (¶¶[0043]-[0047]).
Oracle ’582 does not expressly characterize these alternatives as a user-selected “variable-consideration type.”, “receiving ... historical transaction data associated with the selected variable-consideration type”; “using ... revenue recognition events and historical transaction data associated with the selected variable-consideration type to project revenue for the performance contract”; “generating ... a report based on the projected revenue ... comprising data representing one or more performance obligations corresponding to the one or more revenue recognition events”
Oracle ’582 teaches maintaining a performance-obligation sub-ledger containing obligation IDs and debit/credit balances, summarizing the performance obligations into an entry reflecting the total balance, providing that information to the general ledger, and using the resulting information in preparation of enterprise financial information (¶¶[0040]-[0042]; Fig. 3).
However, Oracle ’582 does not expressly teach that the reported amount is projected revenue generated using historical transaction data.
Oracle ’582 does not expressly disclose: receiving a user selection among expressly designated variable-consideration types; receiving historical transaction data corresponding to the selected type; using that historical transaction data to forecast/project revenue; and the full claimed client/server interface arrangement for configuring the rules.
Shah teaches a revenue-recognition model operating in an automated computer environment.
Shah expressly teaches: receiving rules over a communications network associated with an entity; receiving information associated with a transaction; and implementing automated processes to determine whether revenue from the transaction is recognizable (¶¶[0017], [0024]-[0029]; claim 1).
Shah further teaches that transaction information may include customer identification, transaction date, amount, products/services, transaction description, customer type, and agreement type, and that different users interact with the transaction through network endpoints (¶¶[0024]-[0029]).
Thus, Shah supplies the expressly networked receipt/configuration of revenue-recognition rules and application of those rules to transaction information.
Duetto teaches a historical-data interface module that obtains historical transaction information, including bookings from previous periods, and a forecasting module that combines the historical transaction data using a selected forecasting method.
The forecasting method can be default or user selected and may comprise regression, moving average, exponential smoothing, Bayesian forecasting, or another forecasting technique.
Duetto expressly teaches using historical transaction data to generate estimates of future activity and storing the resulting information as forecast data (¶¶[0041]-[0045]).
Duetto additionally teaches comparing a prior forecast against actual historical transaction data, determining forecast error, and dynamically selecting the forecasting configuration producing the lowest error (¶¶[0046]-[0052]).
Thus, Duetto teaches the missing concept of: historical transaction data → selected analytical treatment → future projection.
Oracle ’873 teaches a revenue-management system maintaining predefined rollover rules and using those rules to perform rollover processing. It further teaches determining whether events require recalculation of rollover and recalculating the resulting rollover information. Oracle ’873 expressly recognizes multiple revenue-processing circumstances and predefined rollover treatments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Oracle ’582's computerized performance-obligation accounting system according to Shah's network-based revenue-recognition rule processing, Duetto's historical-data forecasting technique, and Oracle ’873's configurable rollover/revenue-processing rules.
Oracle ’582 already seeks to maintain accurate current valuations of performance obligations according to stored criteria and to reflect those valuations in enterprise accounting information. Shah teaches a known networked mechanism for obtaining revenue-recognition rules and applying automated processes to transaction information. Duetto teaches a known technique for improving a future financial/business projection by applying selected forecasting methods to historical transaction data. Oracle ’873 teaches predefined alternative rollover rules and recalculation of financial/account data.
A person of ordinary skill would have been motivated to use Shah's network-based rules interface with Oracle ’582 to facilitate centralized configuration and application of performance-obligation recognition rules across an enterprise. The skilled artisan further would have been motivated to apply Duetto's historical-data forecasting technique to Oracle ’582's transaction/performance-obligation information because historical results provide known empirical information for estimating future financial results. Finally, providing selectable accounting treatments such as Oracle ’873's rollover treatment would predictably permit the system to apply an appropriate calculation according to the type of variable financial condition presented by the contract.
The combination merely applies known revenue-recognition, accounting-rule, rollover, and historical-data forecasting techniques to Oracle ’582's known computerized performance-obligation accounting system, with each component performing its known function and yielding the predictable result of projected revenue associated with performance obligations.
Accordingly, claim 2 would have been obvious over Oracle ’582 in view of Shah, Duetto, and Oracle ’873.
Claim 3 further requires: “determining that the projected revenue ... includes one or more incorrect values”
Duetto teaches comparing forecast values against actual historical transaction information and determining forecasting error using, for example, median absolute deviation or mean absolute percentage error (¶¶[0046]-[0049]).
“in response, identifying a plurality of impacted transactions”
Duetto teaches historical transaction records corresponding to particular periods and determines which forecasting configuration produces the erroneous or more accurate result (¶¶[0046]-[0052]).
Oracle ’873 additionally teaches identifying delayed events affecting a previously calculated rollover.
“automatically adjusting the projected revenue based on an adjusted variable consideration”
Oracle ’873 teaches that delayed events can cause recalculation of rollover and that recalculation can trigger rerating of transactions received during the new cycle, thereby causing the rollover to be correctly applied.
Duetto similarly teaches adjusting the forecast based upon differences between historical and current information (¶¶[0053]-[0059]).
It would have been obvious to automatically recalculate affected financial projections once the system identifies that historical/updated transaction information makes the existing calculation inaccurate, because both Oracle ’873 and Duetto expressly teach recalculation/correction following identification of changed or erroneous underlying information.
Accordingly, claim 3 is unpatentable over the combination.
Claim 4 specifies: “receiving a selection of a rollover variable-consideration type.”
Oracle ’873 expressly teaches predefined rollover rules maintained by the revenue-management system and applying those rules to determine rollover processing.
In the combined system, it would have been obvious to identify the financial treatment governed by those rules as a rollover type and permit its selection from the available financial-processing treatments because selecting the applicable rule/type is a predictable implementation of a system supporting multiple accounting treatments.
Accordingly, claim 4 is unpatentable.
Claim 5 requires: “the rollover variable-consideration type is configured to compute variable consideration rollover data based on an adjustment to the performance contract.”
Oracle ’873 teaches computing rollover, determining after the original processing whether delayed events have occurred, determining whether recalculation is required, and recalculating rollover under predefined rollover rules. The recalculated rollover can cause rerating of transactions so that the proper rollover is applied.
Oracle ’582 further teaches revaluation of an existing performance obligation in response to changed criteria, including changes in fair market value, costing, supply, or customer relationships (¶¶[0046]-[0047]; claim 7).
It would therefore have been obvious to apply Oracle ’873's recalculated rollover processing when a contractual/performance-obligation adjustment changes the financial information maintained by Oracle ’582.
Claim 5 is therefore unpatentable.
Claim 6 specifies: “the adjustment to the performance contract comprises a replacement of the performance contract with an updated performance contract.”
Oracle ’582 teaches maintaining and modifying an existing performance obligation when underlying conditions change, including revaluation and modification of release criteria.
Shah teaches transaction information including agreement type, special terms, estimated dates, contingencies, and related transactions and applies automated revenue-recognition processing to the resulting transaction information (¶¶[0024]-[0029]).
Neither reference literally uses the phrase “replacement of the performance contract with an updated performance contract.”
However, where updated contractual information changes the accounting criteria governing the same commercial arrangement, replacing the stored prior contractual record with the updated contractual record would have been an obvious data-maintenance alternative to modifying the existing record in place. Both alternatives predictably cause subsequent revenue processing to operate upon the current contractual terms.
Thus, claim 6 is rejected as an obvious implementation of Oracle ’582's contract/performance-obligation modification teachings in view of Shah's processing of agreement terms and related transactions.
Claim 7 requires: “the plurality of variable-consideration types comprises the rollover variable-consideration type and an estimates variable-consideration type.”
Oracle ’873 teaches the rollover processing category.
Duetto teaches an estimate/forecasting processing category using historical transaction information and selected forecasting methods to generate future estimates (¶¶[0041]-[0045]).
Once the combined system provides both known treatments, representing them as selectable processing “types” would have been an obvious organization of the available financial-calculation functionality.
Accordingly, claim 7 is unpatentable.
Claim 8 requires: “associating the transaction lines with a performance obligation template of one or more performance obligation templates.”
Oracle ’582 teaches creating electronic performance-obligation records containing an obligation identifier, release criteria, total valuation, satisfied valuation, and remaining valuation.
The performance-obligation record therefore constitutes a predefined electronic structure populated with transaction/order-specific information (¶¶[0039]-[0046]; Figs. 3–4).
Oracle ’582 further teaches that a single order can generate multiple performance obligations and that information from order-entry and other enterprise systems populates the corresponding obligation records.
It would have been obvious to provide multiple predefined templates corresponding to the different performance-obligation records because templating known electronic records for repeated transaction processing constitutes a predictable implementation of Oracle ’582's performance-obligation data structure.
Accordingly, claim 8 is unpatentable.
Claim 9 recites the system counterpart of claim 2.
Oracle ’582 expressly teaches a system for tracking performance obligations comprising a processor and memory storing executable computer code.
The memory contains code for: generating performance obligations; recording performance-obligation valuations; recording criteria governing release; reducing valuation based on those criteria; and reflecting performance-obligation balances in a general ledger.
Oracle ’582 further teaches maintaining/revaluing performance obligations and modifying release criteria.
Thus, Oracle ’582 teaches the claimed computer/storage architecture together with the core performance-obligation functionality.
For the substantive operations: providing interfaces and configuring performance-obligation rules is taught by Oracle ’582's electronic performance-obligation records and rule/release criteria, further in view of Shah's receipt of revenue-recognition rules over a communications network; receiving rules containing conditions is taught by Oracle ’582 and Shah; obtaining transaction lines is taught by Oracle ’582's order-entry information and Shah's transaction records; associating transaction information with revenue-recognition events is taught by Oracle ’582's performance-obligation release/recognition criteria and Shah's automated determination of recognizable revenue; selecting variable-consideration processing is taught by Oracle ’873's configurable rollover rules together with Duetto's selectable forecasting treatment; receiving historical transaction data is taught by Duetto; using historical transaction data to project future results is taught by Duetto; and generating accounting/report information representing performance obligations is taught by Oracle ’582's sub-ledger/general-ledger architecture.
Therefore, it would have been obvious to modify Oracle ’582's processor/memory performance-obligation system with Shah's networked revenue-recognition rule processing, Oracle ’873's configurable rollover processing, and Duetto's historical-transaction forecasting.
All references address computerized processing of financial, transaction, revenue, or revenue-management information. Oracle ’582 provides the underlying performance-obligation architecture; Shah provides network-based revenue-recognition rules; Oracle ’873 provides configurable rollover/recalculation functionality; and Duetto provides historical-data-based forecasting.
Combining these known functions would predictably allow Oracle ’582's computerized system to configure recognition rules remotely, choose an applicable variable financial treatment, use historical transactions to estimate future results, and report those results in the existing performance-obligation accounting environment.
The combination represents use of known techniques to improve a similar computerized financial system in the same manner and would have yielded predictable results. No change in the respective principles of operation is required. Accordingly, claim 9 would have been obvious over Oracle ’582 in view of Shah, Oracle ’873, and Duetto.
Claim 10 corresponds substantively to claim 3. Duetto teaches determining forecast error by comparing forecast data against historical actual data and selecting a more accurate forecasting configuration (¶¶[0046]-[0052]).
Oracle ’873 teaches detecting events requiring recalculation, recalculating rollover, and rerating affected transactions.
It would have been obvious to use those teachings in Oracle ’582's system to identify transactions affected by inaccurate projections and automatically adjust the resulting projected financial amount.
With respect to Claim 11 Oracle ’873 teaches predefined rollover rules and rollover processing. Providing the rollover treatment as one selectable financial-processing type is an obvious implementation of the configurable rollover functionality.
With respect to Claim 12 Oracle ’873 teaches recalculating rollover after changed/delayed events and rerating transactions following recalculation.
Oracle ’582 teaches revaluation following changes affecting the performance obligation.
Applying Oracle ’873's rollover recalculation to an adjustment affecting Oracle ’582's performance obligation would have been obvious.
With respect to Claim 13, for the reasons stated for claim 6, Oracle ’582 teaches modifying/revaluing the underlying performance obligation, while Shah teaches processing contractual/agreement information and related transactions.
Replacing a stored superseded contract record with its updated version is a predictable implementation of maintaining current contract information following a modification.
With respect to Claim 14 Oracle ’873 supplies the rollover processing alternative, while Duetto supplies the estimate/forecast processing alternative.
Representing those known alternative calculations as selectable variable-consideration types would have been obvious.
With respect to Claim 15 Oracle ’582 teaches structured electronic performance-obligation records populated from order information and containing identifiers, release criteria and valuations.
Providing those repeatable data structures as performance-obligation templates for associating transaction information would have been an obvious implementation.
Claim 16 recites the same substantive operations in non-transitory computer-storage-medium form.
Oracle ’582 expressly teaches a computer-readable medium having embodied thereon a computer program executable by a machine to perform a method for tracking performance obligations.
The program: generates a performance obligation for an order; records the valuation; records release criteria; reduces valuation based upon the criteria; and reflects the performance-obligation balance in a general ledger.
Oracle ’582 further claims computer-readable-medium embodiments that revalue performance obligations and modify release criteria.
Accordingly, Oracle ’582 expressly supplies the claimed storage-medium implementation.
The substantive operations are supplied by the same combination discussed for claims 2 and 9: Oracle ’582 — performance obligations, rules/criteria, transaction/order data and reporting; Shah — rules over a communications network and automated revenue recognition; Oracle ’873 — rollover rules, recalculation and rerating; and Duetto — historical transaction data, selectable forecasting techniques and future projections.
Therefore, it would have been obvious to embody the combined functionality as processor-executable instructions on Oracle ’582's expressly disclosed computer-readable medium. Oracle ’582 already teaches software instructions implementing performance-obligation accounting. Shah likewise implements revenue recognition through automated software processing. Oracle ’873 implements rollover and recalculation through a computerized revenue-management system, and Duetto implements historical-data forecasting through computerized modules.
A person of ordinary skill would have recognized that incorporating these known software functions into Oracle ’582's computer-readable-medium implementation merely stores the combined known instructions on the conventional medium already provided for executing the performance-obligation accounting process.
The combination would predictably provide a storage-medium implementation capable of rule-based revenue recognition, rollover/recalculation, and historical-data forecasting without changing the established functions of the respective components.
Accordingly, claim 16 would have been obvious over Oracle ’582 in view of Shah, Oracle ’873, and Duetto.
With respect to Claim 17 Duetto teaches comparing forecasts with actual historical transaction data, determining forecast errors, and selecting a corrected/more accurate forecasting configuration.
Oracle ’873 teaches identifying changed/delayed events, recalculating rollover, and rerating transactions.
It would have been obvious to implement these correction functions as executable instructions in Oracle ’582's computer-readable-medium embodiment.
With respect to Claim 18 Oracle ’873 teaches predefined rollover rules and rollover processing. Implementing that known processing category as a selectable rollover variable-consideration type would have been obvious.
With respect to Claim 19 Oracle ’873 teaches recalculating rollover when subsequent information changes the previously determined rollover and rerating transactions accordingly.
Oracle ’582 teaches revaluation of performance obligations following changed conditions.
The combined teachings render obvious computing rollover information following an adjustment affecting the performance contract.
With respect to Claim 20 Oracle ’582 teaches maintenance and revaluation of existing obligations in response to changed circumstances and modification of release criteria.
Shah teaches receiving and processing agreement-related transaction information, including agreement type, special terms, contingencies and related transactions. For the reasons discussed regarding claims 6 and 13, replacing the stored version of a superseded contractual record with an updated contractual record would have been an obvious data-management implementation of those teachings.
With respect to Claim 21 Oracle ’873 teaches the rollover-processing alternative.
Duetto teaches estimation/forecasting based upon historical transaction information. Providing the two known processing treatments as selectable “rollover” and “estimates” variable-consideration types would have been an obvious organization of the combined system's available financial treatments.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROKIB MASUD whose telephone number is (571)270-5390. The examiner can normally be reached Mon-Fri 8:00-5:00.
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, Fahd Obeid can be reached at 571-270-3324. 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.
/ROKIB MASUD/Primary Examiner, Art Unit 3627
