DETAILED ACTION
This is office action on the merits in response to the application filed on 07/02/2026.
Claims 1-22 have been filed by the applicant.
Claims 7 and 14 are previously canceled.
Claims 1, 5-6, 8, 12-13, 15 and 19-22 are currently amended.
Claims 1-6, 8-13 and 15-22 are currently pending and have been examined.
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 Argument
Drawing:
The applicant submitted revised drawings. The objection to drawings is withdrawn.
Double Patenting Rejection:
The examiner acknowledged the applicant’s request to hold double-patenting rejection in abeyance.
Rejection under 112:
Previous 112 rejections are withdrawn based on amendment.
Rejection under 101:
The applicant argues that the claims provide a specific, structured technological solution to controlling resource transfers across disparate resource systems. The examiner respectfully disagrees. The claims recite steps of receiving a request, generating and transmitting messages, and approving request which falls under abstract idea of commercial activities. The claims also recite steps of determining the proper personnel for approving the request which falls under the abstract idea of managing personal interactions between people. The combination of abstract ideas does not integrate the abstract idea into a practical application nor provide significantly more than the abstract idea. In addition, the claims do not recite resource transferred across disparate resource systems, the claim language only shows that the process is applied on different systems.
The applicant further argues that the claims recite a machine-implemented operational sequence for controlling resource transfer across disparate resource systems based on a multi-source system approval mapping and not merely to the idea of asking someone for permission. The examiner respectfully disagrees. The process simply works as looking up the mapping for user approval data and then sending requests to corresponding users for approval, which fits square to the abstract idea of managing personal interactions between people. The computers/system merely serving as a tool to perform the abstract idea.
The applicant further cited McRO v. Bandai and argues that the claims are directed to a specific, rule-driven computer architecture that employs a technical solution. The examiner respectfully disagrees. The court concludes that the claims are eligible if the focus is on a specific technological means rather than a generic result. The current claims does not recites a specific technological means, rather the claims recites personal interactions that are performed on generic computers.
The applicant further argues that the claims are not abstract idea because the claims recite transfer of a resource via a resource system cannot be performed by pure human interactions. The examiner respectfully disagrees. As stated above and in 101 rejections, the transferring step is abstract idea of commercial interactions. The resource system serves as a computer to perform the abstract idea.
The applicant further argues that the claims provide computer and technical improvement. The examiner respectfully disagrees. As stated above, the claims recite two abstract ideas implemented on generic computers, the claims do not recite improvement to the computers, instead the computers are used as generic computers. Therefore, the claims do not provide technical improvement.
The applicant further argues that the claims address the vulnerability of disparate resource systems. The examiner respectfully disagrees. Although the claims recite determining approval status of requestor and getting approval from administrator/approver, it is similar to getting approval from supervisor. The request then sent to resource systems for process the same way as any other requests. The claims do not recite any improvement to the resource systems or addressing any problems of resource systems. Instead, the resource systems are used as their expected function to process transactions.
The applicant further cited [0013] which states the system can delay transfer until receiving approval from administrator/approver which can reduce latency for the resource system. The examiner respectfully disagrees. Getting approval from administrator/approver is abstract idea of managing personal interactions. Also, as the result may reduce latency for transfer, it is expectancy of business method, there is no improvement to the resource systems.
Therefore, 101 rejection is maintained.
Rejection under 103:
The applicant argues that Fernandez and McLaughlin do not teach the features of “mapping users to approval status for at least two resource systems”. The examiner respectfully disagrees. The “resource systems” is used in the claims as data points for mapping the information. Fernandez discloses mappings to approval status. Fernandez does not disclose mapping to resource systems. McLaughlin discloses a process to identify payment type (i.e., different resource systems), and process transactions based on payment type data in the request. Therefore, McLaughlin stores mapping associated with resource systems and identifying and processing requests based on resource systems mapping. Therefore, Fernandez and McLaughlin teach the feature of “mapping users to approval status for at least two resource systems”.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 1-6, 8-12, 15-18 and 21-22 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 4-5, 7-9, 12-16 and 19-20 of copending Application No. 18633621 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other
Claim 1 is anticipated by claim 1 of Application No. 18634195.
Claim 2 is anticipated by claim 1 of Application No. 18634195.
Claim 3 is anticipated by claim 5 of Application No. 18634195.
Claim 4 is anticipated by claim 4 of Application No. 18634195.
Claim 5 is anticipated by claim 7 of Application No. 18634195.
Claim 6 is anticipated by claim 8 of Application No. 18634195.
Claim 8 is anticipated by claim 9 of Application No. 18634195.
Claim 9 is anticipated by claim 9 of Application No. 18634195.
Claim 10 is anticipated by claim 13 of Application No. 18634195.
Claim 11 is anticipated by claim 12 of Application No. 18634195.
Claim 12 is anticipated by claim 15 of Application No. 18634195.
Claim 15 is anticipated by claim 16 of Application No. 18634195.
Claim 16 is anticipated by claim 16 of Application No. 18634195.
Claim 17 is anticipated by claim 20 of Application No. 18634195.
Claim 18 is anticipated by claim 19 of Application No. 18634195.
Claim 21 is anticipated by claim 7 of Application No. 18634195.
Claim 22 is anticipated by claim 1 of Application No. 18634195.
This is a provisional nonstatutory double patenting rejection.
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-6, 8-13 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-6 are directed to a system comprising a memory and a processor, claims 8-13 are directed to a method, and claims 15-20 are directed to a non-transitory computer-readable storage medium. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 8 and 15, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising:
storing, by a resource management system communicatively coupled via a network to a resource request processing system, user data in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status for each user of the plurality of users for each resource system of at least two resource systems, wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers, and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein:
a first subset of the plurality of users with the approval status of approver administrator for one or more of the at least two resource systems are permitted to cause resource transfers to or from a first user account associated with the entity via the one or more of the at least two resource systems and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems
a second subset of the plurality of users with the approval status of approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems, and
a third subset of the plurality of users with the approval status of non- approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems;
receiving, by the resource management system and from a user device associated with a user of the plurality of users, a resource transfer request comprising a selected resource system of the at least two resource systems, a proposal toa request to transfer an amount of a resource from a first user account associated with the entity to a second user account, and an identity of the user of the plurality of users;
determining, by the resource management system querying the relational database and based on the user data, that an approval status of the user is non-approver non-administrator;
in response to determining that the approval status of the user is non- approver non-administrator,
generating, by the resource management system, an approval request notification comprising indications of the amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the selected resource system; and
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator for the selected resource system and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-administrator for the selected resource system, wherein the approval request notification further consists of an approve option, a deny option, and a modification option;
receiving, by the resource management system and from an additional user device of the first plurality of user devices or the second plurality of user devices, an approval indicator comprising a modification to the amount of the resource in response to a user selection of the modification option at the additional user device; and
upon receiving the approval indicator, automatically transmitting, by the resource management system, the approval request notification and the modification to the amount of the resource to the resource request processing system to cause the resource request processing system to perform the transfer of the modified amount of the resource from the first user account to the second user account via the selected resource system
receiving, from the user device of the plurality of user devices associated with the user of the plurality of users, a second resource transfer request comprising the second resource system of the at least two resource systems, a proposal to transfer a second amount of the resource from the first user account to the second user account, and the identity of the user of the plurality of users;
generating, based on the second resource transfer request, a second approval request notification comprising indications of the second amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the second resource system, wherein the second approval request notification further consists of a second approve option, a second deny option, and a second modification option;
transmitting the second approval request notification to the first plurality of user devices associated with the first subset of the plurality of users and transmitting the second approval request notification to the second plurality of user devices associated with the second subset of the plurality of users;
in response to transmitting the second approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, from an additional user device of the first plurality of user devices or the second plurality of user devices, a second approval indicator in response to a user selection of the second approval option at the additional user device of the first plurality of user devices or the second plurality of user devices; and
upon receiving the second approval indicator, transferring the second amount of the resource from the first user account to the second user account via the second resource system
Limitations B-F, K-L, M and O-Q under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer environment in limitation B-F and K-L, nothing in the claim element differentiates the limitation from processes of receiving request, receiving approval and perform transfer. Therefore, limitations B through H recite an abstract idea, as highlighted above, that is consistent with the commercial interactions aspects of Certain Methods of Organizing Human Activity.
Furthermore, limitation G-J and N recites “determining user approval status and send transfer request to higher-level users for approval” which is abstract idea of managing personal interactions between people within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements in limitation G-J merely serving as a tool to perform the abstract idea.
Accordingly, claim 1, and by analogy similar claims 8 and 15, recite an abstract idea and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising:
storing, by a resource management system communicatively coupled via a network to a resource request processing system, user data in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status for each user of the plurality of users for each resource system of at least two resource systems, wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers, and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein:
a first subset of the plurality of users with the approval status of approver administrator for one or more of the at least two resource systems are permitted to cause resource transfers to or from a first user account associated with the entity via the one or more of the at least two resource systems and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems
a second subset of the plurality of users with the approval status of approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems, and
a third subset of the plurality of users with the approval status of non- approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems;
receiving, by the resource management system and from a user device associated with a user of the plurality of users, a resource transfer request comprising a selected resource system of the at least two resource systems, a proposal toa request to transfer an amount of a resource from a first user account associated with the entity to a second user account, and an identity of the user of the plurality of users;
determining, by the resource management system querying the relational database and based on the user data, that an approval status of the user is non-approver non-administrator;
in response to determining that the approval status of the user is non- approver non-administrator,
generating, by the resource management system, an approval request notification comprising indications of the amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the selected resource system; and
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator for the selected resource system and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-administrator for the selected resource system, wherein the approval request notification further consists of an approve option, a deny option, and a modification option;
receiving, by the resource management system and from an additional user device of the first plurality of user devices or the second plurality of user devices, an approval indicator comprising a modification to the amount of the resource in response to a user selection of the modification option at the additional user device; and
upon receiving the approval indicator, automatically transmitting, by the resource management system, the approval request notification and the modification to the amount of the resource to the resource request processing system to cause the resource request processing system to perform the transfer of the modified amount of the resource from the first user account to the second user account via the selected resource system
receiving, from the user device of the plurality of user devices associated with the user of the plurality of users, a second resource transfer request comprising the second resource system of the at least two resource systems, a proposal to transfer a second amount of the resource from the first user account to the second user account, and the identity of the user of the plurality of users;
generating, based on the second resource transfer request, a second approval request notification comprising indications of the second amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the second resource system, wherein the second approval request notification further consists of a second approve option, a second deny option, and a second modification option;
transmitting the second approval request notification to the first plurality of user devices associated with the first subset of the plurality of users and transmitting the second approval request notification to the second plurality of user devices associated with the second subset of the plurality of users;
in response to transmitting the second approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, from an additional user device of the first plurality of user devices or the second plurality of user devices, a second approval indicator in response to a user selection of the second approval option at the additional user device of the first plurality of user devices or the second plurality of user devices; and
upon receiving the second approval indicator, transferring the second amount of the resource from the first user account to the second user account via the second resource system
The additional element(s) in limitation A-G and I-Q are recited at a high level of generality. The additional elements as recited merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). As such, when the additional elements are considered individually and as an ordered combination, the claim as a whole amounts to no more than or mere a computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than implementing an abstract idea on a generic computer. This is not enough to provide an inventive concept. Therefore, claims 1, 8, and 15 are not patent eligible.
Dependent claims 2, 9 and 16 further recite a plurality of user listing and corresponding approval status identifiers which is mere data. The additional element of generating graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 3, 10 and 17 further recite loading a first subset of user listing and a second subset of listing which further recites the abstract idea. The additional element of generating graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 4, 11 and 18 further recite detecting an update and updating the user data which further recites the abstract idea. The additional element of graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 5, 12 and 19 further recite receiving and approve request and transferring resource which further recites the abstract idea. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 6, 13 and 20 further recite receiving and approve request and transferring resource which further recites the abstract idea. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 21 further recite the similar process as in claim 1 and to perform the transfer which is still the abstract idea of commercial interactions. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 22 further recite the similar process as in claim 1 and to deny the transfer which is still the abstract idea of commercial interactions. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 4-6, 8-9, 11-13, 15-16 and 18-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fernandes (US 20150120546 A1), and further in view of McLaughlin et al. (US 20190019169 A1) and Zuber (US 20130254082 A1).
With respect to claim 1, 8 and 15:
Fernandes teaches:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising. (Accordingly, the invention can be implemented in numerous ways, including as an apparatus, a system, a device, a computer-implemented method, and/or a computer-readable medium such as a non-transitory computer-readable storage medium with computer-readable instructions or other program code, which when executed by one or more processors, cause a computer to perform a method in accordance with the one or more embodiments. Examples of a medium includes, but is not limited to, circuit-based media (e.g., read-only memory, flash memory. [0055])
storing, user data, the user data comprising a mapping that relates a plurality of users associated with an entity to an approval status […], and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein: a first subset of the plurality of users with the approval status of approver administrator […] are permitted to cause resource transfers to or from a first user account associated with the entity […] and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account […], a second subset of the plurality of users with the approval status of approver non-administrator […] are permitted to request resource transfers to or from the first user account […] for approval by other users in the first subset and the second subset and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account […], and a third subset of the plurality of users with the approval status of non-approver non-administrator […] are permitted to request resource transfers to or from the first user account […] for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account […]. (The enrollment unit 222 can process new enrollments of payment service participants such as purchasers and merchants. The enrollment unit 222 can further process all requests and responses related to management of accounts. The enrollment unit 222 can ensure that registration data is stored in a format that is in accordance with data formatting requirements such as storage in a lookup table as described below. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. The account hierarchy 300 can be stored as any directed graph-like data structure that maintains nodes and vertices, where nodes can have pointers to other nodes (vertices) indicating superordinacy or subordinarcy. Thus, for example, the database may store a separate hierarchy lookup table according to hierarchy 300 as follows. The hierarchy 300 can also include additional information regarding authorities. For example, node E has superordinate nodes A, B, C, and D but a transaction initiated with node E must be authorized by A, by B, or by C and D. As another example, the hierarchy 300 may be integrated with specific rules. Rules can be quota-based. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0025 0027 0029 0031] Fig. 3). It would have been obvious that without having the exact same groups as recited in the claims, Fernandes discloses the same structure of user groups with approval status by introducing account hierarchy with superordinacy and subordinarcy.
receiving, from a user device associated with a user of the plurality of users, a first resource transfer request comprising […], a proposal to transfer a first amount of a resource from a first user account associated with the entity to a second user account. and an identity of the user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the mapping, that an approval status of the user is non-approver non-administrator; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining that the approval status of the user is non- approver non-administrator; generating a first approval request notification comprising indications of the first amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, […]; and transmitting the first approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator […] and transmitting the first approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-[…], wherein the first approval request notification further consists of a first approve option, a first deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, from a user device of the first plurality of user devices or the second plurality of user devices, a first approval indicator […]; (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the first approval indicator, transferring the […] amount of the resource from the first user account to the second user account […]. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
Fernandes does not teach the following limitations. However,
McLaughlin teaches:
at least two resource systems, wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers. (A system for intelligent switching for multiple transaction types. the system 100 may include an authorization system 110a configured to process payment transactions funded via the payment instrument 108a in addition to an authorization system 110b configured to process payment transactions funded via the payment instrument 110b. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard® (i.e., a second resource system related to wire transfers), whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH) (i.e., a first resource system related to automated clearing house payments). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. [0006-0007 0024])
a first resource transfer request comprising the first resource system of the at least two resource systems; (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
generating, […] a first approval request notification comprising […] and the selected resource system; and transmitting, […], the first approval request notification to a first plurality of user devices associated with a first subset of the plurality of users […] for the first resource system and transmitting the first approval request notification to a second plurality of user devices associated with a second subset of the plurality of users […] for the first resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
transferring […] from the first user account to the second user account via the first resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification further consists of […] a first modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
approval indicator comprising a modification to the first amount of the resource in response to a user selection of the first modification option at the additional user device; transferring the modified amount of the resource […]. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections, he will click "Approve Draft Invoice,". After the final member of the reviewer sequence has reviewed the invoice and clicked on "Approve Draft Invoice," a final version of the invoice may be issued. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
The limitations below are performing the same process as above for “a second resource transfer”. Therefore, Fernandes in view of McLaughlin teaches the limitations below as they are the same process as the above limitations.
receiving, from the user device of the plurality of user devices associated with the user of the plurality of users, a second resource transfer request comprising the second resource system of the at least two resource systems, a proposal to transfer a second amount of the resource from the first user account to the second user account, and the identity of the user of the plurality of users;
generating, based on the second resource transfer request, a second approval request notification comprising indications of the second amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the second resource system, wherein the second approval request notification further consists of a second approve option, a second deny option, and a second modification option;
transmitting the second approval request notification to the first plurality of user devices associated with the first subset of the plurality of users and transmitting the second approval request notification to the second plurality of user devices associated with the second subset of the plurality of users;
in response to transmitting the second approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, from an additional user device of the first plurality of user devices or the second plurality of user devices, a second approval indicator in response to a user selection of the second approval option at the additional user device of the first plurality of user devices or the second plurality of user devices; and
upon receiving the second approval indicator, transferring the second amount of the resource from the first user account to the second user account via the second resource system.
Claim 8, a method with the same scope as claim 1, is rejected.
Claim 15, a CRM with the same scope as claim 1, is rejected.
With respect to claim 2, 9 and 16:
Fernandes further teaches generating a graphical user interface comprising a plurality of user listings and corresponding approval status identifiers, wherein each user listing of the plurality of user listings corresponds to a user of the plurality of users, and wherein the corresponding approval status identifiers indicate the approval status of each user of the plurality of users. (The account hierarchy 300 can be stored as any directed graph-like data structure that maintains nodes and vertices, where nodes can have pointers to other nodes (vertices) indicating superordinacy or subordinarcy. Thus, for example, the database may store a separate hierarchy lookup table according to hierarchy 300 as follows. FIG. 6 shows an exemplary account-creation interface 600 in which the administrator can create new accounts with previously-created rules. The account-creation interface 600 can present to the administrator a grouping of rules and all--preferably subordinate--accounts to which the grouping applies. [0029 0042])
Claim 9, a method with the same scope as claim 2, is rejected.
Claim 16, a CRM with the same scope as claim 2, is rejected.
With respect to claim 4, 11 and 18:
Fernandes further teaches wherein the operations further comprise: detecting an update to the approval status of the user based on a user selection of an approval status identifier for the user at the graphical user interface; and updating the user data based on the update to the approval status. (FIG. 6 shows an exemplary account-creation interface 600 in which the administrator can create new accounts with previously-created rules. The account-creation interface 600 can present to the administrator a grouping of rules and all--preferably subordinate--accounts to which the grouping applies. The administrator can then create a new rule, which the system receives along with other parameters at S810, stores at S812, and applies to a subaccount in accordance with received parameters at S814. The subaccount to which the new rule is applied can be a different subaccount from the subaccount with which the transaction was initiated. Fig. 5-6 [0042 0047])
Claim 11, a method with the same scope as claim 4, is rejected.
Claim 18, a CRM with the same scope as claim 4, is rejected.
With respect to claim 5, 12 and 19:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a third resource transfer comprising […] a proposal to transfer a third amount of the resource[…] and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the mapping, that an approval status of the additional user is approver non-administrator; (The method includes generating a transaction code for the transaction that is initiated with a payment service subaccount. The transaction code including transaction information. The method also includes determining whether to place a lock on the transaction. If, based on the determining step, the lock should be placed on the transaction, the method proceeds with placing the lock on the transaction, identifying an administrator of the payment service subaccount using an account hierarchy and a hierarchical position of the payment service subaccount in the account hierarchy, transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. If, based on the determining step, the lock should not be placed on the transaction, the method proceeds with allowing the transaction to proceed. The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0005 0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver non-administrator, transmitting another approval request notification to the first plurality of user devices; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0024 0027 0031]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, from a user device of the first plurality of user devices, a third approval indicator; (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the third approval indicator, transferring the third amount the resource from […]. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
a second resource transfer request comprising the first resource system of the at least two resource systems, a proposal to transfer the third amount of the resource from the first user account associated with the entity to the second user account[…]. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
transferring the amount the resource from the first user account to the second user account via the first resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Claim 12, a method with the same scope as claim 5, is rejected.
Claim 19, a CRM with the same scope as claim 5, is rejected.
With respect to claim 6, 13 and 20:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a third resource transfer request comprising […], a proposal to transfer a third amount of the resource from […], and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the mapping, that an approval status of the additional user is approver administrator; and (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver administrator, transferring the third amount the resource […]. (The user presented with this interface can be an account holder of a superordinate account creating a rule for a subordinate account or an administrator at a financial institution creating a rule for account holders associated with the financial institution that are subordinate to the financial institution in the payment system hierarchy. [0038]). It would have been obvious that an account holder of a superordinate account (i.e., approver administrator) do not requires approval in order to transfer resource.
McLaughlin further teaches:
resource transfer request comprising the first resource system of the at least two resource systems, […] from the first user account to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
transferring the third amount the resource from the first user account to the second user account via the first resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Claim 13, a method with the same scope as claim 6, is rejected.
Claim 20, a CRM with the same scope as claim 6, is rejected.
With respect to claim 21:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a third resource transfer request comprising […], a proposal to transfer an amount of funds from the […], and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the mapping, that an approval status of the additional user is approver non-administrator; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver non- administrator, transmitting a third approval request notification as a push notification to the first plurality of user devices, the third approval request notification comprising indications of the amount of the funds, […], the identity of the additional user, […], and the second approval request notification consisting of a third approve option, a third deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction, and/or create a rule for all future transactions. The option to create a rule is transmitted with a rule flag in the authorization response so that the system can create a new rule to be applied to the subaccount for future transactions. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, from a user device of the first plurality of user devices, a third approval indicator in response to a user selection of the third approve option at the user device of the first plurality of user devices. (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the third approval indicator, transferring the third amount of the funds […]. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
transfer request comprising a selection of the second resource system of the at least two resource systems, […] first user account associated with the entity to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
request notification comprising indications of […] the first user account, the second user account, […], and the second resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
transferring the third amount of the funds from the first user account to the second user account via the second resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification consisting of […] a modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
With respect to claim 22:
Fernandes further teaches:
receiving, from the user device associated with the user of the plurality of users, a third resource transfer request comprising […], a proposal to transfer an amount of funds […], and the identity of the user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
generating a third approval request notification comprising indications of the amount of the funds, […], the identity of the user of the plurality of users, and the first resource system; and transmitting the third approval request notification as a push notification to the first plurality of user devices associated with the first subset of the plurality of users with the approval status of approver administrator […] and transmitting the third approval request notification as a push notification to the second plurality of user devices associated with the second subset of the plurality of users with the approval status of approver non-administrator […], wherein the third approval request notification further consists of a third approve option, a third deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction, and/or create a rule for all future transactions. The option to create a rule is transmitted with a rule flag in the authorization response so that the system can create a new rule to be applied to the subaccount for future transactions. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving from a user device of the first plurality of user devices, a denial indicator in response to a user selection of the third deny option at the user device of the first plurality of user devices. (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the denial indicator, automatically preventing the transfer of the amount of the funds from the first user account to the second user account. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
transfer request comprising a selection of the second resource system of the at least two resource systems, […] first user account associated with the entity to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
approval request notification comprising indications of […], the first user account, the second user account. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
transmitting, […] approval request notification […] to the […] first subset of the plurality of users […] for the selected resource system and transmitting , […] approval request notification […] to the […] second subset of the plurality of users […] for the selected resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
automatically preventing the transfer […]. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification consisting of […] a third modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Fernandes" and “McLaughlin” and “Zuber” as applied to claim 2, 9 and 16 above, and further in view of Harney et al. (US 20160071424 A1).
With respect to claim 3, 10 and 17:
Fernandes in view of McLaughlin and Zuber does not teach generating the graphical user interface comprises loading a first subset of the plurality of user listings and corresponding approval status identifiers at a first time and loading a second subset of the plurality of user listings and corresponding approval status identifiers at a second time. However,
Harney teaches generating the graphical user interface comprises loading a first subset of the plurality of user listings and corresponding approval status identifiers at a first time and loading a second subset of the plurality of user listings and corresponding approval status identifiers at a second time. (After a selection is made, the interface may update to show the users matching the selected filters. Results may be paginated (e.g., by showing 10, 25, 50, 100, etc. results per page). [0087])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin and Zuber to paginate user listing with the technique as disclosed by Harney to provide better user interface.
Claim 10, a method with the same scope as claim 3, is rejected.
Claim 17, a CRM with the same scope as claim 3, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170011450 A1: Similarly for an organization, organizations will have policies governing their purchasing process. For example, approval for making a purchase will involve approval from a tech lead, a tech manager, and a director. In one exemplary scenario, the current system will provide preapproval to be at any level of the organization, and/or add additional users per approval from existing members.
US 12147985 B1: This may include, for example, querying a supervisory user associated with the same organization as the requesting user, via a user computing device, and requesting that the supervisory user approve the requested fund transfer. Obtaining higher approval, in some examples, may include querying a user within the financial institution handling the fund transfer to request approval of the requested fund transfer. In some examples, the supervisory user or other queried user may decline to provide higher level approval, in which the requested fund transfer may be declined. If the risk score is not greater than the threshold at operation 804 and/or after higher-level approval is obtained at operation 806, the transfer application 114 may execute the requested fund transfer at operation 808.
US 20160342992 A1: The administrator may be able to set and update or change varying levels of access privilege (or “permissioning” features) allowing the authorized user to have full to no discretion over spending on the account, e.g., to control where, when, what, how much the authorized user may spend funds available in the account, or make a deposit into the account.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights