DETAILED ACTION
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 .
Status of Claims
This Office action is in response to correspondence received September 15, 2025.
Claims 1, 8, 12, and 15 have been amended. Claim 22 is newly added. Claims 1-12 and 15-22 are pending and have been examined.
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 September 15, 2025 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-12 and 15-22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Examiner appreciates that Applicant took the care to show in the specification where Applicant found support for the submitted amendments. This is not a requirement, but it advances prosecution in a compact manner.
Per claims 1, 8, and 15, which are similar in scope:
After a careful review, Applicant has taken generic, state of the art descriptions and turn them into claim limitations. This is New Matter as it does not describe the actual invention attempting to be patented. Applicant can only amend from the original disclosure and every element of an amendment must be present in the original disclosure, in the same combination as claimed, or its equivalent in order to overcome a New Matter rejection.
Applicant’s first amendment is the limitation:
wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other
Applicant has recited three software platforms that are “disparate.” However, Applicant has no support that the three software platforms do not integrate with each other.
The following were submitted as support but are insufficient for the following reasons:
Paragraph 3. The background paragraph generically describes the state of the art, as it were, in broad strokes. This does not describe the invention as Applicant did not invent the state of the art. The only support that could be argued is: “Technical problems exist as electronic resource management systems are typically not integrated (e.g., based on unique application layers or distinct software platforms that are offered by different vendors).” However, this state of what is “typically done” does not provide support for the positive elements of three “disparate” software platforms with the negative limitation that they do not integrate with each other.
Par 130. Specifically highlighted by Applicant, the paragraph states, “[a]s described herein, entities conventionally utilize non-integrated or disparate electronic resource management systems to maintain data associated with an event.” Here, there is no support for three disparate software platforms that do not integrate with each other. First, this describes electronic resource management systems. While the scope of an electronic resource management system and a software platform may overlap, that is not clear from this description. Second, there are not three disparate software platforms described here, and then that each of these three do not integrate with each other, as is the scope of the newly added claim limitation. Third, “non-integrated or disparate” are the adjectives and they are reasonably understood to be interchangeable. The sentence states that these are “non integrated or disparate” and there is no way to distinguish between what is non integrated and what is disparate. However, in the newly recited amended limitation, there are three disparate software platforms that do not integrate with each other, which are described separately. First, the software platforms are disparate, but then, as a negative limitation, the disparate software platforms do not integrate with each other. Applicant has taken one generic, broad scope statement about the state of the art and split it into two separate specific meanings in a newly recited limitation.
Finally, paragraph 150 contradicts Applicant’s attempt at weaving positive claim recitations from generic state of the art descriptions as it states that “application interface overcomes difficulty in integrating third party electronic resource management systems….” However, difficulty in integrating describes systems that integrate with each other albeit with difficulty, and does not describe systems that do not integrate with each other.
Therefore, in the absence of a disclosure of three software platforms or their equivalent that are both disparate and also do not integrate with each other, there is not support for this limitation and it is new matter.
The second new matter is the limitation where modifying the event data is based on both the event and the first, the second, and the third software platforms not integrating with each other. The reasonable understanding of this is that the fact that the first, second, and third software platforms are not integrating is either a cause of or is the reason for the event data modification. This is because the event data modification has to be based on the platforms not integrating with each other, which is an antecedent reason for modifying the event data (it is not merely a happenstance or something that is also occurring or existing alongside the event data). This is not disclosed. A review of the paragraphs does not show that modifying of event data is based on the three software platforms not integrating with each other. At best there are two software platforms described in par 0130 as not integrating with each other and having event data, however the modification of event data is not based on three software platforms not integrating with each other (also the software platforms must be—distinct from not integrating with each other-disparate). Therefore, this is new matter.
See the bold part for the second new matter:
and initiating an event modification indicative of a transfer of resources by instructing at least one resource management software to modify event data associated with the event across the plurality of disparate software platforms within the timeframe for the resource transfer, wherein modifying the event data comprises, based on (i) the event and (ii) the first, second, and third software platforms not integrating with each other
The third new matter is modifying within the timeframe, which must be done for a modification that is based on the event and the first, second, and third platforms not integrating with each other (previous new matter). Not only is the combination new matter, but there is no support for modifying the event data within the timeframe, where the timeframe is previously defined as the timeframe for the resource transfer. Examiner reviewed the entire disclosure and did not find support for this additional limitation of the modification of the event data.
Claim 22 is likewise new matter as it further limits what is new matter, the first second and third software platforms not integrating with each other, the reason being that they have unique application layers or being offered by different vendors. That possible equivalents to software platforms (the electronic resource management system which is actually described in the specification) are generally described as not integrating due to these reasons does not support positively claiming three, a specific number of “software platforms,” which is then caused by this reason.
In conclusion, while Applicant makes generic statements in the specification about state of the art, Examiner has shown that there is no specific support for these limitations in the claims, nor has Applicant shown where there is specific support for these limitations.
Claims 2-7, 9-11, and 16-22 are rejected for being dependent on the independent claims.
Therefore, claims 1-12 and 15-22 are rejected under 35 USC 112.
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.
Claim 1-12 and 15-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1, 8, and 15 recites:
A method for reconciling one or more data fields across a plurality of disparate software platforms, the method comprising: obtaining a candidate modification parameter indicating a candidate modification to apply to an event associated with the plurality of disparate software platforms, wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other; in response to obtaining the candidate modification parameter, and based on the candidate modification parameter and a set of resource parameters, determining a resource collection, from among a plurality of resource collections, to support the event; determining a modification to the event based on the candidate modification parameter and the resource collection; determining a timeframe for resource transfer based on a time-dependent variable specific to the event; and initiating an event modification indicative of a transfer of resources modify event data associated with the event across the plurality of disparate software platforms within the timeframe for the resource transfer, wherein modifying the event data comprises, based on (i) the event and (ii) the first, second, and third software platforms not integrating with each other , modifying within the timeframe: a first data field of the plurality of disparate software platforms and associated with a first entity owing a specific obligation to a second entity and associated with the specific obligation, a second data field of the plurality of disparate software platforms and associated with the specific obligation and associated with the second entity, and a third data field of the plurality of disparate software platforms and associated with the specific obligation and associated with a third entity covering at least a portion of the specific obligation on behalf of the first entity.
The abstract idea in claims 1, 8, and 15 is a certain method of organizing human activity – a commercial interaction, because the limitations pertaining to resource transfers. Resource transfers include financial transactions, see par 031 – monetary provider and monetary recipient. Transferring money is a foundational commercial interaction, and the limitations above merely detail how the transfer would be done based on rules. This is further clear from the limitation, “and a third data field of the plurality of disparate software platforms and associated with the specific obligation and associated with a third entity covering at least a portion of the specific obligation on behalf of the first entity,” which can be reasonably interpreted as providing a loan, and loans are elemental financial transactions. Making rules about a commercial interaction, which each of these abstract ideas do, further limits the abstract idea that is a commercial interaction.
Therefore, Applicant’s independent claims recite an abstract idea that is, without more, patent ineligible.
This judicial exception is not integrated into a practical application. The elements, listed below, alone and in combination, are applied elements, in that they are recited at a high level of generality without details as to how they work and are instructions to apply them to the abstract idea. See MPEP 2106.05(f)(1-2). Each claim recites elements that amount to a generic computer:
claim 1:
computer-implemented method
performing a step across a plurality of disparate software platforms, wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other;
by instructing at least one resource management software to [perform abstract idea steps]
data accessible to a first, second, third software platform
claim 8:
A computing device, comprising: one or more processors; and computer storage memory having computer-executable instructions stored thereon which, when executed by the processor, implement a method;
performing a step across a plurality of disparate software platforms, wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other;
by instructing at least one resource management software to [perform abstract idea steps]
data accessible to a first, second, third software platform
claim 15, Computer storage media having computer-executable instructions stored thereon which, when executed by a processor, implement a method;
performing a step across a plurality of disparate software platforms, wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other;
by instructing at least one resource management software to [perform abstract idea steps]
data accessible to a first, second, third software platform
Then, each independent claim recites an applied software element or elements which, when combined with the computer element, amounts to no more than an instruction to run the software on a computer, which is understood as how software runs. This therefore cannot be an integration of an abstract idea into a practical application, because it is similar to the examples in MPEP 2106.05(f)(2) (“Requiring the use of software to tailor information and provide it to the user on a generic computer,” “A commonplace business method or mathematical algorithm being applied on a general purpose computer,”). The addition of a computer to applied software would not be a combination that is a practical application because all software is understood to be run on a computer in order to be used in any way. The step of instructing a software across the plurality of software platforms has no detail as to how this is accomplished and therefore this is reciting a desired result or outcome. See MPEP 2106.05(f)(1). This is similar to a creation of a dynamic document based on different record types which is collecting and displaying data without more. See Intellectual Ventures v Capital One Fin Corp, MPEP 2106.05(f)(1). This is because in both there are record modifications but no detail as to the type of modifications or how the modifications are accomplished. In combination, the additional elements amount to instructions to apply software (computers and ordinary machinery – MPEP 2106.05(f)(2)) to the abstract idea. Therefore, the additional elements both alone and in combination are mere apply it elements and are not a practical application of the abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the same reasoning that applies in the practical application step, Prong 2, above, applies here. Therefore, because the elements alone and in combination are mere instructions to apply, these claims do not recite significantly more than the abstract idea.
Claims 2-6 further define the abstract idea because the limitations further limit variously named parameters and other information elements that further define the rules of the commercial interaction claimed in claim 1.
Claim 7 recites that software that is “owned” by “entities” is instructed (first and second software) and these are additional elements that in combination are not a practical application or significantly more because notably there is no detail about the software except that it is operated by an entity.
Claims 9-12, 15, and 21 further define the abstract idea and the limitation in claim 10 about software that modifies the event data is not a practical application because, similar to the analysis in claim 8, the recitation that software does something like “modifies an event” without detail is just an instruction to use software to tailor information. So, claims 9, 11-15 further define the abstract idea with limitations about how information like parameters are changed and claim 10 with an instruction to use software to perform an abstract idea step are not a practical application or significantly more than the abstract idea of claim 8. Claim 21 further defines modification parameters which are a part of the abstract idea.
Claims 16-20 further define the abstract idea with limitations about how to perform certain steps and in what order based on priority. Claims 16-20 do not recite additional elements that alone or in combination would be a practical application or significantly more than the abstract idea of claim 15.
Claim 22 further describes the additional elements of the disparate “or” non-integrated software platforms as those with unique application layers or “being offered by different vendors,” which under a broadest reasonable interpretations includes software whose distinguishing feature is that they are available from different commercial entities. The fact of being sold by different entities does not mean that something is inherently technically distinct as there is nothing preventing two software companies from making integration difficult or not having “interoperability,” while being in terms of patent scope the same thing (two word processors or two spreadsheet programs defined by their functional results). Therefore, this is a further apply it limitation.
Therefore, claims 1-12 and 15-22 are rejected under 35 USC 101.
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-12, 15-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurian et al., US PGPUB 20180308073 A1 (“Kurian”) in view of Lee et al., US Pat No 10789600 B1 (“Lee”).
Per claims 1, 8, and 15, which are similar in scope Kurian teaches A computer-implemented method for reconciling one or more data fields across a plurality of disparate software platforms, the computer- implemented method comprising in par 042: “Initially, at block 210 of FIG. 2, the system first receives a resource transfer request for a transfer of resources from a first resource location associated with a first user to a second resource location associated with a second user. For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like).” The software platforms are disparate as taught in par 039: “The user application 124, the dynamic resource transfer application 154, and the financial institution application 186 are for instructing the processing devices on their respective systems to perform various steps of the methods discussed herein, and/or other steps and/or similar steps. In various embodiments, one or more of the various applications discussed are included in the computer readable instructions stored in a memory device of one or more systems or devices other than their respective systems and/or devices. For example, in some embodiments, the dynamic resource transfer application 154 is stored and configured for being accessed by a processing device of the financial institution system 170 connected to the network 102. In various embodiments, the user application 124, the dynamic resource transfer application 154, and the financial institution application 186 are stored and executed by different systems/devices.” The software platforms are taught by item 154, 124, and 186, and are disparate because they are stored and executed by different systems/devices. Further these are non-integrated because in light of Applicant’s specification disparate or non-integrated are synonymous terms, see par 0130: “disparate or non-integrated.” Disparate also means different according the Applicant’s specification: “different and/or disparate.”
Per claim 8, specifically, Kurian teaches computing device, comprising: one or more processors; and computer storage memory having computer-executable instructions stored thereon which, when executed by the processor, implement a method comprising in par 042: “in par 042: “Initially, at block 210 of FIG. 2, the system first receives a resource transfer request for a transfer of resources from a first resource location associated with a first user to a second resource location associated with a second user. For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like)”
Per claim 15, specifically, Kurian teaches Computer storage media having computer-executable instructions stored thereon which, when executed by a processor, implement a method comprising in par 042: “in par 042: “Initially, at block 210 of FIG. 2, the system first receives a resource transfer request for a transfer of resources from a first resource location associated with a first user to a second resource location associated with a second user. For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like).”
See par 065: “It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, infrared, electromagnetic, and/or semiconductor system, apparatus, and/or device. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as a propagation signal including computer-executable program code portions embodied therein.”
Then, Kurian teaches obtaining a candidate modification parameter indicating a candidate modification to apply to an event associated with the plurality of disparate software platforms, wherein a first software platform, a second software platform, and a third software platform of the plurality of disparate software platforms do not integrate with each other; in par 042: “Initially, at block 210 of FIG. 2, the system first receives a resource transfer request for a transfer of resources from a first resource location associated with a first user to a second resource location associated with a second user. For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like).” The software platforms are disparate as taught in par 039: “The user application 124, the dynamic resource transfer application 154, and the financial institution application 186 are for instructing the processing devices on their respective systems to perform various steps of the methods discussed herein, and/or other steps and/or similar steps. In various embodiments, one or more of the various applications discussed are included in the computer readable instructions stored in a memory device of one or more systems or devices other than their respective systems and/or devices. For example, in some embodiments, the dynamic resource transfer application 154 is stored and configured for being accessed by a processing device of the financial institution system 170 connected to the network 102. In various embodiments, the user application 124, the dynamic resource transfer application 154, and the financial institution application 186 are stored and executed by different systems/devices.” The software platforms are taught by item 154, 124, and 186, and are disparate because they are stored and executed by different systems/devices. Further these are non-integrated because in light of Applicant’s specification disparate or non-integrated are synonymous terms, see par 0130: “disparate or non-integrated.” Disparate also means different according the Applicant’s specification: “different and/or disparate.” Under a broadest reasonable interpretation of the claims in light of the specification, because the three different software platforms are on three different devices, they are not integrated with each other. This is because non-integrated is synonymous with disparate in Applicant’s specification and is not otherwise defined.
Then, Kurian teaches in response to obtaining the candidate modification parameter, and based on the candidate modification parameter and a set of resource parameters, determining a resource collection, from among a plurality of resource collections, to support the event in par 044: “The resource transfer request may comprise a specified resource (e.g., a specific good or service) requested by the requesting user. In some embodiments, the resource transfer request may further comprise resource or product data associated with a requested resource (e.g., UPC, SKU, barcode, resource description or identifier, or the like). The resource transfer request may further comprise data associated with the requesting user, such as a geographic location (e.g., address, area code, or the like), contact information (e.g., name, phone number, email address, business card), an offer for payment or a bid, or financial information (e.g., credit/debit card information, banking account information, a digital check, a generated payment token, financial account information, or other payment or payment routing information).” banking account information, a generated payment token, financial account information, teaches a resource collection (an account, as it is determined.
Then, Kurian teaches determining a modification to the event based on the candidate modification parameter and the resource collection in par 046: “At block 220 of FIG. 2, the system next determines a resource deficiency associated with the first user after receiving the resource transfer request. As used herein, a “resource deficiency” may refer to a lack of insufficient amount of resources associated with a user, wherein the user does not have a sufficient amount of resources needed to complete a requested resource transfer or transaction. The system may determine a resource deficiency by accessing or retrieving information or data from one or more resource locations associated with a user. For example, upon receiving a resource transfer request for $1000 from a first user, the system may access one or more resource locations (i.e., accounts) associated with the first user and determine that the one or more resource locations associated with the first user only contain $800.”
Then, Kurian teaches determining a timeframe for resource transfer based on a time-dependent variable specific to the event in par 047: “In some embodiments, the system may monitor one or more resource locations, historical resource transfers, and/or scheduled or regular resource transfers (e.g., scheduled bill payments, rent, subscription charges, automatic income deposits, and the like) associated with a user to determine a resource deficiency. The system may further use the monitored information to predict a future resource deficiency that would result from completion of a requested resource transfer. For example, upon receiving a resource transfer request for $1000 from a first user, while a first resource location associated with the first user may contain $1200, the system may determine a predicted resource deficiency based on identifying a regular payment of $300 that is scheduled to be paid on the same day.”
Then, Kurian teaches and initiating an event modification indicative of a transfer of resources by instructing at least one resource management software to modify event data associated with the event across the plurality of disparate software platforms within the timeframe for the resource transfer, wherein modifying the event data comprises, based on the event and within the timeframe, modifying within the timeframe in par 049: “At block 230 of FIG. 2, the system triggers construction of a resource transfer program for completion of the resource transfer request in response to determining the resource deficiency. As used herein, a “resource transfer program” may refer to a program or plan to allow for completion of a resource transfer despite a determined resource deficiency. A resource transfer program may be a loan of resources provided by an entity (e.g., a financial institution) to a requesting user that does not have sufficient funds (i.e., a resource deficiency) to complete a transfer of resources without assistance. In some embodiments, a loaned resource amount may be provided to a user by a financial institution associated with the user.” See also par 049: “In some embodiments, the system continuously matches the user profile with the product profiles and loan profiles in order to provide an accurate, optimized resource transfer program (i.e., a loan) to the user on demand in real-time that reflects the most current information. In this way, a resource transfer program may be provided to the user quickly and efficiently within the time frame of the user initiating a transaction or requesting a resource transfer.” Within the timeframe is taught in par 0049: “In this way, a resource transfer program may be provided to the user quickly and efficiently within the time frame of the user initiating a transaction or requesting a resource transfer.”
Then, Kurian teaches a first data field accessible to a first software platform of the plurality of disparate software platforms and associated with a first entity owing a specific obligation to a second entity and associated with the specific obligation in par 052: “At block 240 of FIG. 2, the system transfers the first resource from the first resource location to the second resource location based on the resource transfer program approved by the user. In some embodiments transfer of the first resource initially request by the user completes the resource transfer request of the user. In some embodiments, receiving the user's approval of the resource transfer program triggers the transfer of resources from a first resource location associated with the user to a second resource location associate with a second user (i.e., a merchant). The system receives or withdraws the first resource from the first resource location associated with the first user and transfers the first resource to the second resource location.” Accessible to a first software platform is taught in par 051: “In some embodiments, the system generates one or more documents (terms and conditions description, signature documents, insurance documents, and the like) necessary for approval and completion of the resource transfer program. The system may automatically generate the one or more documents and transmit the documents to a user device associated with the user or a user device involved in the resource transfer (e.g., a POS device), wherein the documents may be displayed to the user for approval.” The documents are on the user device teaching accessible to a the software platform (of the user device)
Then, Kurian teaches a second data field accessible to a second software platform of the plurality of disparate software platforms and associated with the specific obligation and associated with the second entity in par 052: “The system receives or withdraws the first resource from the first resource location associated with the first user and transfers the first resource to the second resource location, wherein system transfers or deposits the first resource to a resource storage location (e.g., an account, e-wallet, or the like) associated with the second user. The deposit of the first resource may be an immediate electronic transfer of funds between accounts. In some embodiments, the system may display a notification to at least one of the first and second users that the transfer of resources was completed.” The second data field accessible to the software platform is taught in par 052 where funds are transferred to the e-wallet of a merchant, which is accessible (field – how many funds) to the second software platform (e-wallet): “In some embodiments, receiving the user's approval of the resource transfer program triggers the transfer of resources from a first resource location associated with the user to a second resource location associate with a second user (i.e., a merchant). The system receives or withdraws the first resource from the first resource location associated with the first user and transfers the first resource to the second resource location, wherein system transfers or deposits the first resource to a resource storage location (e.g., an account, e-wallet, or the like) associated with the second user. The deposit of the first resource may be an immediate electronic transfer of funds between accounts. In some embodiments, the system may display a notification to at least one of the first and second users that the transfer of resources was completed.”
Then, Kurian teaches and a third data field accessible to a third software platform of the plurality of disparate software platforms and associated with the specific obligation and associated with a third entity covering at least a portion of the specific obligation on behalf of the first entity in par 054: “In block 330 of FIG. 3, the system transfers the first resource from a third resource location (i.e., the financial institution) with sufficient resources to the first resource location based on the constructed resource transfer program. In this embodiment of the invention, an entity (e.g., a financial institution) provides or loans at least a portion of the requested first resource amount to the first user for completion of the resource transfer request. In some embodiments, the entity that provides the first resource amount to the first user may not be a financial institution associated with the user. In some embodiments, the system may transfer the first resource directly from the third resource location associated with the financial institution to the second resource location associated with the second user (i.e., a merchant), wherein the financial institution directly completes the requested transaction or transfer of resources instead of the resources first passing through the first resource location associated with the first user.” That a third data field where the entity covers at least a portion of the specific obligation on behalf of the first entity is accessible to a third software platform is taught in par 042 where “the system” is the third platform: “Initially, at block 210 of FIG. 2, the system first receives a resource transfer request for a transfer of resources from a first resource location associated with a first user to a second resource location associated with a second user. For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like).”
Kurian does not teach based on…the first, second, and third software platforms not integrating with each other.
Lee teaches a transaction exchange platform which receives transactions from sources through workflows and microservices. See abstract.
Lee teaches based on…the first, second, and third software platforms not integrating with each other in col 5 ln 36-48: “A transaction exchange platform, according to one or more aspects discussed herein, may provide a version agnostic data streaming, reactive microservice solution that facilitates payment related workflows to be executed. Although the term “microservice” is used throughout this disclosure, aspects are not limited to “microservices” as used in cloud computing contexts. Generally, as used herein “microservice” may refer to a technology process that does work on an object on a streaming data platform in any given step of a workflow. Aspects discussed herein may refer to “approval” of transactions. This generally refers to the processing necessary to move a transaction through the transaction exchange platform from intake to output,” That first, second, and third platforms are not integrated with each other and that the modification is based on this is taught in Fig 2 and col 7 ln 56 – col 8 ln 58. The items in Fig 2 include item 205, an originations source, which may be presenting a card at a POS. Then, settlement, which is the respective financial institutions. Then, clearing, which provide various support for the transactions, for example regulatory. These are not integrated systems as Item 210 is the interface for the transactions, which teaches under a broadest reasonable interpretation “non-integrating” systems, which necessitate an interface in order to interact. The version agnostic data streaming previously taught means that event data is modified based on non-integrated systems, under a broadest reasonable interpretation in light of the specification. See col 9 ln 45 – col 10 ln 14. This text, including the transaction object, is modified based on systems that are non integrating such that the systems will be able to pass the information or modify the information (as is taught in col 10 ln 10-15) between each other.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the resource transfer limitations of Kurian with the based on first-third software platforms non-integrating teaching of Lee because Lee teaches
Different transaction types may be subject to different approval workflows. Payment processing systems may be configured to perform the required approval steps for each different transaction type. Yet such payment processing systems have become incredibly complex, monolithic software services designed to accommodate and enforce the many aspects of the process of reviewing and approving a transaction for settlement. Although sometimes divided into modules corresponding to different transactions, changes to single steps in a given transaction's approval workflow may require re-coding, re-compiling, and re-deploying large software components. Additionally, problems with individual steps of the workflows can grind the whole approval process to a halt.
Aspects described herein may address these and other shortcomings present in existing solutions. Novel aspects discussed herein may implement a transaction exchange platform using a streaming data platform and microservices to provide faster, more dynamic, and more robust processing and approval of transactions. The novel transaction exchange platform may provide benefits such as improving the flexibility and reliability of transaction approval and processing systems, while offering robust record keeping for transaction audit purposes. The novel platform may also provide other benefits such as support for legacy and ongoing operations, solving for new and changing requirements in today's environment, and adapting to future technologies
Col 1 ln 45 – col 2 ln 5.
As Lee addresses a problem in the art of requiring re-coding, re-compiling, and re-deploying large software components, one would be motivated to combine Lee with Kurian to overcome this and allow for flexibility in transaction approval and processing systems without taking those steps. This would motivate one ordinarily skilled in the art to modify Kurian with Lee.
Per claim 2, Kurian and Lee teach the limitations of claim 1, above. Kurian further teaches wherein the candidate modification parameter comprises a resource indicator that represents an amount of resources to be transferred or a scheduled time or time range for a resource transfer in association with the event in par 054: “In block 330 of FIG. 3, the system transfers the first resource from a third resource location (i.e., the financial institution) with sufficient resources to the first resource location based on the constructed resource transfer program. In this embodiment of the invention, an entity (e.g., a financial institution) provides or loans at least a portion of the requested first resource amount to the first user for completion of the resource transfer request. In some embodiments, the entity that provides the first resource amount to the first user may not be a financial institution associated with the user. In some embodiments, the system may transfer the first resource directly from the third resource location associated with the financial institution to the second resource location associated with the second user (i.e., a merchant), wherein the financial institution directly completes the requested transaction or transfer of resources instead of the resources first passing through the first resource location associated with the first user. In some embodiments, the second user (i.e., the merchant) may simply receive payment and not be aware of the resource transfer program or loan.” See par 047 for time or time range.
Per claim 3, Kurian and Lee teach the limitations of claim 1, above. Kurian further teaches wherein the candidate modification parameter is provided via a destination entity that is to receive a resource transfer in association with the event in par 042: “For example, a first user (i.e., a customer) may be requesting completion of a transaction at a merchant location with a second user (i.e., the merchant) and may request for a transfer of funds from an account associated with the first user to an account associated with the merchant. In some embodiments, the request is received by the system in response to the initiation of a transaction. A transaction may be initiated, for example, via a user device associated with the first (e.g., a mobile device, computer, or the like) or a user device associated with the second user (e.g., a point of sale device, mobile device, or the like). In some embodiments, initiation of a transaction and request for a resource transfer triggers a sending of the request to an entity (e.g., a financial institution) associated with the requesting user's account.”
Per claim 4, Kurian and Lee teach the limitations of claim 1, above. Kurian further teaches the plurality of resource collections correspond with (1) a source entity that provides a resource transfer in association with the event or (2) a third-party entity that is willing to provide the resource transfer on behalf of the source entity, wherein the first entity comprises the source entity and wherein the third entity comprises the third-party entity in par 054: “In block 330 of FIG. 3, the system transfers the first resource from a third resource location (i.e., the financial institution) with sufficient resources to the first resource location based on the constructed resource transfer program. In this embodiment of the invention, an entity (e.g., a financial institution) provides or loans at least a portion of the requested first resource amount to the first user for completion of the resource transfer request. In some embodiments, the entity that provides the first resource amount to the first user may not be a financial institution associated with the user. In some embodiments, the system may transfer the first resource directly from the third resource location associated with the financial institution to the second resource location associated with the second user (i.e., a merchant), wherein the financial institution directly completes the requested transaction or transfer of resources instead of the resources first passing through the first resource location associated with the first user. In some embodiments, the second user (i.e., the merchant) may simply receive payment and not be aware of the resource transfer program or loan.” See also par 050: “For example, a teenager may be attempting to obtain a loan to purchase a car and have his or her parent assist in acquiring the loan to obtain more attractive terms and conditions. In some embodiments, the system may combine contributions from each user into a single contribution (e.g., a down payment, a payment in a payment plan, or the like) as far as a recipient user (i.e., the s