DETAILED ACTION
This office action is in response to communication filed on 30 January 2026.
Claims 1 – 20 are presented for examination.
The following is a FINAL office action upon examination of application number 18/939186. Claims 1 – 20 are pending in the application and have been examined on the merits discussed below.
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 .
Response to Amendment
In the response filed 30 January 2026, Applicant amended no claims.
Response to Arguments
Applicant's arguments filed 30 January 2026 have been fully considered but they are not persuasive.
In the remarks regarding the subject matter eligibility rejection under 35 USC 101, Applicant argues that claims are not directed to abstract ideas without significantly more. Examiner respectfully disagrees. Importing financial data and accessing and importing banking data comprising providing account credentials to obtain access are both mental processes and certain methods of organizing human activity. “Importing” without sufficient technology required is akin to receiving data from another source, which is a mental process. Commercial or legal interactions (sub groupings under certain methods of organizing human activity) include providing account credentials to obtain access. Providing account credentials in the context of the current claims is only configured to access and import through a document, as one of the selectable options. One could be at a physical bank branch location and provide account credentials as personal identification and bank account in physical form, which can be verified with banking documents in a simple computer that has a relational database to match credentials with their user and financial data. All of this could be performed on old and well-known technology, not significantly more, as is claimed herein. As for the rest of the steps called out in Applicant’s arguments, gathering data, providing services, determining, maintaining data, analyzing data, storing data, and providing data responsive to request are all mental processes as they describe observation, judgment, evaluation, and opinion as defined as concepts performed in the human mind in the MPEP. Examiner has analyzed claims as a whole, and they do not rise to the level of significantly more, so the 35 USC 101 rejection is maintained. Examiner strongly suggests that Applicant re-review the Allowable Subject Matter section from the previous and current rejection to best amend claims to allow, in Examiner’s position.
In the remarks regarding independent claims 1, 19, and 20, Applicant argues that the cited prior art does not teach the independent claims. Examiner respectfully disagrees. The limitation that Applicant points out is an accounting platform configured to access banking data over a network through a bank feed or document, or over a network via an application protocol interface, and wherein the accessing the banking data comprises providing account credentials of the plurality of users to obtain access to the banking data for the plurality of users. Lochrie teaches in paragraph 40 that transactions can be imported from an integration such as a banking app or imported from a statement upload (i.e. a banking document). Banking statements have credentials, but Lochrie also discloses in paragraph 33 that users can scan receipts to be OCR scanned and access credit card account information.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 12, 14, 15, and 19 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to the judicial exception of abstract ideas without significantly more. The claims recite importing financial data for each user with a user account into user data, configured to access and import banking data comprising providing account credentials to obtain access, configured to gather accounting data and provide accounting services, determining and maintaining user data comprising entity identifier indicating entity that user data is associated and an attribute, analyzing accounting and financial data imported to determine the attribute, storing user data in a database, and providing a subset of user data responsive to request for user data. This judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The eligibility analysis in support of these findings is provided below, in accordance section 2106 of the MPEP (hereinafter, MPEP 2106).
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is noted that the method, the accounting platform (system), and the non-transitory machine readable storage medium are directed to eligible categories of subject matter. Step 1 is satisfied.
With respect to Step 2A prong 1 of MPEP 2106, it is next noted that the claims recite an abstract idea by reciting concepts of accessing banking data and providing credentials, which falls into the “certain methods of organizing human activity” group within the enumerated groupings of abstract ideas set forth in the MPEP 2106. The claimed invention also recites an abstract idea that falls within the mental processes grouping. The limitations reciting the abstract idea in independent claims are importing financial data for each user with a user account into user data, configured to access and import banking data comprising providing account credentials to obtain access, configured to gather accounting data and provide accounting services, determining and maintaining user data comprising entity identifier indicating entity that user data is associated and an attribute, analyzing accounting and financial data imported to determine the attribute, storing user data in a database, and providing a subset of user data responsive to request for user data.
With respect to Step 2A Prong Two of the MPEP 2106, the judicial exception is not integrated into a practical application. The additional elements are directed to a cloud computing environment, bank feed or document (examiner’s choice is document), network, application protocol interface, database, application, computer processors, memory, non-transitory machine-readable storage medium, and computer, to implement the abstract idea. However, these elements fail to integrate the abstract idea into a practical application they are directed to the use of generic computing elements to perform the abstract idea, which is not sufficient to amount to a practical application (as noted in the MPEP 2106) and is tantamount to simply saying “apply it” using a general purpose computer, which merely serves to tie the abstract idea to a particular technological environment by using the computer as a tool to perform the abstract idea, which is not sufficient to amount to particular application.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional limitations are directed to: a cloud computing environment, bank feed or document (examiner’s choice is document), network, application protocol interface, database, application, computer processors, memory, non-transitory machine-readable storage medium, and computer. These elements have been considered, but merely serve to tie the invention to a particular operating environment, though at a very high level of generality and without imposing meaningful limitation on the scope of the claim. This does not amount to significantly more than the abstract idea, and it is not enough to transform an abstract idea into eligible subject matter. Such generic, high-level, and nominal involvement of a computer or computer-based elements for carrying out the invention merely serves to tie the abstract idea to a particular technological environment, which is not enough to render the claims patent-eligible, as noted at pg. 74624 of Federal Register/Vol. 79, No. 241, citing Alice, which in turn cites Mayo.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Their collective functions merely provide conventional computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
The dependent claims have been fully considered as well, however, similar to the finding for claims above, these claims are similarly directed to the abstract idea of concepts of defining attribute types, defining user data, comparing attributes to a target range, receiving requests for benchmark, etc., without integrating it into a practical application and with, at most, a general purpose computer that serves to tie the idea to a particular technological environment, which does not add significantly more to the claims. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 3, 5 – 6, 8 – 10, 12, 14, 15, and 19 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. P.G. Pub. 2016/0042469 (hereinafter, Lochrie) in view of U.S. P.G. Pub. 2008/0126155 (hereinafter, Xu).
Regarding claim 1, Lochrie teaches a method comprising:
importing into user data, by an accounting platform in a cloud computing environment, financial data for each of a plurality of users having a user account with the accounting platform (¶ 36, “The system may determine and identify related bank data or accounting data from that which is accessed by the system and import said bank data and/or accounting data into the system”),
wherein the accounting platform is configured to access and import banking data over a network through a bank feed or document, or over a network via an application protocol interface (¶ 33, “The user may scan the receipt, or take a photo of the receipt, that is provided to the user. The receipt is then provided to the system so that an OCR is able to scan the receipt and collects information regarding the financial transaction that was the purchase of the computer by the user. This information is utilized to produce a record of the transaction. The system may further access other sources having records of the transaction, such as the credit card company source and the seller company source.”) (¶ 40, “Transactions may result from multiple sources, such as the following three sources, for example: transactions that are manually entered into the system by the user; transactions that are imported from an integration (e.g., CashEdge™, Paypal™, etc.); and transactions that are imported from a statement upload.”) (Examiner note: statement upload is a document), and
wherein the accessing the banking data comprises providing account credentials of the plurality of users to obtain access to the banking data for the plurality of users, wherein the accounting platform is configured to gather accounting data and provide accounting services to the plurality of users (¶ 33, “This information is utilized to produce a record of the transaction. The system may further access other sources having records of the transaction, such as the credit card company source and the seller company source. These third party transaction records may be accessed by the system, and the information therein may be utilized by the system.”).
Lochrie does not explicitly teach user data having an entity identifier. However, in the analogous art of business transaction benchmarking, Xu teaches determining and maintaining, by the accounting platform, user data for the plurality of users, wherein the user data comprises an entity identifier indicative of an entity with which the user data is associated, and at least a first attribute (¶ 28, “FIG. 2 a flow diagram illustrating one embodiment of a process for accessing enterprise operation health. The process 200 may be performed by a processing logic in a system as shown in FIG. 1. In one embodiment, the processing logic receives a query for the EHA report of an organization at block 201. The organization may be an enterprise entity. The query may include a scope. In one embodiment, the scope specifies a business unit of the organization. In one embodiment, the scope defines a type of the report, such as a report for a bank, a report for a business partner, a report for a customer, a report for a supplier or a report for an authority. The EHA report may be a credit report or other business reports. In one embodiment, a credit report includes histories of borrowing and repaying by an organization. In another embodiment, a credit report includes business transactions with customers, suppliers, banks, or business partners associated with an organization. A credit report may include business attributes, such as asset, debt, earnings, etc. associated with an organization.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business entity attributes of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and as having a user be an entity is merely a label, it would easily apply Xu to Lochrie without changing the functionality of either.
Lochrie teaches:
wherein determining, by the accounting platform, user data for each of the plurality of users comprises analyzing accounting data gathered by the accounting platform and financial data imported by the accounting platform to determine the at least first attribute (¶¶ 36-37, “The system may access bank data and other accounting related data either from a database incorporated in the system, or systems or databases external to the system. For example, the accessed bank data and accounting related data may include invoices, payments, bills or other data or documents. The system may determine and identify related bank data or accounting data from that which is accessed by the system and import said bank data and/or accounting data into the system, as required. The transaction processing application may match the transaction record against the accessed data, including any imported data. The matching may be achieved by a learning process, which implements a learning algorithm or calculation. The result of the learning algorithm or calculation may be a single view of the transaction. The learning algorithm or calculation may involve the identification of elements in the transaction records, for example, such as an amount, the date of the transaction, a description of the transaction, or any other elements. The learning algorithm or calculation may further involve a review of information relating to previous behaviours of a user engaged in the transaction, for example, such as a review of transactions that the user was engaged in that have previously been manually matched, or other indicators of previous user behaviours. The learning algorithm or calculation may also involve a review of the behaviour of other users, for example, such as a review of transactions that other users have manually matched, or other indicators of behaviours of other users.”);
storing the user data in a database (¶ 13, “store information derived from the loaded record and the additional records, as well as copies of the loaded record and the additional records in the one or more databases”) (¶ 40, “transactions that are imported from a statement upload. All transactions are stored in one or more databases of the system, such as in a relational database structure, for example.”); and
responsive to a request for user data from a user of the plurality of users, and/or from an application, providing at least a subset of the user data to user or application (¶ 36, “The system may access bank data and other accounting related data either from a database incorporated in the system, or systems or databases external to the system. For example, the accessed bank data and accounting related data may include invoices, payments, bills or other data or documents. The system may determine and identify related bank data or accounting data from that which is accessed by the system and import said bank data and/or accounting data into the system, as required. The transaction processing application may match the transaction record against the accessed data, including any imported data. The matching may be achieved by a learning process, which implements a learning algorithm or calculation. The result of the learning algorithm or calculation may be a single view of the transaction.”).
Regarding claim 2, Lochrie and Xu teach the method of claim 1. Lochrie teaches further comprising: causing, by the accounting platform, a display in a client device of the at least the subset of user data (¶ 13, “a user interface operable by one or more processors of the server computer to interactively display the information derived from the loaded record and the additional records to the user”).
Regarding claim 3, Lochrie and Xu teach the method of claim 1. Lochrie teaches wherein the at least first attribute of the user data comprises one or more of: a present amount of liquid capital, amount of debt, outstanding liabilities, unpaid invoices, average transaction size, a number of transactions in a predetermined time period, an average transaction size, a number of full-time employees, a location, a turnover rate, a debt-to-equity ratio, a floor space, a land area, a profit as a percentage of stock, a profit as a percentage of land area, or a profit as a percentage of retail space (¶ 36, “accounting related data may include invoices”).
Regarding claim 5, Lochrie and Xu teach the method of claim 1. Xu teaches wherein the entity is a business, a school, a church, a city, a state, a club, or a sports team (¶ 28, “FIG. 2 a flow diagram illustrating one embodiment of a process for accessing enterprise operation health. The process 200 may be performed by a processing logic in a system as shown in FIG. 1. In one embodiment, the processing logic receives a query for the EHA report of an organization at block 201. The organization may be an enterprise entity. The query may include a scope. In one embodiment, the scope specifies a business unit of the organization. In one embodiment, the scope defines a type of the report, such as a report for a bank, a report for a business partner, a report for a customer, a report for a supplier or a report for an authority. The EHA report may be a credit report or other business reports. In one embodiment, a credit report includes histories of borrowing and repaying by an organization. In another embodiment, a credit report includes business transactions with customers, suppliers, banks, or business partners associated with an organization. A credit report may include business attributes, such as asset, debt, earnings, etc. associated with an organization.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business entity attributes of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and as having a user be an entity is merely a label, it would easily apply Xu to Lochrie without changing the functionality of either.
Regarding claim 6, Lochrie and Xu teach the method of claim 1. Lochrie teaches wherein the user data comprises transaction level data including one or more of: invoices sent, payments received, and payments made (¶ 36, “the accessed bank data and accounting related data may include invoices, payments, bills or other data or documents.”).
Regarding claim 8, Lochrie and Xu teach the method of claim 1. Xu teaches further comprising: comparing, by the accounting platform, the at least first attribute to a threshold to determine if the at least first attribute is above or below the threshold (¶ 45, “organizations identify and develop proactive alerts via email or SMS when a particular key performance indicator falls outside the predetermined thresholds.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business entity attributes of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and as having a user be an entity is merely a label, it would easily apply Xu to Lochrie without changing the functionality of either.
Regarding claim 9, Lochrie and Xu teach the method of claim 1. Xu teaches further comprising: comparing, by the accounting platform, the at least first attribute to a target range to determine if the at least first attribute is within, below or above the target range (¶ 48, “An additional credit related data may be a status according to a comparison between business attributes and associated benchmark information. A status may have a binary value to indicate whether the result of a benchmark comparison is satisfactory or not. The benchmark comparison may be based on a reference according to the benchmark. In one embodiment, the reference may have a value corresponding to the benchmark value adjusted by a tolerance range.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business entity attributes of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and as having a user be an entity is merely a label, it would easily apply Xu to Lochrie without changing the functionality of either.
Regarding claim 10, Lochrie and Xu teach the method of claim 1. Xu teaches further comprising: determining, by the accounting platform, a benchmark based on user data for at least some of the plurality of users; and determining, by the accounting platform, a performance metric of a first user of the plurality of users based on a comparison of the at least first attribute of the first user with the benchmark (¶ 46, “Benchmark data may be related to expected values of business attributes automatically derived by an EIS application according to histories of business performance. In one embodiment, benchmark data is based on well-known public consensus.”) (¶ 25, “enterprise applications have already predefined many KPIs and according to the business requirements for each industry. These KPIs may be calculated by the BI (business intelligence) unit, which may be a part of an information warehouse to analysis business data.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business benchmarking of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and Xu merely adds the comparison functionality that would seamlessly integrate into Lochrie.
Regarding claim 12, Lochrie and Xu teach the method of claim 1. Xu teaches wherein the accounting platform is provided by a primary data center comprising a plurality of pods, each pod comprising one or more application server virtual machines that are specific to the pod, and the plurality of pods collectively providing an internal services virtual machine that is shared between the plurality of pods (¶¶ 72-73, “Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a "machine" may be a machine that converts intermediate form (or "abstract") instructions into processor specific instructions (e.g., an abstract execution environment such as a "virtual machine" (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.)), and/or, electronic circuitry disposed on a semiconductor chip (e.g., "logic circuitry" implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code. It is believed that processes taught by the discussion above may also be described in source level program code in various object-orientated or non-object-orientated computer programming languages (e.g., Java, C#, VB, Python, C, C++, J#, APL, Cobol, ABAP, Fortran, Pascal, Perl, etc.) supported by various software development frameworks (e.g., SAP Netweaver, SAP ABAP Workbench, Microsoft Corporation's NET, Mono, Java, Oracle Corporation's Fusion, etc.). The source level program code may be converted into an intermediate form of program code (such as Java byte code, Microsoft Intermediate Language, etc.) that is understandable to an abstract execution environment (e.g., a Java Virtual Machine, a Common Language Runtime, a high-level language virtual machine, an interpreter, etc.), or a more specific form of program code that is targeted for a specific processor.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business benchmarking utilizing virtual machines of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and Xu merely adds the type of processing computer that would seamlessly integrate into Lochrie.
Regarding claim 14, Lochrie and Xu teach the method as recited in claim 12. Xu teaches wherein each pod comprises one or more primary database query servers for accessing a primary data center storage layer shared by the plurality of pods to read and write data generated by or used by the application server virtual machines of the respective pod (¶ 71-72, “ The mass storage 711 is typically a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD RAM or other types of memory systems which maintain data (e.g. large amounts of data) even after power is removed from the system. Typically, the mass storage 711 will also be a random access memory although this is not required. While FIG. 7 shows that the mass storage 711 is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the present invention may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface. The bus 703 may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art. Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a "machine" may be a machine that converts intermediate form (or "abstract") instructions into processor specific instructions (e.g., an abstract execution environment such as a "virtual machine" (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.)), and/or, electronic circuitry disposed on a semiconductor chip (e.g., "logic circuitry" implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business benchmarking utilizing virtual machines of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and Xu merely adds the type of processing computer that would seamlessly integrate into Lochrie.
Regarding claim 15, Lochrie and Xu teach the method as recited in claim 14. Xu teaches wherein each pod comprises a redundant database query server in respect of each primary database query server, the redundant database query server providing backup functionality to the respective primary database query server (¶ 26, “Report generator 111 may be a module coupled with EOH engine 105 within a single application server or among multiple application servers (e.g., a server farm or a cluster of servers) associated with the enterprise entity. In one embodiment, report generator 111 performs data operations based on the collected business information to generate a credit report 119 according to the information requested by the query 101. The credit report 119 may include credit related information extracted or derived from the collected business information according the query 101. In one embodiment, report generator 111 forwards business transaction information to an advisory unit 115. The credit report 119 may be presented to a user through a user interface.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with business benchmarking utilizing virtual machines of Xu. This combination would have yielded a predictable result because both have user data associated with banking transactions, and Xu merely adds the type of processing computer that would seamlessly integrate into Lochrie.
Regarding claims 19 and 20, the claims recite substantially similar limitations to claim 1. Therefore, claims 19 and 20 are similarly rejected for the reasons set forth above with respect to claim 1.
Claims 4 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Lochrie in view of Xu in view of U.S. P.G. Pub. 2003/0182181 (hereinafter, Kirkwood).
Regarding claim 4, Lochrie and Xu teach the method of claim 1. Neither teaches wherein the at least first attribute of the user data is a geographical attribute associated with the entity identifier, the geographical attribute including one or more of: a city; a region; a country; and a size of a city, a region or a country. However, in the analogous art of business benchmarking, this is taught by Kirkwood (¶ 52, “The KPIs are compared to comparative key performance indicators selected by the user, e.g., average scores in a specific geographical area (e.g. global, national or regional average), scores of a pre-defined group, a former forecast of the user itself for the period in question, or comparative key performance indicators based on a customized query.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with the attribute of locations in benchmarking of Kirkwood. This combination would have yielded a predictable result because both have user data associated with financial data, and as attribute being geographical in nature is merely a label, it would easily apply Kirkwood to Lochrie without changing the functionality of either.
Regarding claim 7, Lochrie and Xu teach the method of claim 1. Neither teaches wherein the user data comprises employee data including one or more of: a number of employees, pay rates for each employee, vacation accrued by each employee, and title of each employee. However, in the analogous art of business benchmarking, this is taught by Kirkwood (¶ 25, “Performance data can for example be financial parameters (e.g. costs per job, etc.), operational parameters (e.g. number of employees”).It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine user transaction data of Lochrie with the attribute of employee data in benchmarking of Kirkwood. This combination would have yielded a predictable result because both have user data associated with financial data, and as attribute containing employee data is merely a label, it would easily apply Kirkwood to Lochrie without changing the functionality of either.
Allowable Subject Matter
Claims 13 and 16 – 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA GURSKI whose telephone number is (571)270-5961. The examiner can normally be reached Monday to Thursday 7am to 5pm EST.
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, Brian Epstein can be reached at 571-270-5389. 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.
/AMANDA GURSKI/Primary Examiner, Art Unit 3625