DETAILED ACTION
This is office action on the merits in response to the application filed on 02/18/2026.
Claims 1-22 have been filed by the applicant.
Claims 7 and 14 are presently canceled.
Claims 1, 5-6, 8, 12-13, 15 and 19-20 are currently amended.
Claims 1-6, 8-13 and 15-22 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/18/2026 has been entered.
Response to Argument
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 prevent unauthorized resource transfer by approving and modifying the resource transfer request 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.
Therefore, 101 rejection is maintained.
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-6, 8-12, 15-18 and 21-22 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 4-5, 7-9, 12-16 and 19-20 of copending Application No. 18633621 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other
Claim 1 is anticipated by claim 1 of Application No. 18634195.
Claim 2 is anticipated by claim 1 of Application No. 18634195.
Claim 3 is anticipated by claim 5 of Application No. 18634195.
Claim 4 is anticipated by claim 4 of Application No. 18634195.
Claim 5 is anticipated by claim 7 of Application No. 18634195.
Claim 6 is anticipated by claim 8 of Application No. 18634195.
Claim 8 is anticipated by claim 9 of Application No. 18634195.
Claim 9 is anticipated by claim 9 of Application No. 18634195.
Claim 10 is anticipated by claim 13 of Application No. 18634195.
Claim 11 is anticipated by claim 12 of Application No. 18634195.
Claim 12 is anticipated by claim 15 of Application No. 18634195.
Claim 15 is anticipated by claim 16 of Application No. 18634195.
Claim 16 is anticipated by claim 16 of Application No. 18634195.
Claim 17 is anticipated by claim 20 of Application No. 18634195.
Claim 18 is anticipated by claim 19 of Application No. 18634195.
Claim 21 is anticipated by claim 7 of Application No. 18634195.
Claim 22 is anticipated by claim 1 of Application No. 18634195.
This is a provisional nonstatutory double patenting rejection.
Examiner Notes
With respect to claim 1, 8 and 15:
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 “cause the resource request processing system to perform the transfer of the modified amount of the resource from the first user account to the second user account via the selected resource system” 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 5-6, 12-13 and 19-20:
In addition with respect to “cause the resource request processing system to perform the transfer of the amount of the resource from the first user account to the second user account” 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 21:
In addition with respect to “cause the resource request processing system to perform the transfer of the amount of the funds from the first user account to the second user account via the second 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 22:
In addition with respect to “to prevent the resource request processing system from performing the transfer of the amount of the funds” 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-22 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 15 recite “a processing device” for performing the recited steps. However, claims 1 and 15 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 22 recite steps that are performed by “the resource management system”. However, Claims 1 recite “a processing device” for performing the recited steps. 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.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6, 8-13 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-6 are directed to a system comprising a memory and a processor, claims 8-13 are directed to a method, and claims 15-20 are directed to a non-transitory computer-readable storage medium. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 8 and 15, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising:
storing, by a resource management system communicatively coupled via a network to a resource request processing system, user data in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status for each user of the plurality of users for each resource system of at least two resource systems, wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers, and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein:
a first subset of the plurality of users with the approval status of approver administrator for one or more of the at least two resource systems are permitted to cause resource transfers to or from a first user account associated with the entity via the one or more of the at least two resource systems and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems
a second subset of the plurality of users with the approval status of approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems, and
a third subset of the plurality of users with the approval status of non- approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems;
receiving, by the resource management system and from a user device associated with a user of the plurality of users, a resource transfer request comprising a selected resource system of the at least two resource systems, a proposal toa request to transfer an amount of a resource from a first user account associated with the entity to a second user account, and an identity of the user of the plurality of users;
determining, by the resource management system querying the relational database and based on the user data, that an approval status of the user is non-approver non-administrator;
in response to determining that the approval status of the user is non- approver non-administrator,
generating, by the resource management system, an approval request notification comprising indications of the amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the selected resource system; and
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator for the selected resource system and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-administrator for the selected resource system, wherein the approval request notification further consists of an approve option, a deny option, and a modification option;
receiving, by the resource management system and from an additional user device of the first plurality of user devices or the second plurality of user devices, an approval indicator comprising a modification to the amount of the resource in response to a user selection of the modification option at the additional user device; and
upon receiving the approval indicator, automatically transmitting, by the resource management system, the approval request notification and the modification to the amount of the resource to the resource request processing system to cause the resource request processing system to perform the transfer of the modified amount of the resource from the first user account to the second user account via the selected resource system.
Limitations B-F and K-L under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer environment in limitation B-F and K-L, nothing in the claim element differentiates the limitation from processes of receiving request, receiving approval and perform transfer. Therefore, limitations B through H recite an abstract idea, as highlighted above, that is consistent with the commercial interactions aspects of Certain Methods of Organizing Human Activity.
Furthermore, limitation G-J recites “determining user approval status and send transfer request to higher-level users for approval” which is abstract idea of managing personal interactions between people within the “certain methods of organizing human activity” grouping of abstract ideas. The additional elements in limitation G-J merely serving as a tool to perform the abstract idea.
Accordingly, claim 1, and by analogy similar claims 8 and 15, recite an abstract idea and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising:
storing, by a resource management system communicatively coupled via a network to a resource request processing system, user data in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status for each user of the plurality of users for each resource system of at least two resource systems, wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers, and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein:
a first subset of the plurality of users with the approval status of approver administrator for one or more of the at least two resource systems are permitted to cause resource transfers to or from a first user account associated with the entity via the one or more of the at least two resource systems and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems
a second subset of the plurality of users with the approval status of approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems, and
a third subset of the plurality of users with the approval status of non- approver non-administrator for the one or more of the at least two resource systems are permitted to request resource transfers to or from the first user account via the one or more of the at least two resource systems for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account and with respect to the one or more of the at least two resource systems;
receiving, by the resource management system and from a user device associated with a user of the plurality of users, a resource transfer request comprising a selected resource system of the at least two resource systems, a proposal toa request to transfer an amount of a resource from a first user account associated with the entity to a second user account, and an identity of the user of the plurality of users;
determining, by the resource management system querying the relational database and based on the user data, that an approval status of the user is non-approver non-administrator;
in response to determining that the approval status of the user is non- approver non-administrator,
generating, by the resource management system, an approval request notification comprising indications of the amount of the resource, the first user account, the second user account, the identity of the user of the plurality of users, and the selected resource system; and
transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator for the selected resource system and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-administrator for the selected resource system, wherein the approval request notification further consists of an approve option, a deny option, and a modification option;
receiving, by the resource management system and from an additional user device of the first plurality of user devices or the second plurality of user devices, an approval indicator comprising a modification to the amount of the resource in response to a user selection of the modification option at the additional user device; and
upon receiving the approval indicator, automatically transmitting, by the resource management system, the approval request notification and the modification to the amount of the resource to the resource request processing system to cause the resource request processing system to perform the transfer of the modified amount of the resource from the first user account to the second user account via the selected resource system.
The additional element(s) in limitation A-G and I-L are recited at a high level of generality. The additional elements as recited merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). As such, when the additional elements are considered individually and as an ordered combination, the claim as a whole amounts to no more than or mere a computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than implementing an abstract idea on a generic computer. This is not enough to provide an inventive concept. Therefore, claims 1, 8, and 15 are not patent eligible.
Dependent claims 2, 9 and 16 further recite a plurality of user listing and corresponding approval status identifiers which is mere data. The additional element of generating graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 3, 10 and 17 further recite loading a first subset of user listing and a second subset of listing which further recites the abstract idea. The additional element of generating graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 4, 11 and 18 further recite detecting an update and updating the user data which further recites the abstract idea. The additional element of graphical user interface generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 5, 12 and 19 further recite receiving and approve request and transferring resource which further recites the abstract idea. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 6, 13 and 20 further recite receiving and approve request and transferring resource which further recites the abstract idea. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 21 further recite the similar process as in claim 1 and to perform the transfer which is still the abstract idea of commercial interactions. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 22 further recite the similar process as in claim 1 and to deny the transfer which is still the abstract idea of commercial interactions. The additional element of user devices merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)). The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 4-6, 8-9, 11-13, 15-16 and 18-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fernandes (US 20150120546 A1), and further in view of McLaughlin et al. (US 20190019169 A1) and Zuber (US 20130254082 A1).
With respect to claim 1, 8 and 15:
Fernandes teaches:
A system comprising: a processing device; and a memory device that includes instructions executable by the processing device for causing the processing device to perform operations comprising. (Accordingly, the invention can be implemented in numerous ways, including as an apparatus, a system, a device, a computer-implemented method, and/or a computer-readable medium such as a non-transitory computer-readable storage medium with computer-readable instructions or other program code, which when executed by one or more processors, cause a computer to perform a method in accordance with the one or more embodiments. Examples of a medium includes, but is not limited to, circuit-based media (e.g., read-only memory, flash memory. [0055])
storing, by a resource management system communicatively […], user data in a relational database, the user data comprising a plurality of users associated with an entity and comprising an approval status for each user of the plurality of users[…], and wherein the approval status of each user of the plurality of users is selected from a group consisting of approver administrator, approver non-administrator, and non-approver non-administrator, wherein: a first subset of the plurality of users with the approval status of approver administrator […] are permitted to cause resource transfers to or from a first user account associated with the entity […] and to approve resource transfers initiated by other users of the plurality of users with respect to the first user account 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 […], and a third subset of the plurality of users with the approval status of non-approver non-administrator […] are permitted to request resource transfers to or from the first user account […] for approval by other users in the first subset and the second subset and are prevented from approving resource transfers initiated by other users of the plurality of users with respect to the first user account […]. (The enrollment unit 222 can process new enrollments of payment service participants such as purchasers and merchants. The enrollment unit 222 can further process all requests and responses related to management of accounts. The enrollment unit 222 can ensure that registration data is stored in a format that is in accordance with data formatting requirements such as storage in a lookup table as described below. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. The account hierarchy 300 can be stored as any directed graph-like data structure that maintains nodes and vertices, where nodes can have pointers to other nodes (vertices) indicating superordinacy or subordinarcy. Thus, for example, the database may store a separate hierarchy lookup table according to hierarchy 300 as follows. The hierarchy 300 can also include additional information regarding authorities. For example, node E has superordinate nodes A, B, C, and D but a transaction initiated with node E must be authorized by A, by B, or by C and D. As another example, the hierarchy 300 may be integrated with specific rules. Rules can be quota-based. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0025 0027 0029 0031] Fig. 3). It would have been obvious that without having the exact same groups as recited in the claims, Fernandes discloses the same structure of user groups with approval status by introducing account hierarchy with superordinacy and subordinarcy.
receiving, by the resource management system and from a user device associated with a user of the plurality of users, a resource transfer request comprising […], a proposal to transfer an amount of a resource from a first user account associated with the entity to a second user account. and an identity of the user of the plurality of users; (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, by the resource management system querying the relational database and based on the user data, that an approval status of the user is non-approver non-administrator; (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, 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 transmitting, by the resource management system, the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users with an approval status of approver administrator […] and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users with an approval status of approver non-[…], wherein the approval request notification further consists of an approve option, a deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, by the resource management system and from an additional user device of the first plurality of user devices or the second plurality of user devices, an approval indicator […]; (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, by the resource management system, the approval request notification and the […] amount of the resource […] to perform 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:
coupled via a network to 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. wherein the at least two resource systems comprise a first resource system related to automated clearing house payments and a second resource system related to wire transfers. (A system for intelligent switching for multiple transaction types. the system 100 may include an authorization system 110a configured to process payment transactions funded via the payment instrument 108a in addition to an authorization system 110b configured to process payment transactions funded via the payment instrument 110b. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, 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])
generating, […] an approval request notification comprising […] and the selected resource system; and transmitting, […], the approval request notification to a first plurality of user devices associated with a first subset of the plurality of users […] for the selected resource system and transmitting the approval request notification to a second plurality of user devices associated with a second subset of the plurality of users […] for the selected resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
automatically transmitting, […] the approval request notification […] to the resource request processing system to cause the resource request processing system to perform the transfer […] from the first user account to the second user account via the selected resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification further consists of […] a modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
an approval indicator comprising a modification to the amount of the resource in response to a user selection of the modification option at the additional user device; automatically transmitting the approval request notification and the modification to the amount of the resource […] to perform the transfer of the modified amount of the resource […]. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections, he will click "Approve Draft Invoice,". After the final member of the reviewer sequence has reviewed the invoice and clicked on "Approve Draft Invoice," a final version of the invoice may be issued. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
Claim 8, a method with the same scope as claim 1, is rejected.
Claim 15, a CRM with the same scope as claim 1, is rejected.
With respect to claim 2, 9 and 16:
Fernandes further teaches generating a graphical user interface comprising a plurality of user listings and corresponding approval status identifiers, wherein each user listing of the plurality of user listings corresponds to a user of the plurality of users, and wherein the corresponding approval status identifiers indicate the approval status of each user of the plurality of users. (The account hierarchy 300 can be stored as any directed graph-like data structure that maintains nodes and vertices, where nodes can have pointers to other nodes (vertices) indicating superordinacy or subordinarcy. Thus, for example, the database may store a separate hierarchy lookup table according to hierarchy 300 as follows. FIG. 6 shows an exemplary account-creation interface 600 in which the administrator can create new accounts with previously-created rules. The account-creation interface 600 can present to the administrator a grouping of rules and all--preferably subordinate--accounts to which the grouping applies. [0029 0042])
Claim 9, a method with the same scope as claim 2, is rejected.
Claim 16, a CRM with the same scope as claim 2, is rejected.
With respect to claim 4, 11 and 18:
Fernandes further teaches wherein the operations further comprise: detecting an update to the approval status of the user based on a user selection of an approval status identifier for the user at the graphical user interface; and updating the user data based on the update to the approval status. (FIG. 6 shows an exemplary account-creation interface 600 in which the administrator can create new accounts with previously-created rules. The account-creation interface 600 can present to the administrator a grouping of rules and all--preferably subordinate--accounts to which the grouping applies. The administrator can then create a new rule, which the system receives along with other parameters at S810, stores at S812, and applies to a subaccount in accordance with received parameters at S814. The subaccount to which the new rule is applied can be a different subaccount from the subaccount with which the transaction was initiated. Fig. 5-6 [0042 0047])
Claim 11, a method with the same scope as claim 4, is rejected.
Claim 18, a CRM with the same scope as claim 4, is rejected.
With respect to claim 5, 12 and 19:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a second resource transfer comprising […] another proposal to transfer the amount of the resource[…] and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the user data, that an approval status of the additional user is approver non-administrator; (The method includes generating a transaction code for the transaction that is initiated with a payment service subaccount. The transaction code including transaction information. The method also includes determining whether to place a lock on the transaction. If, based on the determining step, the lock should be placed on the transaction, the method proceeds with placing the lock on the transaction, identifying an administrator of the payment service subaccount using an account hierarchy and a hierarchical position of the payment service subaccount in the account hierarchy, transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. If, based on the determining step, the lock should not be placed on the transaction, the method proceeds with allowing the transaction to proceed. The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0005 0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver non-administrator, transmitting another approval request notification to the first plurality of user devices; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0024 0027 0031]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, from a user device of the first plurality of user devices, an additional approval indicator; (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the additional approval indicator, automatically transmitting the additional approval indicator to […]to perform the transfer of the amount the resource from […]. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
a second resource transfer request comprising another selected resource system of the at least two resource systems, another proposal to transfer the amount of the resource from the first user account associated with the entity to the second user account[…]. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
automatically transmitting the additional approval indicator to the resource request processing system to cause the resource request processing system to perform the transfer of the amount the resource from the first user account to the second user account. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Claim 12, a method with the same scope as claim 5, is rejected.
Claim 19, a CRM with the same scope as claim 5, is rejected.
With respect to claim 6, 13 and 20:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a second resource transfer request comprising […], another proposal to transfer the amount of the resource from […], and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the user data, that an approval status of the additional user is approver administrator; and (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver administrator, automatically transmitting an approval indicator to […] perform the transfer of the amount the resource […]. (The user presented with this interface can be an account holder of a superordinate account creating a rule for a subordinate account or an administrator at a financial institution creating a rule for account holders associated with the financial institution that are subordinate to the financial institution in the payment system hierarchy. [0038]). It would have been obvious that an account holder of a superordinate account (i.e., approver administrator) do not requires approval in order to transfer resource.
McLaughlin further teaches:
resource transfer request comprising another selected resource system of the at least two resource systems, […] from the first user account to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
automatically transmitting […] the resource request processing system to cause the resource request processing system to perform the transfer of the amount the resource from the first user account to the second user account. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Claim 13, a method with the same scope as claim 6, is rejected.
Claim 20, a CRM with the same scope as claim 6, is rejected.
With respect to claim 21:
Fernandes further teaches:
receiving, from an additional user device associated with an additional user of the plurality of users, a second resource transfer request comprising […], a proposal to transfer an amount of funds from the […], and an identity of the additional user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
determining, based on the user data, that an approval status of the additional user is approver non-administrator; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. The hierarchy 300 can represent an account hierarchy of authorities with respect to one or more accounts. For example, the hierarchy can include account nodes A-E, each representing a payment account with an associated account holder, and a representation of the hierarchical relationship of those nodes. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. [0024 0027] Fig. 3). It would have been understood that approval status is determined by querying to retrieve hierarchical relationship of the nodes.
in response to determining the approval status of the additional user is approver non- administrator, transmitting a second approval request notification as a push notification to the first plurality of user devices, the second approval request notification comprising indications of the amount of the funds, […], the identity of the additional user, […], and the second approval request notification consisting of the approve option, the deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction, and/or create a rule for all future transactions. The option to create a rule is transmitted with a rule flag in the authorization response so that the system can create a new rule to be applied to the subaccount for future transactions. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, from a user device of the first plurality of user devices, an additional approval indicator in response to a user selection of the approve option at the user device of the first plurality of user devices. (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the additional approval indicator, automatically transmitting the additional approval indicator to […] perform the transfer of the amount of the funds […]. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
transfer request comprising a selection of the second resource system of the at least two resource systems, […] first user account associated with the entity to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
request notification comprising indications of […] the first user account, the second user account, […], and the second resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
automatically transmitting […] indicator to the resource request processing system to cause the resource request processing system to perform the transfer of the amount of the funds from the first user account to the second user account via the second resource system. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification consisting of […] a modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
With respect to claim 22:
Fernandes further teaches:
receiving, by the resource management system and from the user device associated with a user of the plurality of users, a second resource transfer request comprising […], a proposal to transfer an amount of funds […], and the identity of the user of the plurality of users; (Finally, the transaction code generator 202 can also run on the server side of network 204 and receive transaction information in alternative formats from other devices connected to network 204 upon which the transaction code generator will operate. The transaction code can be sent in a transaction authorization request over a network 204 to a communications layer 206 of the payment system 200. The web server 214 can receive the transaction authorization request, perform any necessary front-end processing, and forward the transaction authorization request to the accounts logic layer 218. [0020-0023])
generating, by the resource management system, a second approval request notification comprising indications of the amount of the funds, […], the identity of the user of the plurality of users, and the first resource system; and transmitting, by the resource management system, the second approval request notification as a push notification to the first plurality of user devices associated with the first subset of the plurality of users with the approval status of approver administrator […] and transmitting the second approval request notification as a push notification to the second plurality of user devices associated with the second subset of the plurality of users with the approval status of approver non-administrator […], wherein the second approval request notification further consists of the approve option, the deny option, […]; (The accounts logic layer 218 can perform most processing related to the transaction and account. For example, upon receiving the transaction authorization request from the presentation layer 212, an administrator identifying unit 220 identifies an administrator of a subject account with which the transaction was initiated, for example, by querying a database 232 through a data access layer 230 to retrieve and traverse one or more hierarchies (see FIG. 3) that include the subject account. For example, in hierarchy 300, account A is superordinate to subordinate accounts C and E. In certain embodiments, an account holder of a superordinate account can authorize and lock transactions (e.g., by creating rules) initiated with subordinate accounts. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction, and/or create a rule for all future transactions. The option to create a rule is transmitted with a rule flag in the authorization response so that the system can create a new rule to be applied to the subaccount for future transactions. [0024 0027 0031 0051]). Although not specific stated in the prior art, it would have been obvious to one in the art that querying hierarchical information and having account A, B, C or D to authorize transaction from account E requires transmitting alerts to A, B, C and D.
receiving, by the resource management system and from a user device of the first plurality of user devices, a denial indicator in response to a user selection of the deny option at the user device of the second plurality of user devices. (transmitting an authorization request including the transaction code to a portable electronic device of the administrator, and removing or maintaining the lock based on an authorization response received from the portable electronic device of the administrator in response to the authorization request. The model/interface generator 216 can generate a presentation model and interface that is displayed to the purchaser, the merchant, and/or an administrator upon receiving a transaction authorization response from the accounts logic layer 218. Transactions using account E exceeding $1,000 must be authorized by A and B, exceeding $100 must be authorized by A or B, and exceeding $20 must be authorized by A, B, C, or D. Rules can be merchant-based. Transactions using account E at merchant M1 must be authorized by A, B, or C while transactions using account E at merchant M2 must be authorized by A, B, or D. [0005 0023 0031])
upon receiving the denial indicator, automatically preventing, by the resource management system, the second approval request from being transmitted […] to prevent […] from performing the transfer of the amount of the funds. (An authorization interface displayed to the administrator who receives the authorization request can include options to approve the transaction, toll the timeout period, contact (e.g., SMS or call) the subaccount holder (which, preferably, automatically tolls the timeout period), decline the transaction. If the administrator did not authorize the transaction, then the accounts locking unit maintains the temporary lock. If the administrator authorized the transaction, then the temporary lock is removed by the accounts locking unit at S924, the transaction is allowed to proceed at S926, and the method 900 ends. [0050-0051])
McLaughlin further teaches:
transfer request comprising a selection of the second resource system of the at least two resource systems, […] first user account associated with the entity to the second user account. (In the system 100, the participant system 106 may submit every transaction directly to the processing server 102 using a suitable communication network and method. The processing server 102 may receive a data message from the participant system 106 (e.g., or an intermediate entity, as applicable) that includes this transaction data. The data message may also include data that is used by the processing server 102 to identify a type of transaction indicated by the data message. For example, an integer value may be associated with each transaction type that the processing server 102 is configured to route (e.g., a ‘1’ for credit card transactions, ‘2’ for wire transfers, ‘3’ for blockchain transactions, etc.). [0026])
approval request notification comprising indications of […], the first user account, the second user account. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
transmitting, […] approval request notification […] to the […] first subset of the plurality of users […] for the selected resource system and transmitting , […] approval request notification […] to the […] second subset of the plurality of users […] for the selected resource system. (the tied executable processes are then executed to perform any necessary processing and culminating in the intelligent routing of the transaction message to the appropriate processing system. [0005]). Fernandes discloses to route transaction request to appropriate personnel, McLaughlin discloses to route transaction request to appropriate system. It would have been understood for a person in the art to route the transaction request to the appropriate personnel of the appropriate system.
automatically preventing, […] request from being transmitted the resource request processing system to prevent the resource request processing system from performing the transfer […]. (The participant system 106 may receive the payment details and may submit the payment details along with other transaction data for processing. In conventional systems, the participant system 106 would submit the payment details and transaction data to an authorization system 110. In an example, the payment instrument 108a may be a credit card, where the authorization system 110a may be a credit card processing network, such as one operated by Mastercard®, whereas the payment instrument 108b may be account details for a transaction account where the transaction is a wire transfer where the authorization system 110b is the Automated Clearing House (ACH). In another example, a payment instrument 108 may be a blockchain wallet, where the authorization system 110 is a node in a blockchain network configured to process blockchain transactions. transmitting, by a transmitter (e.g., the transmitting device 224) of the processing server, the received data message to an authorization system (e.g., authorization system 110) associated with the specific data type, and the plurality of data types includes at least a financial transaction message and an automated clearing house message. [0024 0025 0056]])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes to collaborate with different resource system with the technique as disclosed by McLaughlin to be more efficient and more effective as McLaughlin suggested [0005].
Fernandes in view of McLaughlin does not teach the following limitations. However,
Zuber teaches (in italic):
approval request notification consisting of […] a modification option. (When the first member clicks on the invoice approval request, the draft invoice will open on his screen, and he will then be able to review the invoice. After he has reviewed it, and made any comments or corrections. [0010])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin to correct request and transfer based on correction with the technique as disclosed by Zuber to provide a more efficient means for review, correction, and approval [0007].
Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Fernandes" and “McLaughlin” and “Zuber” as applied to claim 2, 9 and 16 above, and further in view of Harney et al. (US 20160071424 A1).
With respect to claim 3, 10 and 17:
Fernandes in view of McLaughlin and Zuber does not teach generating the graphical user interface comprises loading a first subset of the plurality of user listings and corresponding approval status identifiers at a first time and loading a second subset of the plurality of user listings and corresponding approval status identifiers at a second time. However,
Harney teaches generating the graphical user interface comprises loading a first subset of the plurality of user listings and corresponding approval status identifiers at a first time and loading a second subset of the plurality of user listings and corresponding approval status identifiers at a second time. (After a selection is made, the interface may update to show the users matching the selected filters. Results may be paginated (e.g., by showing 10, 25, 50, 100, etc. results per page). [0087])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Fernandes in view of McLaughlin and Zuber to paginate user listing with the technique as disclosed by Harney to provide better user interface.
Claim 10, a method with the same scope as claim 3, is rejected.
Claim 17, a CRM with the same scope as claim 3, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170011450 A1: Similarly for an organization, organizations will have policies governing their purchasing process. For example, approval for making a purchase will involve approval from a tech lead, a tech manager, and a director. In one exemplary scenario, the current system will provide preapproval to be at any level of the organization, and/or add additional users per approval from existing members.
US 12147985 B1: This may include, for example, querying a supervisory user associated with the same organization as the requesting user, via a user computing device, and requesting that the supervisory user approve the requested fund transfer. Obtaining higher approval, in some examples, may include querying a user within the financial institution handling the fund transfer to request approval of the requested fund transfer. In some examples, the supervisory user or other queried user may decline to provide higher level approval, in which the requested fund transfer may be declined. If the risk score is not greater than the threshold at operation 804 and/or after higher-level approval is obtained at operation 806, the transfer application 114 may execute the requested fund transfer at operation 808.
US 20160342992 A1: The administrator may be able to set and update or change varying levels of access privilege (or “permissioning” features) allowing the authorized user to have full to no discretion over spending on the account, e.g., to control where, when, what, how much the authorized user may spend funds available in the account, or make a deposit into the account.
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