DETAILED ACTION
This is office action on the merits in response to the application filed on 07/08/2026.
Claims 1-20 have been filed by the applicant.
Claims 1-2, 5-10, 13-17 and 20 are currently amended.
Claims 1-20 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-2, 4-10, 12-17 and 19-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 3-6, 8 and 10-12 of copending Application No. 18633621 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because [ 4 ].
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1 and 6 is anticipated by claim 2 of Application No. 18633621.
Claim 2 is further disclosed by claim 2 of Application No. 18633621.
Claim 4 is further disclosed by claim 4 of Application No. 18633621.
Claim 5 is further disclosed by claim 3 of Application No. 18633621.
Claim 7 is further disclosed by claim 5 of Application No. 18633621.
Claim 8 is further disclosed by claim 6 of Application No. 18633621.
Claims 9 and 14 is anticipated by claim 9 of Application No. 18633621.
Claim 10 is further disclosed by claim 9 of Application No. 18633621.
Claim 12 is further disclosed by claim 11 of Application No. 18633621.
Claim 13 is further disclosed by claim 10 of Application No. 18633621.
Claim 15 is further disclosed by claim 12 of Application No. 18633621.
Claim 16 is anticipated by claim 16 of Application No. 18633621.
Claim 17 is further disclosed by claim 16 of Application No. 18633621.
Claim 19 is further disclosed by claim 18 of Application No. 18633621.
Claim 20 is further disclosed by claim 17 of Application No. 18633621.
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-8 and 16-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 16 recite "a processing device" for performing the recited steps. However, claims 1 and 16 further recite "displaying via a graphical user interface of a plurality of user device". It is not clear whether or not a plurality of user device is part of the processing device. For the purpose of examination, the examiner interprets that a plurality of user device is not part of the processing device. In this case, the limitation is outside of the scope and does not distinguish the claims from prior art. All dependent claims are rejected.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-8 are directed to a system comprising a memory and a processor, claims 9-15 are directed to a method, and claims 16-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 9 and 16, 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:
receiving user data, the user data comprising a mapping that relates each of a plurality of users associated with an entity to an approval status for each resource system of at least two resource systems, the at least two resource systems comprising a first resource system related to automated clearing house payments and a second resource system related to wire transfers, 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 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 at least two resource systems,
a second subset of the plurality of users with the approval status of approver non-administrator for the at least two resource systems are permitted to request resource transfers to or from the first user account via 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,
a third subset of the plurality of users with the approval status of non- approver non-administrator for 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 at least two resource systems;
displaying, via a graphical user interface on a plurality of user devices, a user listing that is based on the user data, wherein the user listing comprises each user of the plurality of users, and associates each user of the plurality of users with a corresponding approval status identifier indicative of the approval status of each user of the plurality of users for each of the at least two resource systems;
receiving, from a user device of the plurality of user devices associated with a user of the plurality of users, a first resource transfer request comprising the first resource system of the at least two resource systems, a proposal to transfer a first amount of a resource from the first user account to a second user account, and an identity of the user of the plurality of users;
in response to receiving the first resource transfer request, withholding the transfer of the first amount of the resource until an approval of the first resource transfer request is received and determining, based on the mapping, that an approval status of the user is non-approver non-administrator for the at least two resource systems;
in response to determining that the approval status of the user is non-approver non-administrator for the at least two resource systems,
generating, based on the first resource transfer request, 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 the selected resource system
transmitting the first approval request notification to a first plurality of user devices associated with the first subset of the plurality of users and transmitting the first approval request notification to a second plurality of user devices associated with the second subset of the plurality of users;
in response to transmitting the first approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, from a user device of the first plurality of user devices or the second plurality of user devices, the approval of the first resource transfer request;
upon receiving the approval of the first resource transfer request, transferring the first amount of the resource from the first user account to the second user account via the first 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;
withholding the transfer of the second amount of the resource until an additional approval of the second resource transfer request is received;
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;
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 another user device of the first plurality of user devices or the second plurality of user devices, the additional approval of the second resource transfer request; and
upon receiving the additional approval of the second resource transfer request, transferring the second amount of the resource from the first user account to the second user account via the second resource system
Limitations B-G, L-P, and S under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer environment in limitation B-G, L-P, and S, nothing in the claim element differentiates the limitation from processes of commercial interactions. 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 H-K and Q-R recites “determining user approval rights 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.
Accordingly, claim 1, and by analogy similar claims 9 and 16, recite at least two abstract ideas 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:
receiving user data, the user data comprising a mapping that relates each of a plurality of users associated with an entity to an approval status for each resource system of at least two resource systems, the at least two resource systems comprising a first resource system related to automated clearing house payments and a second resource system related to wire transfers, 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 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 at least two resource systems,
a second subset of the plurality of users with the approval status of approver non-administrator for the at least two resource systems are permitted to request resource transfers to or from the first user account via 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,
a third subset of the plurality of users with the approval status of non- approver non-administrator for 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 at least two resource systems;
displaying, via a graphical user interface on a plurality of user devices, a user listing that is based on the user data, wherein the user listing comprises each user of the plurality of users, and associates each user of the plurality of users with a corresponding approval status identifier indicative of the approval status of each user of the plurality of users for each of the at least two resource systems;
receiving, from a user device of the plurality of user devices associated with a user of the plurality of users, a first resource transfer request comprising the first resource system of the at least two resource systems, a proposal to transfer a first amount of a resource from the first user account to a second user account, and an identity of the user of the plurality of users;
in response to receiving the first resource transfer request, withholding the transfer of the first amount of the resource until an approval of the first resource transfer request is received and determining, based on the mapping, that an approval status of the user is non-approver non-administrator for the at least two resource systems;
in response to determining that the approval status of the user is non-approver non-administrator for the at least two resource systems,
generating, based on the first resource transfer request, 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 the selected resource system
transmitting the first approval request notification to a first plurality of user devices associated with the first subset of the plurality of users and transmitting the first approval request notification to a second plurality of user devices associated with the second subset of the plurality of users;
in response to transmitting the first approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, from a user device of the first plurality of user devices or the second plurality of user devices, the approval of the first resource transfer request;
upon receiving the approval of the first resource transfer request, transferring the first amount of the resource from the first user account to the second user account via the first 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;
withholding the transfer of the second amount of the resource until an additional approval of the second resource transfer request is received;
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;
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 another user device of the first plurality of user devices or the second plurality of user devices, the additional approval of the second resource transfer request; and
upon receiving the additional approval of the second resource transfer request, 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-M are recited at a high level of generality. The additional elements of limitations A-N and P-S merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional element in limitation B generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). 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 generally link the use of the judicial exception to a particular technological environment, 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. 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 generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept. Therefore, claims 1, 9, and 16 are not patent eligible.
Dependent claims 2, 10 and 17 further recite a resource system and resource system options which merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional element of GUI 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, 11 and 18 further recite approval status identifier is positionable in GUI which 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, 12 and 19 further recite detecting an update and updating the user data which further recites following instructions. 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, 13 and 20 further recite loading a first subset of user listing and a second subset of listing which further recites following instructions. 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 6 and 14 further recite receiving and approve request and transferring resource which further recites following instructions. 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 7 and 15 further recite receiving and approve request and transferring resource which further recites following instructions. 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 8 further recite receiving request and transferring resource which further recites following instructions. 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.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
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-4, 6-12, 14-19 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).
With respect to claim 1, 9 and 16:
Fernandes teaches (in italic):
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])
receiving user data, the user data comprising a mapping that relates each of a plurality of users associated with an entity to an approval status […], 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 and […], 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 and […]. (The accounts logic layer 218 can also include an enrollment unit 222. 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. The table can be used to query a relational database--for example, in a JOIN clause that joins an ACCOUNTS table with the foregoing HIERARCHY table--by the administrator identifying unit. 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. [0025 0027 0029-0031 0038 Fig. 3]
displaying, via a graphical user interface on a plurality of user devices, a user listing that is based on the user data, wherein the user listing comprises each user of the plurality of users, and associates each user of the plurality of users with a corresponding approval status identifier indicative of 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] Fig. 3, 5-6)
receiving, from a user device of the plurality of user devices 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 […]. (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. Transaction information of a transaction can include, but is not limited to: a requested amount of the transaction [0020-0023 0032])
in response to receiving the first resource transfer request, withholding the transfer of the first amount of the resource until an approval of the first resource transfer request is received and 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. 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. [0023 0024 0027 0031 0051] 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, based on the first resource transfer request, a first approval request notification comprising indications of the amount of the resource, […], 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 the first subset of the plurality of users and transmitting the first approval request notification to a second plurality of user devices associated with the second subset of the plurality of users. (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-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 generating and transmitting the notification to A, B, C and D.
in response to transmitting the first approval request notification to the first plurality of user devices and the second plurality of user devices, receiving from a user device of the first plurality of user devices or the second plurality of user devices, the approval of the first resource transfer request. (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. 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 [0005 0023 0031 0051])
upon receiving the approval of the first resource transfer request, transferring of the first 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:
a resource request processing system. (in step 410, the transmitting device 224 may route the data message (e.g., reformatted if necessary through an applicable executable process 210) to an authorization system 110 in the local region 306 as indicated by an executable process 210 associated with the action event 208. The authorization system 110 may then process the transaction accordingly.[0053])
for each resource system of at least two resource systems, the at least two resource systems comprising 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])
a proposal to transfer an first amount of a resource from the first user account to a second user account, and an identity of the user of the plurality of users. (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. [0024 0025])
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].
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.
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].
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;
withholding the transfer of the second amount of the resource until an additional approval of the second resource transfer request is received;
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;
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 another user device of the first plurality of user devices or the second plurality of user devices, the additional approval of the second resource transfer request; and
upon receiving the additional approval of the second resource transfer request, transferring the second amount of the resource from the first user account to the second user account via the second resource system;
Claim 9, a method with the same scope as claim 1, is rejected.
Claim 16, a CRM with the same scope as claim 1, is rejected.
With respect to claim 2, 10 and 17:
Fernandes further teaches wherein the graphical user interface further comprises resource system options that are associated with the corresponding approval status identifiers for each of the plurality of users. (FIGS. 5 and 6 illustrate exemplary interface components for controlling and configuring accounts. FIG. 5 shows how the system can create or allow users to create (i.e., through a control interface 500) a new rule from a transaction code 502. 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. Fig.5-6 [0038-0042])
Claim 10, a method with the same scope as claim 2, is rejected.
Claim 17, a CRM with the same scope as claim 2, is rejected.
With respect to claim 3, 11 and 18:
Fernandes further teaches wherein each approval status identifier is positionable in the graphical user interface in a first position or in a second position, wherein the first position is associated with the approval status of approver administrator or the approval status of approver non-administrator, and wherein the second position is associated with the approval status of non-approver non-administrator. (The method also includes 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. The hierarchy 300 can represent a user hierarchy of authorities with respect to participants in the payment system. For example, nodes in layer 1 can be financial institutions that are capable of issuing accounts to 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. [0004-0005 0028-0029])
Claim 11, a method with the same scope as claim 3, is rejected.
Claim 18, a CRM with the same scope as claim 3, is rejected.
With respect to claim 4, 12 and 19:
Fernandes further teaches wherein the operations further comprise: detecting an update to the approval status of the user of the plurality of users based on a user selection of an approval status identifier associated with 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 12, a method with the same scope as claim 4, is rejected.
Claim 19, a CRM with the same scope as claim 4, is rejected.
With respect to claim 6 and 14:
Fernandes further teaches:
receiving, from a second user device associated with a second user of the plurality of users, a third resource transfer request […] a proposal to transfer a third amount of the resource […] and an identity of the second user of the plurality of the 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. Transaction information of a transaction can include, but is not limited to: a requested amount of the transaction [0020-0023 0032])
determining, based on the user data, that an approval status of the second 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, transmitting a third approval request 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 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; (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 another user device of the first plurality of user devices or the second plurality of user devices, a denial of the third resource transfer reguest; and (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 of the third resource transfer, preventing a transfer of the third 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:
resource transfer request comprising the selected resource system, […] a proposal to transfer[…] from the first user account to the second user account. (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.). 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. [0024-0026])
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].
With respect to claim 7 and 15:
Fernandes further teaches:
receiving, from a second user device associated with a second user of the plurality of users, a third resource transfer request comprising […], a proposal to transfer a third amount of the resource […], and an identity of the second 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 user data, that an approval status of the second 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 second user is approver non- administrator, transmitting a third approval request 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; (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 another user device of the first plurality of user devices, an approval of the third resource transfer reguest; and (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 approval of the third resource transfer reguest, transferring the third 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:
resource transfer request comprising the selected resource system, […] a proposal to transfer[…] from the first user account to the second user account. (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.). 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. [0024-0026])
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 15, a method with the same scope as claim 7, is rejected.
With respect to claim 8:
Fernandes further teaches:
receiving, from a second user device associated with a second user of the plurality of users, a third resource transfer request comprising […], a proposal to transfer a third amount of the resource […], and an identity of the second 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 user data, that an approval status of the second 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 second user is approver administrator, transferring the third amount of the resource from the first user account to the second user account via the first resource system […]. (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.
Fernandes does not teach the following limitations. However,
McLaughlin teaches:
resource transfer request comprising the first resource system, […] a proposal to transfer[…] from the first user account to the second user account. (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.). 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. [0024-0026])
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(s) 5, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Fernandes" in view of “McLaughlin” as applied to claim 1, 9 and 16 above, and further in view of Harney et al. (US 20160071424 A1).
With respect to claim 5, 13 and 20:
Fernandes in view of McLaughlin does not teach wherein the operation of displaying the graphical user interface comprises loading a f portion of the user listing and the corresponding approval status identifiers at a first time and loading a second portion of the user listing the corresponding approval status identifiers at a second time. However,
Harney teaches wherein the operation of displaying the graphical user interface comprises loading a f portion of the user listing and the corresponding approval status identifiers at a first time and loading a second portion of the user listing the 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 to paginate user listing with the technique as disclosed by Harney to provide better user interface.
Claim 13, a method with the same scope as claim 5, is rejected.
Claim 20, a CRM with the same scope as claim 5, 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