Detailed Action
Applicant amended claims 1-4, 6-9, 11-15 and 17-20 and presented claims 1-20 for reconsideration on 06/10/2026.
Claim Objections
Claims 5, 10 and 16 are objected to regarding the following informalities.
The Claims are labeled as “Currently Amended”. However, the claims are original.
Examiner's Notes
The Examiner cites sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 102 that forms the basis for all the rejections under this section made in this Office Action:
A person shall be entitled to a patent unless—
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 9, 11-16 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by McLACHLAN et al., Pub. No.: US 2021/0096886 A1 (McLACHLAN).
McLACHLAN teaches:
Claim 1. A computing system comprising: a communications module; a processor coupled to the communications module; and a memory coupled to the processor storing instructions that, when executed by the computing system, cause the computing system to:
provide a selectable option to request separation of a transfer into a plurality of parts to a transferor device; (McLACHLAN, ¶ 238, a user device, e.g., a transferor device displays an option for the user to select an installment plan for a payment transaction: “purchase confirmation user interface 802, which is displayed to provide a user interface to allow a user to initiate a transfer to acquire ( e.g., purchase) an item …the purchase (e.g., transfer) is broken into two payment transactions ( e.g., transfers)… The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full”)
receive, via the selectable option, a request to separate the transfer into the plurality of parts and obtaining a total amount and a total time period for the request; (McLACHLAN, ¶ 238, an installment plan separates a payment transaction into several portions to be paid gradually: “The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full”)
prepare a plurality of request- for- transfer links, each of the request- for- transfer links associated with a respective transfer time period, wherein each of the respective transfer time periods are less than or equal to the total time period, each of the request- for- transfer links associated with a respective transfer part amount, wherein a summation of the respective transfer part amounts is equal to the total amount; and (McLACHLAN, a payment portion is prepared as a request- for- transfer link associated with certain time and amount; each scheduled payment portion information is transferred to the user device enabling the user to pay the portion as scheduled or early using a provided link: ¶ 238, “The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full”, ¶ 246, “The installment balance of $511 corresponds to the balance of the installment plan upon purchase of the item in FIG. 8A. The user interface in FIG. 8D is shown on Dec. 25, 2019. Thus, FIG. 8D shows the card balance and installment balance before the first installment for the installment plan is charged to the transfer account, which is scheduled to occur on December 31, as indicated in FIGS. 8A and 8B”, ¶ 248, “balance transfer user interface element 816 includes an indicator 816A indicating ( e.g., with text such as "pay," "pay early," "pay more," and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made). In FIG. 8D, indicator 816A displays "pay early," indicating that a balance transfer ( e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due”, ¶ 340, “the first transfer is an installment transaction (e.g., 820D) in an installment plan (e.g., a transaction (e.g., financial transaction) in a series of transactions that are scheduled to be settled in repeating installments over a number of cycle periods (e.g., monthly) until the installment plan purchase (e.g., debt) is settled in full)”)
provide the plurality of request- for- transfer links to the transferor device, each of the request- for- transfer links allowing the transfer to fulfill the respective transfer part amount to be performed. (McLACHLAN, see above, the user can use a link on the user device, e.g., the transferor device to pay a portion of a payment: ¶ 248, “balance transfer user interface element 816 includes an indicator 816A indicating ( e.g., with text such as "pay," "pay early," "pay more," and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made). In FIG. 8D, indicator 816A displays "pay early," indicating that a balance transfer ( e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due”)
Claim 12 is rejected under the same rationale as above.
Claim 2. The computing system of claim 1, wherein each of the request-for-transfer links allows the transfer to fulfill a separate transfer part amount to be performed without requiring input of one or both of the respective transfer part amount or recipient information. (McLACHLAN, user can pay a scheduled amount using provided link for activation of the payment without requiring input of one or both of the respective transfer part amount or recipient information: ¶ 246, “FIG. 8D shows the card balance and installment balance before the first installment for the installment plan is charged to the transfer account, which is scheduled to occur on December 31, as indicated in FIGS. 8A and 8B”, ¶ 248, “balance transfer user interface element 816 includes an indicator 816A indicating ( e.g., with text such as "pay," "pay early," "pay more," and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made). In FIG. 8D, indicator 816A displays "pay early," indicating that a balance transfer ( e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due”, ¶ 340, “the first transfer is an installment transaction (e.g., 820D) in an installment plan (e.g., a transaction (e.g., financial transaction) in a series of transactions that are scheduled to be settled in repeating installments over a number of cycle periods (e.g., monthly) until the installment plan purchase (e.g., debt) is settled in full)”; ¶ 430)
Claim 13 is rejected under the same rationale as above.
Claim 3. The computing system of claim 1, wherein a plurality of the respective transfer part amounts is equal. (McLACHLAN, ¶ 238, “The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full”)
Claim 14 is rejected under the same rationale as above.
Claim 4. The computing system of claim 1, wherein each of the request-for-transfer links is only valid during the respective transfer time period for that request- for- transfer link. (McLACHLAN, each scheduled payment happens in certain time and can be paid early before certain time: ¶ 246, “FIG. 8D shows the card balance and installment balance before the first installment for the installment plan is charged to the transfer account, which is scheduled to occur on December 31, as indicated in FIGS. 8A and 8B”, ¶ 248, “balance transfer user interface element 816 includes an indicator 816A indicating ( e.g., with text such as "pay," "pay early," "pay more," and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made). In FIG. 8D, indicator 816A displays "pay early," indicating that a balance transfer ( e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due”, ¶ 340, “the first transfer is an installment transaction (e.g., 820D) in an installment plan (e.g., a transaction (e.g., financial transaction) in a series of transactions that are scheduled to be settled in repeating installments over a number of cycle periods (e.g., monthly) until the installment plan purchase (e.g., debt) is settled in full)”; ¶ 430)
Claim 15 is rejected under the same rationale as above.
Claim 5. The computing system of claim 4, wherein the instructions further cause the computing system to determine the total time period based on a final transfer due date for the transfer. (McLACHLAN, total time period is determined based on the plan: ¶¶ 238, 340, “the first transfer is an installment transaction (e.g., 820D) in an installment plan (e.g., a transaction (e.g., financial transaction) in a series of transactions that are scheduled to be settled in repeating installments over a number of cycle periods (e.g., monthly) until the installment plan purchase (e.g., debt) is settled in full)”)
Claim 16 is rejected under the same rationale as above.
Claim 9. The computing system of claim 1, wherein the transfer transfers value from a transferor account to a recipient account. (McLACHLAN, wherein a payment is a value paid from an account associated with the user to a recipient account: ¶ 243, “virtual wallet user interface 805 includes representations of different accounts provisioned on the electronic device, including: different transfer accounts (e.g., payment accounts, such as a third-party credit card account, a debit card account, and/or a stored-value account; points accounts; rewards accounts), first-party manufacturer-issued ( or branded) stored-value accounts, and other accounts ( e.g., other transfer accounts, points cards, rewards cards), ID cards ( e.g., student ID, government-issued ID), and/or tickets (e.g., event ticket, boarding pass ticket) provisioned on or linked to electronic device 100”, ¶ 294, “account details user interface 863 displays details regarding the transfer account such as, for example, an option for viewing a virtual card number associated with the transfer account, billing address information, an option for contacting a bank associated with the transfer account, and option 865 for viewing installment plans associated with the transfer account. In some embodiments, option 865 includes an indication of the number of installment plans associated with the transfer account”)
Claim 20 is rejected under the same rationale as above.
Claim 11. The computing system of claim 1, wherein prior to preparing the plurality of request-for-transfer links, the instructions, when executed by the computing system, further cause the computing system to: validate the request to separate the transfer into the plurality of parts. (McLACHLAN, a user account is verified for each purchase: ¶¶ 204-205, “each user account includes payment information… a payment is denied when provided payment information is not consistent…or when no account includes payment information matching that from the POS communication… data for the user account further identifies one or more restrictions ( e.g., credit limits); current or previous balances; previous transaction dates, locations, and/or amounts; account status (e.g., active or) frozen); and/or authorization instructions…the payment server (e.g., 604) uses such data to determine whether to authorize a payment. For example, a payment server denies a payment when a purchase amount added to a current balance would result in exceeding an account limit, when an account is frozen, when a previous transaction amount exceeds a threshold, or when a previous transaction count or frequency exceeds a threshold”)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
Claims 6-8 and 17-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over McLACHLAN as applied to claims 1 and 12 above, in view of Examiner's Official Notice.
Claim 6 recites: The computing system of claim 1, wherein the plurality of request-for-transfer links are provided to the transferor device at once.
Claim 7 recites: The computing system of claim 1, wherein the plurality of request-for-transfer links are provided to the transferor device separately at defined times.
Claim 8 recites: The computing system of claim 7, wherein each of the plurality of request-for-transfer links are sent to the device at or near an end of the respective transfer time period associated with a request-for-transfer links.
The examiner takes official notice that whether the requests for transfer links are provided at once, separately or at near due date depends on a plan agreement or a design choice for enabling a user to pay an installment amount as agreed. For example, a user in McLACHLAN is able to pay an amount of a purchase in full, in certain time as planned or early toward the account balance before the due date: ¶ 238, “purchase confirmation user interface 802, which is displayed to provide a user interface to allow a user to initiate a transfer to acquire ( e.g., purchase) an item …the purchase (e.g., transfer) is broken into two payment transactions ( e.g., transfers). The first payment transaction is a standard payment transaction in which a first portion of the purchase is satisfied by immediate ( or nearly immediate) payment ( e.g., via transfer of credit) via the transfer account (e.g., the first portion is charged/billed/etc. to the transfer account)…The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full”, ¶ 248, “In some embodiments, balance transfer user interface element 816 includes an indicator 816A indicating ( e.g., with text such as "pay," "pay early," "pay more," and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made)… indicator 816A displays "pay early," indicating that a balance transfer ( e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due”. Therefore, it would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to modify McLACHLAN by sending links to a device at once, separately at defined times or at or near an end of the respective transfer time period associated with the request for transfer link based on an agreed plan as desired for enabling payment of an installed amount as disclosed by McLACHLAN.
Claims 17-19 are rejected under the same rationale as above.
Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over McLACHLAN as applied to claim 1 above, in view of Prabhu, Pub. No.: US 2020/0219098 A1 (Prabhu).
Claim 10. McLACHLAN taught the computing system of claim 1; McLACHLAN did not specifically teach but Prabhu teaches wherein the selectable option includes an option to define the total time period. (Prabhu, ¶¶ 132-133, wherein a user is able “to choose 3, 6, or 9-month installment payments for the electronic service application for converting a transaction amount into multiple monthly installment payments”)
It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing wherein the selectable option includes an option to define the total time period because doing so would provide for a user to select a desirable total time period.
Response to Amendment and Arguments
Applicant filed electronic terminal disclaimer on 06/10/2026. Double patenting rejections are withdrawn.
Applicant’s arguments with respect to rejected claims have been considered but are not persuasive for the following reason.
With respect to claim 1, Applicant argues: “McLachlan expressly describes this as a system in which the purchase "is broken into two payment transactions ... The second payment transaction is an installment plan in which the installed portion of the purchase (e.g., a financed amount) is satisfied by an accumulation of equal portions of the installed (e.g., financed) amount of the purchase that are satisfied on a repeating (e.g., monthly) basis until the installed balance is satisfied in-full." McLachlan, ¶ [0238]. There is no recipient-side computing system preparing and sending links to a transferor. There is no disclosure of a transferor device receiving actionable links. There is no disclosure of an inter-institutional transfer architecture involving a separate transferor and recipient financial institution. The installments in McLachlan are not fulfilled by the transferor activating a link, but rather, the installments are processed automatically without any affirmative act by the user…McLachlan contains no disclosure of "a plurality of request-for-transfer links" of any kind. The Examiner's assertion that "each payment transaction is a transfer link" is an unsupported conclusory statement that fundamentally rewrites the disclosure of McLachlan. A scheduled automatic charge to a credit account is not a "request-for-transfer link" as claimed. McLachlan discloses an automated billing event that requires no action by the transferor and involves no link being prepared, transmitted, or activated. The Examiner has not identified any passage in McLachlan that discloses the preparation or provision of discrete, actionable links corresponding to individual transfer parts, because no such disclosure exists.” Remarks, 8
In response:
Claim 1 does not recite “recipient-side…actionable links… an inter-institutional transfer architecture involving a separate transferor and recipient financial institution…”.
Claim 1 recites “a plurality of request-for-transfer links” wherein “each of the request-for-transfer links associated with a respective transfer time period, wherein each of the respective transfer time periods are less than or equal to the total time period, each of the request-for-transfer links associated with a respective transfer part amount, wherein a summation of the respective transfer part amounts is equal to the total amount” and further “each of the request-for-transfer links allowing the transfer to fulfill the respective transfer part amount to be performed” (emphasis added).
McLachlan provides for a user, using the user device, to pay an installed amount according to an installment plan wherein “each portion of the installed amount is referred to as an installment, and a transfer for satisfying an installment is referred to herein as an installment transfer or installment transaction”. A user, who is billed for an installed amount, can pay for an installment by utilizing a pay link and the pay link is a request-for-transfer link allowing the transfer to fulfill the respective transfer part amount to be performed. see, McLachlan, ¶¶ 238, 248, “balance transfer user interface element 816 includes an indicator 816A indicating (e.g., with text such as “pay,” “pay early,” “pay more,” and/or symbols such as a checkmark or an exclamation mark) a status of a balance transfer (e.g., whether a balance payment is currently due, whether a balance payment is urgently due, whether a balance payment has been made). In FIG. 8D, indicator 816A displays “pay early,” indicating that a balance transfer (e.g., payment towards the account balance) can be applied to the transfer account balance, but that a balance transfer is not currently due. Features concerning balance transfer user interface element 816 are described in greater detail below with reference to FIGS. 11A-11R”, ¶¶ 254, 274, 287, 421-422, “Because an installment transfer is included in the balance of the transfer account, summary user interface 810 is capable of initiating a process for paying at least a portion of the installment plan using, for example, balance transfer user interface element 816. For example, as shown in FIG. 11G, device 100 detects input 1126 on indicator 816A to initiate the process for making a balance transfer”. The device used by the user for paying an installment amount is the user device with an application and the application transmit information to a server associated with the application. See, ¶¶ 207, 275, 238, 430. Therefore, each interaction of the user with the application interface is transmitted to the server and the information generated by the server is transmitted to the user device: ¶ 275, “Installment details user interface 845 also includes installment payment user interface element, which is a selectable option to initiate a process for making additional payments towards the installment plan”. ¶ 430, “In FIG. 11L, device 100 detects input 1135 on installment payment user interface element 850 and, in response, initiates a process for making a balance transfer for the installment plan—that is, a process for making an early payment towards the balance of the installment plan. By default, portions of the installment plan are scheduled for payment on a recurring (e.g., monthly basis). However, the process for making an early payment towards the balance of the installment plan allows a user to payoff unbilled amounts of the installment plan (e.g., a balance of the installment plan that is not yet due for payment). In some embodiments, the installment balance (e.g., the portion of the installment plan that has not yet been billed or added to the transfer account balance) does not accrue interest, whereas the balance billed to the transfer account is capable of accruing interest. In some embodiments, device 100 therefore forces the user to pay off the interest-accruing balance of the transfer account, in order to make payments towards the interest-free installment balance. In some embodiments, initiating the process for making an early payment towards the installment balance includes optionally displaying a notification to the user informing them of the requirement to pay off the interest-accruing balance of the transfer account. An example of such a notification is shown in FIG. 11M (e.g., user interface 1136)”.
With respect to claim 1, Applicant argues, “A scheduled automatic charge to a credit account is not a "request-for-transfer link" as claimed. McLachlan discloses an automated billing event that requires no action by the transferor and involves no link being prepared, transmitted, or activated”. Remarks, 8.
In response, a payment portion is prepared as a request- for- transfer link associated with certain time and amount; each scheduled payment portion information is transferred to the user device enabling the user to pay the portion as scheduled or early using a provided link. See, McLachlan, ¶¶ 238, 246, 248, 340 for example.
With respect to claim 1, Applicant argues, “McLachlan does not teach providing links that allow a transfer to be performed without requiring input of recipient information. In McLachlan, there is no separate recipient as the entire transaction is self-contained within the user's own account at a single institution. The concept of pre-populating recipient information into a link as claimed is entirely foreign to McLachlan”. Remarks, 8.
In response, a transfer is performed by clicking a link. The amount to be paid is not populated by the user. See, McLachlan, ¶ 430.
With respect to claim 2, Applicant argues, “Para. 246 describes a balance summary user interface element that displays the current balance and installment balance of a user's own credit account. The passage merely describes an informational display of account data and has no bearing on the prepopulation of transfer amounts or recipient information into an actionable link. Para. 340 describes the automatic billing of installment transactions to a user's own credit account, which, as discussed above with respect to the independent claims, is an automated charge that requires no affirmative act by the user and involves no link of any kind. Neither passage discloses a link that pre-populates a transfer amount and recipient information to eliminate the need for the transferor to input such information. To the contrary, in McLachlan there is no recipient separate from the issuing institution, and accordingly the concept of pre-populating recipient information is entirely absent from McLachlan”. Remarks, 9.
In response: a balance summary is an indication that the user does not need to populate any data for paying an amount. Payments are scheduled based on the user agreement and further a user can pay an amount by clicking a link. The amount to be paid is not populated by the user. See, McLachlan, ¶¶ 248, 430.
With respect to claim 3, Applicant argues, “Applicant acknowledges that McLachlan discloses equal installment amounts in the context of its automatic credit account billing system. However, because McLachlan fails to disclose the foundational features of the independent claims, the disclosure of equal installment amounts cannot save the Examiner's rejection. The dependent claim features cannot supply missing elements of the independent claims from which they depend”. Remarks, 10.
In response, McLachlan discloses claim 1 as shown above. Furthermore, a user can pay an installment amount by clicking a link. See, McLachlan, ¶¶ 248, 430.
With respect to claim 4, Applicant argues, “The fact that an automatic installment charge is scheduled to occur on a particular date does not teach or suggest a link that is only valid during a defined transfer time period. As claimed, link validity is a distinct functional characteristic of the link itself in that the link is enabled only during its associated transfer time period and may expire thereafter…A scheduled automatic billing date is not a link validity time period but is simply a date on which an automatic charge occurs, entirely independent of any user action or link activation”. Remarks, 10.
In response, a user can utilize a link provided for an early payment, the link is valid for the amount that is not yet due for payment. See, McLachlan, ¶¶ 248, 430.
With respect to claim 5, , Applicant argues “Para. 340 of McLachlan describes a series of installment transactions scheduled to be settled in repeating installments until the installment plan is paid in full. This describes the duration of an automatically recurring billing cycle and it does not teach a computing system that receives a final transfer due date and uses that date to calculate and define a total time period over which a plurality of request-for-transfer links are to be distributed. As claimed, the total time period is derived from a specific final transfer due date communicated as part of the request to separate the transfer, for example as part of an invoice…McLachlan contains no such document-driven, due-date-based period calculation, as McLachlan's installment plan duration is defined entirely by the number of installments chosen at the point of sale, not by a final due date received from a separate recipient system”. Remarks, 11.
In response, an installment plan includes a final transfer due date based on terms of the installment plan. For example, “24 MONTHLY INSTALLMENTS STARTING DECEMBER 31” as illustrated in Fig. 8A, displays the equal portions of the installed amount for two years, meaning a final transfer due date is the last month of 24 monthly installments. Evidently, for a one-year installment plan, a final transfer due date is the last month of 12 monthly installments. See, McLachlan, ¶ 238.
With respect to claims 6-8, Applicant argues “Applicant challenges the propriety of the Examiner's reliance on Official Notice. Under MPEP § 2144.03, Official Notice is only appropriate where the noticed fact is "capable of instant and unquestionable demonstration as being well-known" and is not subject to reasonable dispute. The Examiner has taken Official Notice that providing request-for-transfer links at once, separately, or at or near due dates is merely a matter of design choice or plan agreement. However, the Examiner has provided no evidentiary basis for this assertion, and it is not a fact that is capable of instant and unquestionable demonstration. The specific context of the claims, (e.g., a recipient-side computing system preparing and distributing a plurality of request-for-transfer links to a transferor device in the context of an inter-institutional transfer architecture) is a specialized technical context for which the Examiner's bare design choice assertion is insufficient. Applicant hereby formally challenges the Official Notice taken by the Examiner and respectfully requests that the Examiner provide documentary evidence in support of this assertion, as is required under MPEP § 2144.03(a)…” Remarks, 13-15
In response, as noted above with respect to claim 1, there is no feature such as “a recipient-side computing system preparing and distributing a plurality of request-for-transfer links to a transferor device in the context of an inter-institutional transfer architecture”. McLachlan provides for a user, using the user device, to select an installment plan for paying an installed amount according to an installment plan. The user can pay an installed amount from a bank account associated with the user using a provided link. Providing 24 links to the user device for a 24 monthly installment at once, separately, at or near an end of the respective transfer time period associated with a link is only a matter of design choice because each provided link allowing the transfer to fulfill the respective transfer part amount to be performed as recited in claim 1 and the provided links, e.g., “pay”, “pay early” and “pay more” with respect to an installed amount in McLachlan allows the transfer to fulfill the respective transfer part amount to be performed. Therefore, a provided link can be used for a single installment amount, or multiple installments amounts by simply selecting a desired link. Furthermore, as noted above, the device used by the user for paying an installment amount is the device with an application and the application transmits information to a server associated with the application. See, ¶¶ 207, 275, 238, 430. Therefore, each interaction of the user with the application interface is transmitted to the server and the information generated by the server is transmitted to the user device: ¶ 275, “Installment details user interface 845 also includes installment payment user interface element, which is a selectable option to initiate a process for making additional payments towards the installment plan”. ¶ 430, “In FIG. 11L, device 100 detects input 1135 on installment payment user interface element 850 and, in response, initiates a process for making a balance transfer for the installment plan—that is, a process for making an early payment towards the balance of the installment plan. By default, portions of the installment plan are scheduled for payment on a recurring (e.g., monthly basis). However, the process for making an early payment towards the balance of the installment plan allows a user to payoff unbilled amounts of the installment plan (e.g., a balance of the installment plan that is not yet due for payment). In some embodiments, the installment balance (e.g., the portion of the installment plan that has not yet been billed or added to the transfer account balance) does not accrue interest, whereas the balance billed to the transfer account is capable of accruing interest. In some embodiments, device 100 therefore forces the user to pay off the interest-accruing balance of the transfer account, in order to make payments towards the interest-free installment balance. In some embodiments, initiating the process for making an early payment towards the installment balance includes optionally displaying a notification to the user informing them of the requirement to pay off the interest-accruing balance of the transfer account. An example of such a notification is shown in FIG. 11M (e.g., user interface 1136)”.
With respect to claim 9, Applicant argues “while McLachlan may involve transfers of value, the nature of the transfer in McLachlan is fundamentally different from that recited in the claims. In McLachlan, the transfer of value occurs entirely within a single institution. An installment amount is automatically charged to the user's own first-party credit account by the same institution that issued the account. There is no separate transferor account at one institution and recipient account at a different institution. By contrast, the claims contemplate a transfer of value from a transferor account maintained by one database management system to a recipient account maintained by a separate database management system, communicated over a transfer rail…McLachlan's single-institution, automatic credit billing mechanism does not teach or suggest this inter-institutional transfer of value between a distinct transferor account and recipient account.” Remarks, 11.
In response, the claim recites a transferor account and a recipient account. The claim does not recite “separate transferor account at one institution and recipient account at a different institution”. Nevertheless, a user account is a payment account associated with a bank for paying an installed amount. See McLachlan, ¶¶ 195-196, 243, 339.
With respect to claim 11, Applicant argues, “Nowhere does McLachlan teach a validation of a request to separate a transfer into a plurality of parts. As claimed, the validation step is specifically directed to evaluating whether the request to split a transfer into multiple parts should be approved, for example by conducting a credit check in connection with the transferor before generating and providing the plurality of request-for-transfer links”. Remarks, 12.
In response, a simple user credit check before processing a purchase is a validation process before splitting and processing a purchasing amount.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. It is suggested that the Applicant review these documents before submitting any amendments.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohsen Almani whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9 AM-5 PM, ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159
Prosecution Insights