DETAILED ACTION
This is office action on the merits in response to the application filed on 01/28/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 .
Double Patenting Rejection:
The examiner acknowledged the applicant’s request on double-patenting rejection. Double-patenting rejection is maintained and revised to reflect the amendment.
Rejection under 101:
The applicant mentions claim 19 of Example 2. However, the claimed invention is dealing with different issue in a different field of endeavor. Claim 19 of Example 2 is directed to activation of web page. However, the claimed invention is directed to authorizing resource transfer based on user approval status.
The applicant further argues that the claims provide technical improvement to securely transfer resource based on user approval status. The examiner respectfully disagrees. The claims recite a process to request and approve resource transfer, which is an abstract idea of commercial interactions. The claims further recite determining a user approval status, sending the request to a higher-level user for approval, which is an abstract of managing personal interactions between people. In addition, it may also fall into mitigating risks grouping of abstract idea. Combination of abstract ideas does not make the claims patentable eligible.
The applicant further argues that the claims provide technical improvement security by preventing the transfer. The examiner respectfully disagrees. It is fundamental commercial interactions to transfer when transaction authorized and to stop transfer when transaction declined.
Therefore, 101 rejection is maintained and made final.
Rejection under 103:
The applicant argues that cited reference does not teach the amended feature regarding “at least two resource systems”. The examiner agrees that cited reference does not teach the amended feature regarding “at least two resource systems”. However, the recited “at least two resource systems” is non-functional and does not distinguish the claims from prior arts because it is just data and does not used to perform the recited steps.
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.
Examiner Notes
With respect to claim 1, 9 and 16:
In addition with respect to “communicatively coupled via a network to a resource request processing system” this is nonfunctional descriptive material as it only describes a resource request processing system that is coupled to the system, while the resource request processing system is not with the scope the recited system and not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP 2111.05), Ex parte Nehls 88 USPQ2d 1883 (BPAI 2008)
In addition with respect to “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” and all the limitations related to “the at least two resource systems” this is nonfunctional descriptive material as it only describes the data that is contained in the user data, while the data contained in the user data is not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP 2111.05), Ex parte Nehls 88 USPQ2d 1883 (BPAI 2008) (precedential).
In addition with respect to “prevent the transfer of the amount of the resource from the first user account to the second user account via the selected resource system” is intended use of the resource request processing system and does not limit the scope of the claims. It has been held language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
With respect to claim 6-8 and 14-15:
In addition with respect to “cause the resource processing system to transfer the amount of the recourse from the first user account to the second user account via the selected resource system” is intended use of the resource request processing system and does not limit the scope of the claims. It has been held language that suggests or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. An example of such language includes statements of intended use or field of use (MPEP §2103 I C).
Drawings
The drawings are not of sufficient quality to permit examination. Accordingly, replacement drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to this Office action. The replacement sheet(s) should be labeled “Replacement Sheet” in the page header (as per 37 CFR 1.84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action.
Applicant is given a shortened statutory period of TWO (2) MONTHS to submit new drawings in compliance with 37 CFR 1.81. Extensions of time may be obtained under the provisions of 37 CFR 1.136(a) but in no case can any extension carry the date for reply to this letter beyond the maximum period of SIX MONTHS set by statute (35 U.S.C. 133). Failure to timely submit replacement drawing sheets will result in ABANDONMENT of the application.
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-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 steps that is performed by “a resource management system”. It is not clear whether:
a resource management system is part of the processing device, or
a resource management system is the processing device, or
a resource management system is outside of the processing device
for the purpose of examination, the examiner interpret that a resource management system is the processing device. All dependent claims are rejected.
Claims 1, 9 and 16 recite “receiving…user data stored in a relational database”. It is not clear whether the user data is stored in a relational database prior to the receiving OR after the receiving. It is also not clear whether or not the relational database is part of the recited system. For the purpose of examination, the examiner interpret that the user data is stored, after receiving, in a relational database of the recited system. 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, by a resource management system communicatively coupled via a network to a resource request processing system, user data stored in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status of each user of the plurality of users 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 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,
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;
displaying, by the resource management system and 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, by the resource management system and from a user device of the plurality of user devices 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 to transfer an 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 resource transfer request, determining, by the resource management system querying the relational database that an approval status of the user is non-approver non-administrator for the selected resource system;
in response to determining that the approval status of the user is non-approver non-administrator for the selected resource system,
generating, by the resource management system and based on the resource transfer request, 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
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with the first subset of the plurality of users and transmitting the 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 approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, by the resource management system and from a user device of the first plurality of user devices or the second plurality of user devices, a denial of the resource transfer request; and
upon receiving the denial of the resource transfer request, automatically preventing, by the resource management system, a transmission of the resource transfer request to the resource request processing system to prevent the transfer of the amount of the resource from the first user account to the second user account via the selected resource system.
Limitations B-G and L-M under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer environment in limitation B-G and L-M, 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 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, by a resource management system communicatively coupled via a network to a resource request processing system, user data stored in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status of each user of the plurality of users 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 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,
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;
displaying, by the resource management system and 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, by the resource management system and from a user device of the plurality of user devices 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 to transfer an 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 resource transfer request, determining, by the resource management system querying the relational database that an approval status of the user is non-approver non-administrator for the selected resource system;
in response to determining that the approval status of the user is non-approver non-administrator for the selected resource system,
generating, by the resource management system and based on the resource transfer request, 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
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with the first subset of the plurality of users and transmitting the 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 approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, by the resource management system and from a user device of the first plurality of user devices or the second plurality of user devices, a denial of the resource transfer request; and
upon receiving the denial of the resource transfer request, automatically preventing, by the resource management system, a transmission of the resource transfer request to the resource request processing system to prevent the transfer of the amount of the resource from the first user account to the second user account via the selected resource system.
The additional element(s) in limitation A-M are recited at a high level of generality. The additional elements of limitations A-M 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, by a resource management system communicatively coupled via a network to […], user data stored in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status of each user of the plurality of users[…], 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, by the resource management system and 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, by the resource management system and from a user device of the plurality of user devices associated with a user of the plurality of users, a resource transfer request comprising […], a proposal to transfer an 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 resource transfer request, determining, by the resource management system querying the relational database 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, by the resource management system and based on the resource transfer request, an approval request notification comprising indications of the amount of the resource, […], the identity of the user of the plurality of users, […]; and transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with the first subset of the plurality of users and transmitting the 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 approval request notification to the first plurality of user devices and the second plurality of user devices, receiving, by the resource management system and from a user device of the first plurality of user devices or the second plurality of user devices, a denial of the 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 denial of the resource transfer request, automatically preventing, by the resource management system, a transmission of the resource transfer request to the […] to prevent the transfer of 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:
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®, 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. [0006-0007 0024])
a resource transfer request comprising a selected 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 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].
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 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 second resource transfer request […] a proposal to transfer the 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 an additional 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 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, an approval indicator; 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 indicator, automatically transmitting the approval indicator to the resource request processing system to cause the resource request processing system to transfer the amount 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 second resource transfer request comprising […], a proposal to transfer the 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 an additional 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 indicator; 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 indicator, automatically transmitting the approval indicator to the resource request processing system to cause the resource request processing system to transfer the amount 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 second resource transfer request comprising […], a proposal to transfer the 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, automatically transmitting an approval indicator to the resource request processing system to cause the resource request processing system to transfer the amount the resource from the first user account to the second user account […]. (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 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(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 generating the graphical user interface comprises loading a f portion of the user listing corresponding approval status identifiers at a first time and loading a second portion of the user listing corresponding approval status identifiers at a second time. However,
Harney teaches wherein the operation of generating the graphical user interface comprises loading a f portion of the user listing corresponding approval status identifiers at a first time and loading a second portion of the user listing 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.
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