DETAILED ACTION
This action is in response to the original filing on 10/17/2024. Claims 1-20 are pending and have been considered below.
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 .
Claim Objections
Claim 1, 10, 11, and 20 are objected to because of the following informalities:
Claims 1, 11, and 20 recite ‘the end user computing device’; however, they should recite - - an end user computing device - -.
Claim 10 recites ‘the operation’; however, it should recite - - an operation - -.
Claim 11 recites ‘(i) the interface assembly instructions’; however, it should recite - - (i) interface assembly instructions - -.
Appropriate correction is required.
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.
Claims 1-20 are 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.
Regarding claims 1 and 11, the recites “transmit a command to a first remote network that implements a first remote connection”. It is unclear whether “that implements a first remote connection” is intended to modify the command or the first remote network. For the purposes of examination, this limitation is interpreted as: transmit a command to a first remote network and implement a first remote connection
Claim 11 further recites “each of the remote networks”. The claim does not previously recite “remote networks” and it is unclear how this limitation is intended to relate to “a remote network” and “a first remote network”. For the purposes of examination, this limitation is interpreted as: each of a plurality of remote networks
Regarding claim 20, claim 20 recites “a transfer destination identification for a remote network that implements a remote connection” and “a command to the remote network that implements the remote connection”. It is unclear whether “that implements a first remote connection” is intended to modify the destination, the remote network, or the command. For the purposes of examination, this limitation is interpreted as: a transfer destination identification for a remote network and implement a remote connection, a command to the remote network and implement the remote connection
Regarding claims 2-10 and 12-19, the claims are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for depending on an indefinite parent claim.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1, 11-14, and 16-19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7, 9, and 18 of application 18918651 in view of Srihari et al. (US 20240320644 A1, published 09/26/2024), hereinafter Srihari. Although the claims at issue are not identical, they are not patentably distinct from each other because:
18918628 (Instant Application)
18918651
Claim 1): 1. A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
Claim 18) A system for operating remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
(a) generate interface assembly instructions, wherein the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data;
(d) generate interface assembly instructions that comprise a plurality of transfer destination identifications, control components, and remote connection transfer data, wherein (i) the control components comprise a cancel function, a modify plan function, and an activity function, (ii) the control components are configured for selection by an end user, and
(b) send the interface assembly instructions to an end user computing device, wherein (i) the interface assembly instructions generate a Remote Connection graphical user interface (GUI) when the interface assembly instructions are executed by the end user computing device, and (ii) the Remote Connection GUI displays the transfer destination identifications, the control components, and the remote connection transfer data; and
(iii) the interface assembly instructions are transmitted to an end user computing device;
(c) when the end user selects a control component, transmit a command to a first remote network that implements a first remote connection, wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI.
(e) receive a command in response to the end user selecting a control component; (f) transmit the command to a first remote network.
Claim 11) A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
Claim 1) A system for operating remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
(a) execute stored interface assembly instructions, wherein (i) the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data, (ii) executing the interface assembly instructions generates a Remote Connection graphical user interface (GUI), and (iii) the Remote Connection GUI displays the plurality of transfer destination identifications, the control components, and the remote connection transfer data;
(b) establish a secure communication session with each of the remote networks without requiring the end user to input security data to the end user computing device;
(b) establish a secure communication session with each of the remote networks; and
and (c) when the end user selects a control component, transmit a command to a first remote network that implements a first remote connection,
wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI.
(c) transmit a command to a first remote network that implements a first remote connection in response to the selection of a function control component,
wherein the command (i) modifies remote connection data stored to the first remote network, or (ii) causes the first remote network to return remote connection data that is incorporated into interface assembly instructions transmitted to the end user computing device to generate a user interface for display.
Claim 12) wherein: (a) the command is a cancel function; and (b) the first remote network processes the cancel function to terminate the first remote connection.
Claim 2) wherein: (a) the command is a cancel function; and (b) the first remote network processes the cancel function to terminate the first remote connection
Claim 13) wherein: (a) the command is a modify plan function; and (b) the first remote network processes the modify plan function to modify remote connection data by modifying a subscription level, wherein modifying the subscription level reduces resource utilization through the first remote connection
Claim 3) wherein: (a) the command is a modify plan function; and (b) the first remote network processes the modify plan function to modify remote connection data by modifying a subscription level, wherein modifying the subscription level reduces resource utilization through the first remote connection
Claim 14) wherein: (a) the command is an activity function; and (b) the first remote network processes the activity function to return remote connection transfer data according to an end user selection
Claim 4) wherein: (a) the command is an activity function; and (b) the first remote network processes the activity function to return remote connection transfer data according to an end user selection
Claim 16) wherein: (a) the system further comprises a neural network; (b) the neural network performs an operation to determine the transfer destination identifications by processing transfer activity data to recognize transfers conducted through a remote connection
Claim 6) wherein: (a) the system further comprises a neural network; and (b) the neural network performs the operation to determine that transfer activity data comprises transfers conducted through a plurality of remote connections.
Claim 17) wherein the neural network comprises an architecture selected from one of a convolutional neural network architecture, Long short-term memory network architecture, or a recurrent network architecture
Claim 7) wherein the neural network comprises an architecture selected from one of a convolutional neural network architecture, Long short-term memory network architecture, or a recurrent network architecture
Claim 18) wherein the system comprises a Remote Connection application programming interface (API) that converts the command to a format that complies with a communication protocol utilized by the first remote network
Claim 5) wherein the system comprises a Remote Connection application programming interface (API) that converts the command to a format that complies with a communication protocol utilized by the first remote network
Claim 19) wherein (a) the interface assembly instructions further comprise a classification code; and (b) the Remote Connection graphical user interface (GUI) displays a remote connection classification based on the classification code
Claim 9) wherein: (a) the processor executes a further operation to classify the first remote connection to generate a classification code; and (b) the classification code is transmitted to an end user computing device for display
Regarding claim 1, in the same field of endeavor, Srihari teaches wherein (i) the interface assembly instructions generate a Remote Connection graphical user interface (GUI) when the interface assembly instructions are executed by the end user computing device, and (ii) the Remote Connection GUI displays the transfer destination identifications, the control components, and the remote connection transfer data (Srihari Figs. 1-11; [0045-0049], [0062-0066], [0070-0077]) and wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI (Srihari Figs. 1-11; [0070], [0077-0078], [0081-0091], [0095]). It would have been obvious to one of ordinary skill in the art at the time the invention was made to have incorporated wherein (i) the interface assembly instructions generate a Remote Connection graphical user interface (GUI) when the interface assembly instructions are executed by the end user computing device, and (ii) the Remote Connection GUI displays the transfer destination identifications, the control components, and the remote connection transfer data and wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI as suggested in Srihari. Doing so would be desirable because many subscription services can be updated or cancelled online by a user, with a web browser, going to a merchant's web site and logging in and navigating through several pages to in order to update or cancel their service. The increasing number of these services may contribute to an increase in situations in which a user loses track of the services to which that user is subscribed. For example, 1 in 3 users aged 25-54 have six or more subscription services (see Srihari [0002]). As a result, users may end up inadvertently spending significant amounts of money in the form of unwanted subscription charges that are paid on a recurring basis. Not surprisingly, nearly half of users do not know the exact amount of money they are spending on subscriptions. However, to manage these unwanted services, a user may take the steps of canceling the service or altering their services via calling a customer service center or logging into the merchant's web site. Such methods of cancelling or updating a service can be time consuming, and require the user to know what services they have (see Srihari [0003]).
Regarding claim 11, in the same field of endeavor, Srihari teaches (a) execute stored interface assembly instructions, wherein (i) the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data, (ii) executing the interface assembly instructions generates a Remote Connection graphical user interface (GUI), and (iii) the Remote Connection GUI displays the plurality of transfer destination identifications, the control components, and the remote connection transfer data (Srihari Figs. 1-11; [0045-0049], [0062-0066], [0070-0077], [0081-0091]). It would have been obvious to one of ordinary skill in the art at the time the invention was made to have incorporated (a) execute stored interface assembly instructions, wherein (i) the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data, (ii) executing the interface assembly instructions generates a Remote Connection graphical user interface (GUI), and (iii) the Remote Connection GUI displays the plurality of transfer destination identifications, the control components, and the remote connection transfer data as suggested in Srihari. Doing so would be desirable because many subscription services can be updated or cancelled online by a user, with a web browser, going to a merchant's web site and logging in and navigating through several pages to in order to update or cancel their service. The increasing number of these services may contribute to an increase in situations in which a user loses track of the services to which that user is subscribed. For example, 1 in 3 users aged 25-54 have six or more subscription services (see Srihari [0002]). As a result, users may end up inadvertently spending significant amounts of money in the form of unwanted subscription charges that are paid on a recurring basis. Not surprisingly, nearly half of users do not know the exact amount of money they are spending on subscriptions. However, to manage these unwanted services, a user may take the steps of canceling the service or altering their services via calling a customer service center or logging into the merchant's web site. Such methods of cancelling or updating a service can be time consuming, and require the user to know what services they have (see Srihari [0003]).
Claim 20 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 13 of application 18918651 in view of Evans et al. (US 20200184434 A1, published 06/11/2020), hereinafter Evans, in further view of Srihari et al. (US 20240320644 A1, published 09/26/2024), hereinafter Srihari. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Claim 20) A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
Claim 13) A system for operating remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to:
(a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI, and (ii) the Remote Connection GUI comprises (A) a transfer destination identification for a remote network that implements a remote connection, (B) a control component, and (C) remote connection transfer data;
(b) establish a secure communication session with the remote network; and
(b) establish a secure communication session with the plurality of remote networks without requiring the end user to input security data to the end user computing device; and
(c) when the end user selects the control component, transmit a command to the remote network that implements the remote connection, wherein the remote network processes the command to (i) modify remote connection data stored to the remote network, or (ii) cause the remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI
(c) transmit a command to a first remote network in response to the end user selecting a function control component on a graphical user interface displayed by the end user computing device, wherein (i) the command is executed by the first remote network, and (ii) in response to receiving the command, the remote network transmits remote connection data for display by the end user computing device
Regarding claim 20, in the same field of endeavor, Evans teaches: (a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI (Evans 1-4; [0029], [0054-0057]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated (a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI as suggested in Evans into Srihari. Doing so would be desirable because the present disclosure relates generally to the field of systems and methods for automatically identifying subscription-based (or membership-based) goods and services that are in disuse (or not used) and automatically managing the subscription (or membership) based on the disuse (see Evans [0001]). Users may forget to cancel the subscription (or membership), especially when recurring payments to the merchants are scheduled to automatically occur, which can lead to payments for goods or services that are no longer used. Further, merchants may exacerbate the problem by making it difficult or time consuming to cancel the subscription (or membership), since a large source of income for such subscription-based goods and services is generated from recurring payments received from the users regardless of whether the goods or services are being used. Thus, even if the user desires to cancel the subscription, the user may become frustrated with the cancellation process, which can cause delays or even forego cancellation even though the goods or services are disused (see Evans [0002]). Accordingly, systems and methods for automatically identifying goods and services that are disused (or not used) to enable efficient management of subscriptions (or memberships) associated with the goods and services may be desired (see Evans [0003]).
In the same field of endeavor, Srihari teaches wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI, and (ii) the Remote Connection GUI comprises (A) a transfer destination identification for a remote network that implements a remote connection, (B) a control component, and (C) remote connection transfer data; (Srihari Figs. 1-11; [0045-0049], [0062-0066], [0070-0077], [0081-0091]). It would have been obvious to one of ordinary skill in the art at the time the invention was made to have incorporated wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI, and (ii) the Remote Connection GUI comprises (A) a transfer destination identification for a remote network that implements a remote connection, (B) a control component, and (C) remote connection transfer data as suggested in Srihari. Doing so would be desirable because many subscription services can be updated or cancelled online by a user, with a web browser, going to a merchant's web site and logging in and navigating through several pages to in order to update or cancel their service. The increasing number of these services may contribute to an increase in situations in which a user loses track of the services to which that user is subscribed. For example, 1 in 3 users aged 25-54 have six or more subscription services (see Srihari [0002]). As a result, users may end up inadvertently spending significant amounts of money in the form of unwanted subscription charges that are paid on a recurring basis. Not surprisingly, nearly half of users do not know the exact amount of money they are spending on subscriptions. However, to manage these unwanted services, a user may take the steps of canceling the service or altering their services via calling a customer service center or logging into the merchant's web site. Such methods of cancelling or updating a service can be time consuming, and require the user to know what services they have (see Srihari [0003]).
This is a provisional nonstatutory double patenting rejection.
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for 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-7, 9, 11-15, 18, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Srihari et al. (US 20240320644 A1, published 09/26/2024), hereinafter Srihari.
Regarding claim 1, Srihari teaches the claim comprising:
A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to (Srihari Figs. 1-11; [0053], As seen in FIG. 1, computing device 101 may include a processor 111, RAM 113, ROM 115, network interface 117, input/output interfaces (I/O) 119 (e.g., keyboard, mouse, display, printer, etc.), and memory 121. Processor 111 may include one or more computer processing units (CPUs), graphical processing units (GPUs), and/or other processing units such as a processor adapted to perform computations associated with machine learning. I/O 119 may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. I/O 119 may be coupled with a display such as display 120. Memory 121 may store software for configuring computing device 101 into a special purpose computing device in order to perform one or more of the various functions discussed herein):
(a) generate interface assembly instructions, wherein the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data; (b) send the interface assembly instructions to an end user computing device, wherein (Srihari Figs. 1-11; [0045], it may be advantageous to utilize a third party intermediary that provides APIs that allows a bank to provide its customers with subscription management options to manage their subscriptions from the bank mobile app; The third party intermediary can send the subscription management options available to a financial institution. The financial institution in turn can make the subscription management options available to their customers through their mobile app; [0046], a financial institution may apply a machine learning model to generate an accurate prediction to an upcoming charge. Also, a predicted amount of the upcoming charge prediction a predicted date when an upcoming charge will be applied to a user's electronic payment method can be generated by a computing device of the financial institution. Thus, the user can, via the financial institution mobile app, be presented with a list of upcoming charges for specific subscription services determined to be recurring transactions on the display of their mobile device separately from other transactions, and manage the subscription services by selecting a subscription management option such as pause, cancel, or update payment method; [0048], the financial institution can identify all subscription related recurring transactions and provide at least the option to block charges; [0049], The determined probability that the past charges correspond to a subscription type recurring transaction may then be used to determine whether an upcoming charge should be presented to the user to provide a user with one or more options to alter the service associated with the upcoming charge such as by canceling, pausing, or updating the service, or an option allowing the user to update the payment method for the service associated with the subscription type recurring transaction; [0062], financial institution 220 may process the incoming charges for each corresponding user and then the server 230 may store the transaction data as historical transaction data in user transaction data storage 222 associated with the financial institution in step 305; [0065], Financial institution 220, for a user, may determine periodically, such as daily or responsive to a charge being received and processed to the user's electronic payment method for a service of a particular merchant, the probability that the historical transaction data, which includes past charges associated with the particular merchant, indicates that the past charges represent a subscription type recurring transaction that is expected to have an upcoming payment date in step 310; [0066], In step 310, the server(s) 230 may determine, based on a machine learning model 225 and the historical transaction data, a probability that historical transaction data of the user for past charges from a particular merchant indicates a subscription type recurring transaction for a service of the particular merchant; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0071], server 230 may associate a block charges or allow charges option with the upcoming transaction, by adding the block charge option to the upcoming transaction data in upcoming transaction data memory 224; [0073], After adding the block charge option to the upcoming transaction data in step 340, server 230 may send upcoming transaction data to financial institution mobile app on user mobile device 202 in step 350; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350. In this case, the upcoming transaction data may include expected upcoming charge date, expected upcoming charge amount, identity of the merchant, expected transaction description of upcoming charge, regular cadence of the charge, and the subscription management options available to the user to manage the subscription type service);
(i) the interface assembly instructions generate a Remote Connection graphical user interface (GUI) when the interface assembly instructions are executed by the end user computing device, and (ii) the Remote Connection GUI displays the transfer destination identifications, the control components, and the remote connection transfer data (Srihari Figs. 1-11; [0070], if third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0076] Following step 350 (taking either pathway from step 335), in step 355 when the user 201 accesses their account associated with their electronic payment method (e.g., credit account) on the financial mobile app on mobile device 202, the mobile app may display upcoming transactions, which are subscription type and any available options for managing the subscriptions. An illustrative user interface screen 600 in the mobile app displaying the upcoming transactions for a credit card is shown in FIG. 6A; [0077], On screen 600, upcoming transactions (recurring transactions) as may be identified as upcoming bills 610 may be listed separately from recent transactions for the user to view. In this example, three upcoming transactions are listed with their corresponding upcoming transaction data. For the second upcoming bill listed, the merchant name 610, expected upcoming charge amount 625, expected upcoming charge date 630, and recurring charge period (regular cadence) 635 may be displayed on screen 600. The upcoming bills listed may be presented to include the next three expected upcoming charges, or one, all or less than all of the expected upcoming charges, which may be limited based on the available screen real estate. Also, on the display next to the expected upcoming charge amount 625 may be three dots ( . . . ) as shown on screen 600. By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription);
and (c) when the end user selects a control component, transmit a command to a first remote network that implements a first remote connection, wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI (Srihari Figs. 1-11; [0007], receiving, by the application and via second user input, a reactivation instruction to reactivate the subscription type service, and sending, via the third party intermediary to the corresponding merchant, the reactivation instruction to reactivate the subscription type service; [0045], A customer of the financial institution may select a subscription management option, and subscription management instruction may be sent, via the third party intermediary, to the merchant. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, upgrade or downgrade subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellation, and resubscribe; [0059], online video streaming; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0086], By selecting three dots region 950 next to canceled service 930, the user may be presented with a subscription management option to “resubscribe to service”; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); [0089], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with a service update screen similar to screen 820 in FIG. 8B along with selection regions similar to 850 and 860, but tailored for a user updating their service type. As in the offer example, the user may select an option to update their service plan by selecting a service option and selecting an accept update region or decline to change/update their service plan and continue to cancel (or pause) service by selecting a decline region on the user interface of the mobile app; [0090], If the user has selected to accept the promotional offer or update their service plan in step 380, the mobile app sends an updated alter instruction corresponding to the accepted promotional offer or updated service plan to server 230. Server 230 may send the updated alter instruction, via third party intermediary APIs including service management functions API 244. Third party intermediary 240 then sends the updated alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385; [0091], If the user has selected to decline the promotional offer or not update their service plan in step 380, the mobile app sends the original alter instruction (e.g., cancel service, pause service) to server 230 as part of step 390. Server 230 may send the original alter instruction to third party intermediary 240, via third party intermediary APIs including service management functions API 244 as further part of step 390; [0092], Third party intermediary 240 may then send the original alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385. After receiving a cancel instruction, server 230 may store user cancellation data in user cancellation and pause data store 228; [0093], the merchant may respond to the third party intermediary with a message that the service may not be cancellable or is only cancellable by payment of early termination fee, or has been successfully executed; server 230 can send a notification to the user regarding status of their cancel request. Notification may be sent to any or all of the user's mobile app; [0095], The financial institution may maintain an inactive (e.g., paused, canceled, blocked) service list with the merchant identifier and user information in user cancellation and pause data store 228 and update that list each time a new service becomes inactive or a previously inactive service is reactivated. The list may be forwarded by server 230 to the user's mobile app for display to user 201 on the screen of mobile device 202; [0096], An example screen may include a list of upcoming transactions and a list of inactive subscription services such as illustrated in FIG. 9)
Regarding claim 2, Srihari teaches all the limitations of claim 1, further comprising:
wherein the control components comprise at least one of a cancel function, a modify plan function, a change card function, and an activity function (Srihari Figs. 1-11; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); see also [0090-0096])
Regarding claim 3, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the command is a cancel function; and (b) the first remote network processes the cancel function to terminate the first remote connection (Srihari Figs. 1-11; [0018], sending, via the third party intermediary to the corresponding merchant, the cancel instruction; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680; advise the user that they will be notified of the result of the cancellation in several days by email; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0092], Third party intermediary 240 may then send the original alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385. After receiving a cancel instruction, server 230 may store user cancellation data in user cancellation and pause data store 228; [0093], where third party intermediary 240 communicates the cancel instruction to the relevant merchant, the merchant may respond to the third party intermediary with a message that the service may not be cancellable or is only cancellable by payment of early termination fee, or has been successfully executed; [0095], third party intermediary may provide service management options including restart a paused service and resubscribe to a canceled service; [0096], An example screen may include a list of upcoming transactions and a list of inactive subscription services such as illustrated in FIG. 9. On screen 900, inactive list 910 is shown with a service 920 for which charges are blocked and a service 930 which has been canceled; see also [0082], [0090-0095])
Regarding claim 12, the claim contains substantially similar limitations to those found in claim 3. Consequently, the claim is rejected for the same reasons.
Regarding claim 4, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the command is a modify plan function; and (b) the first remote network processes the modify plan function to modify remote connection data by modifying a subscription level, wherein modifying the subscription level reduces resource utilization through the first remote connection (Srihari Figs. 1-11; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); see also [0090-0096])
Regarding claim 13, the claim contains substantially similar limitations to those found in claim 4. Consequently, the claim is rejected for the same reasons.
Regarding claim 5, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the command is an activity function; and (b) the first remote network processes the activity function to return remote connection transfer data according to an end user selection (Srihari Figs. 1-11; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); [0089], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with a service update screen similar to screen 820 in FIG. 8B along with selection regions similar to 850 and 860, but tailored for a user updating their service type. As in the offer example, the user may select an option to update their service plan by selecting a service option and selecting an accept update region or decline to change/update their service plan and continue to cancel (or pause) service by selecting a decline region on the user interface of the mobile app; see also [0090-0096])
Regarding claim 14, the claim contains substantially similar limitations to those found in claim 5. Consequently, the claim is rejected for the same reasons.
Regarding claim 6, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the command is a change card function; and (b) the first remote network processes the change card function to replace stored remote connection transfer data (Srihari Figs. 1-11; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081-0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); see also [0083-0086], [0090-0096])
Regarding claim 15, the claim contains substantially similar limitations to those found in claim 6. Consequently, the claim is rejected for the same reasons.
Regarding claim 7, Srihari teaches all the limitations of claim 1, further comprising:
wherein (a) the interface assembly instructions further comprise a classification code; and (b) the Remote Connection graphical user interface (GUI) displays a remote connection classification based on the classification code (Srihari Figs. 1-11; [0015], the transaction details for one or more of the past charges may comprise a merchant category code field, and the machine learning model may be further configured to perform steps comprising determining, based on the merchant category code field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with the merchant category code field indicating that a category of goods or services provided by the merchant correspond to a subscription type recurring transaction; [0060], The transaction data may comprise a merchant identifier field that indicates the name of the merchant and/or a merchant identifier (e.g., a numeric code) that may be used to identify the merchant associated with the incoming charge, a merchant category code (MCC), the amount of the charge, the date of the charge, and a transaction description of the charge; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0076] Following step 350 (taking either pathway from step 335), in step 355 when the user 201 accesses their account associated with their electronic payment method (e.g., credit account) on the financial mobile app on mobile device 202, the mobile app may display upcoming transactions, which are subscription type and any available options for managing the subscriptions. An illustrative user interface screen 600 in the mobile app displaying the upcoming transactions for a credit card is shown in FIG. 6A; [0077], On screen 600, upcoming transactions (recurring transactions) as may be identified as upcoming bills 610 may be listed separately from recent transactions for the user to view; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0105], the merchant category code may be evaluated to determine if the types of goods or services associated with the transaction may represent a subscription type recurring transaction; see also [0081-0087], [0090-0096])
Regarding claim 19, the claim contains substantially similar limitations to those found in claim 7. Consequently, the claim is rejected for the same reasons.
Regarding claim 9, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the interface assembly instructions further comprise an activity instruction control component configured for selection by the end user; (b) the Remote Connection graphical user interface (GUI) displays the activity instruction control component; (c) selecting the activity instruction control component generates activity instructions for execution by the end user computing device; (d) the activity instructions are displayed by the end user computing device; and (e) executing the activity instructions reduces resource utilization through the first remote connection (Srihari Figs. 1-11; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0086], In an example, in which user 201 selects to change service in step 360, which is a service management option of the third party intermediary, prior to confirming the change instruction in step 369, the mobile app may display screen 810 prompting user 201 to update their service plan by selecting one of the available plans; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); [0088], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with an offer in their mobile app to continue their service or provide options for updating their service on the display of mobile device 202 in step 375. An example of an offer a user could receive is shown on screen 830 of mobile device 202 in FIG. 8C; [0089], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with a service update screen similar to screen 820 in FIG. 8B along with selection regions similar to 850 and 860, but tailored for a user updating their service type. As in the offer example, the user may select an option to update their service plan by selecting a service option and selecting an accept update region or decline to change/update their service plan and continue to cancel (or pause) service by selecting a decline region on the user interface of the mobile app; see also [0090-0096])
Regarding claim 11, Srihari teaches the claim comprising:
A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to (Srihari Figs. 1-11; [0053], As seen in FIG. 1, computing device 101 may include a processor 111, RAM 113, ROM 115, network interface 117, input/output interfaces (I/O) 119 (e.g., keyboard, mouse, display, printer, etc.), and memory 121. Processor 111 may include one or more computer processing units (CPUs), graphical processing units (GPUs), and/or other processing units such as a processor adapted to perform computations associated with machine learning. I/O 119 may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. I/O 119 may be coupled with a display such as display 120. Memory 121 may store software for configuring computing device 101 into a special purpose computing device in order to perform one or more of the various functions discussed herein):
(a) execute stored interface assembly instructions, wherein (i) the interface assembly instructions comprise (i) a plurality of transfer destination identifications that each correspond to a remote connection implemented by a remote network, (ii) control components configured for selection by an end user, and (iii) remote connection transfer data (Srihari Figs. 1-11; [0045], it may be advantageous to utilize a third party intermediary that provides APIs that allows a bank to provide its customers with subscription management options to manage their subscriptions from the bank mobile app; The third party intermediary can send the subscription management options available to a financial institution. The financial institution in turn can make the subscription management options available to their customers through their mobile app; [0046], a financial institution may apply a machine learning model to generate an accurate prediction to an upcoming charge. Also, a predicted amount of the upcoming charge prediction a predicted date when an upcoming charge will be applied to a user's electronic payment method can be generated by a computing device of the financial institution. Thus, the user can, via the financial institution mobile app, be presented with a list of upcoming charges for specific subscription services determined to be recurring transactions on the display of their mobile device separately from other transactions, and manage the subscription services by selecting a subscription management option such as pause, cancel, or update payment method; [0048], the financial institution can identify all subscription related recurring transactions and provide at least the option to block charges; [0049], The determined probability that the past charges correspond to a subscription type recurring transaction may then be used to determine whether an upcoming charge should be presented to the user to provide a user with one or more options to alter the service associated with the upcoming charge such as by canceling, pausing, or updating the service, or an option allowing the user to update the payment method for the service associated with the subscription type recurring transaction; [0062], financial institution 220 may process the incoming charges for each corresponding user and then the server 230 may store the transaction data as historical transaction data in user transaction data storage 222 associated with the financial institution in step 305; [0065], Financial institution 220, for a user, may determine periodically, such as daily or responsive to a charge being received and processed to the user's electronic payment method for a service of a particular merchant, the probability that the historical transaction data, which includes past charges associated with the particular merchant, indicates that the past charges represent a subscription type recurring transaction that is expected to have an upcoming payment date in step 310; [0066], In step 310, the server(s) 230 may determine, based on a machine learning model 225 and the historical transaction data, a probability that historical transaction data of the user for past charges from a particular merchant indicates a subscription type recurring transaction for a service of the particular merchant; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0071], server 230 may associate a block charges or allow charges option with the upcoming transaction, by adding the block charge option to the upcoming transaction data in upcoming transaction data memory 224; [0073], After adding the block charge option to the upcoming transaction data in step 340, server 230 may send upcoming transaction data to financial institution mobile app on user mobile device 202 in step 350; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350. In this case, the upcoming transaction data may include expected upcoming charge date, expected upcoming charge amount, identity of the merchant, expected transaction description of upcoming charge, regular cadence of the charge, and the subscription management options available to the user to manage the subscription type service);
(ii) executing the interface assembly instructions generates a Remote Connection graphical user interface (GUI), and (iii) the Remote Connection GUI displays the plurality of transfer destination identifications, the control components, and the remote connection transfer data (Srihari Figs. 1-11; [0070], if third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0076] Following step 350 (taking either pathway from step 335), in step 355 when the user 201 accesses their account associated with their electronic payment method (e.g., credit account) on the financial mobile app on mobile device 202, the mobile app may display upcoming transactions, which are subscription type and any available options for managing the subscriptions. An illustrative user interface screen 600 in the mobile app displaying the upcoming transactions for a credit card is shown in FIG. 6A; [0077], On screen 600, upcoming transactions (recurring transactions) as may be identified as upcoming bills 610 may be listed separately from recent transactions for the user to view. In this example, three upcoming transactions are listed with their corresponding upcoming transaction data. For the second upcoming bill listed, the merchant name 610, expected upcoming charge amount 625, expected upcoming charge date 630, and recurring charge period (regular cadence) 635 may be displayed on screen 600. The upcoming bills listed may be presented to include the next three expected upcoming charges, or one, all or less than all of the expected upcoming charges, which may be limited based on the available screen real estate. Also, on the display next to the expected upcoming charge amount 625 may be three dots ( . . . ) as shown on screen 600. By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription);
(b) establish a secure communication session with each of the remote networks without requiring the end user to input security data to the end user computing device (Srihari Figs. 1-11; [0005], Aspects described herein may address these and other problems, and generally improve user convenience by allowing a user, via an application executing on a mobile device, to manage a service from a merchant that has been determined, by the financial institution applying a machine learning model to historical transaction data of a user for the service, to be a recurring transaction. In this case, a user can manage recurring transactions (e.g., subscriptions) without the need to call or log on to the merchant's website; [0058], According to an illustrative operation of the system of FIG. 2, server(s) 230 such as computing device(s) (e.g., computing device 101) of financial institution 220 may receive a transaction stream 210 from a payment processor in step 300, which provides customer transaction data for incoming charges from merchants to an electronic payment method of a user (customer); [0060], The transaction data may comprise a merchant identifier field that indicates the name of the merchant and/or a merchant identifier (e.g., a numeric code) that may be used to identify the merchant associated with the incoming charge, a merchant category code (MCC), the amount of the charge, the date of the charge, and a transaction description of the charge; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge)
and (c) when the end user selects a control component, transmit a command to a first remote network that implements a first remote connection, wherein the remote network processes the command to (i) modify remote connection data stored to the first remote network, or (ii) cause the first remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI (Srihari Figs. 1-11; [0007], receiving, by the application and via second user input, a reactivation instruction to reactivate the subscription type service, and sending, via the third party intermediary to the corresponding merchant, the reactivation instruction to reactivate the subscription type service; [0045], A customer of the financial institution may select a subscription management option, and subscription management instruction may be sent, via the third party intermediary, to the merchant. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, upgrade or downgrade subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellation, and resubscribe; [0059], online video streaming; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0086], By selecting three dots region 950 next to canceled service 930, the user may be presented with a subscription management option to “resubscribe to service”; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); [0089], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with a service update screen similar to screen 820 in FIG. 8B along with selection regions similar to 850 and 860, but tailored for a user updating their service type. As in the offer example, the user may select an option to update their service plan by selecting a service option and selecting an accept update region or decline to change/update their service plan and continue to cancel (or pause) service by selecting a decline region on the user interface of the mobile app; [0090], If the user has selected to accept the promotional offer or update their service plan in step 380, the mobile app sends an updated alter instruction corresponding to the accepted promotional offer or updated service plan to server 230. Server 230 may send the updated alter instruction, via third party intermediary APIs including service management functions API 244. Third party intermediary 240 then sends the updated alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385; [0091], If the user has selected to decline the promotional offer or not update their service plan in step 380, the mobile app sends the original alter instruction (e.g., cancel service, pause service) to server 230 as part of step 390. Server 230 may send the original alter instruction to third party intermediary 240, via third party intermediary APIs including service management functions API 244 as further part of step 390; [0092], Third party intermediary 240 may then send the original alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385. After receiving a cancel instruction, server 230 may store user cancellation data in user cancellation and pause data store 228; [0093], the merchant may respond to the third party intermediary with a message that the service may not be cancellable or is only cancellable by payment of early termination fee, or has been successfully executed; server 230 can send a notification to the user regarding status of their cancel request. Notification may be sent to any or all of the user's mobile app; [0095], The financial institution may maintain an inactive (e.g., paused, canceled, blocked) service list with the merchant identifier and user information in user cancellation and pause data store 228 and update that list each time a new service becomes inactive or a previously inactive service is reactivated. The list may be forwarded by server 230 to the user's mobile app for display to user 201 on the screen of mobile device 202; [0096], An example screen may include a list of upcoming transactions and a list of inactive subscription services such as illustrated in FIG. 9)
Regarding claim 18, Srihari teaches all the limitations of claim 11, further comprising:
wherein the system comprises a Remote Connection application programming interface (API) that converts the command to a format that complies with a communication protocol utilized by the first remote network (Srihari Figs. 1-11; [0045], it may be advantageous to utilize a third party intermediary that provides APIs that allows a bank to provide its customers with subscription management options to manage their subscriptions from the bank mobile app; The third party intermediary can send the subscription management options available to a financial institution. The financial institution in turn can make the subscription management options available to their customers through their mobile app; [0060], the transaction data may be structured in accordance with the ISO 8583 API. In other aspects, the transaction data may be structured in accordance with any API accepted and processed by one or more computing devices of financial institution 220 by a payment processor; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation;; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350; [0090], Server 230 may send the updated alter instruction, via third party intermediary APIs including service management functions API 244. Third party intermediary 240 then sends the updated alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385; [0092], For a cancel instruction, an authorization form may be sent by server 230 of financial institution 200, via the letter of attorney API 246, to third party intermediary 240 along with the cancel instruction being sent to service management functions API 244)
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.
Claims 8, 10, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Srihari in view of Goldfield et al. (US 20230031874 A1, published 02/02/2023), hereinafter Goldfield.
Regarding claim 8, Srihari teaches all the limitations of claim 7, further comprising:
wherein: (a) the interface assembly instructions further comprise a sort control component configured for selection by the end user; (b) the Remote Connection graphical user interface (GUI) displays a sort function; (d) selection of a first sort parameter displays the transfer destination identifications on the Remote Connection GUI in a sequence according to the first sort parameter (Srihari Figs. 1-11; [0015], the transaction details for one or more of the past charges may comprise a merchant category code field, and the machine learning model may be further configured to perform steps comprising determining, based on the merchant category code field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with the merchant category code field indicating that a category of goods or services provided by the merchant correspond to a subscription type recurring transaction; [0060], The transaction data may comprise a merchant identifier field that indicates the name of the merchant and/or a merchant identifier (e.g., a numeric code) that may be used to identify the merchant associated with the incoming charge, a merchant category code (MCC), the amount of the charge, the date of the charge, and a transaction description of the charge; [0076-0077], On screen 600, upcoming transactions (recurring transactions) as may be identified as upcoming bills 610 may be listed separately from recent transactions for the user to view; [0096] An example screen may include a list of upcoming transactions and a list of inactive subscription services such as illustrated in FIG. 9. On screen 900, inactive list 910 is shown with a service 920 for which charges are blocked and a service 930 which has been canceled; see also [0081-0087], [0090-0096])
However, Srihari fails to expressly disclose wherein: (a) the interface assembly instructions further comprise a sort control component configured for selection by the end user; (b) the Remote Connection graphical user interface (GUI) displays a sort function; (c) the sort function presents the end user with a plurality of sort parameters; and (d) selection of a first sort parameter displays the transfer destination identifications on the Remote Connection GUI in a sequence according to the first sort parameter. In the same field of endeavor, Goldfield teaches:
wherein: (a) the interface assembly instructions further comprise a sort control component configured for selection by the end user; (b) the Remote Connection graphical user interface (GUI) displays a sort function; (c) the sort function presents the end user with a plurality of sort parameters; and (d) selection of a first sort parameter displays the transfer destination identifications on the Remote Connection GUI in a sequence according to the first sort parameter (Goldfield Figs. 1-13; abs. the computing server classifies a list of named entities that offer subscription services and hence, create recurring transactions with the client organization. The computing server receives transaction data and determines that a target transacting named entity extracted from the received data belongs to the category (e.g., there is a named entity in the received transaction data that has sold a service to the client organization more than once). The computing server may then determine the presence and frequency of a subscription transaction series in the received transaction data, and cause a predicted a timing of an upcoming transaction in the subscription transaction series to be displayed in a graphical user interface; [0101], FIG. 10 is a recurring transaction and named entity management portal 1000, in accordance with an embodiment. The computing server 110 causes the portal 1000 to be generated as a GUI (e.g., the interface 260) where clients can monitor transactions made by an organization’s employees. An employee of an organization may request various transactions using an end user transaction device (e.g., the end user transaction device 120), owning those transactions as the requestor or initiator; as shown in FIG. 10, the computing server 110 can cause a summary of recurring transactions by each vendor to be generated in the portal 1000; [0102], Each vendor in the table 1011 is listed in a row along with columns for the corresponding employee owner who made a transaction with the vendor, the total amount spent in all recurring transactions between the vendor and the employee owner, the amount spent within the last thirty days between the vendor and the employee owner, predicted next payment to the vendor by the employee owner (e.g., as predicted using the transaction prediction engine 240), frequency of the recurring transactions (e.g., as determined using the transaction analysis engine 230), department of the organization to which the employee owner belongs, and office of the organization at which the employee owner is located. The columns depicted in the table 1010 are examples of characterizing aspects of a recurring transaction that may be provided to the client and used to sort the recurring transactions. For example, a client may sort the transactions by the dates of the upcoming transactions so that the client can see upcoming payments in chronological order)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein: (a) the interface assembly instructions further comprise a sort control component configured for selection by the end user; (b) the Remote Connection graphical user interface (GUI) displays a sort function; (c) the sort function presents the end user with a plurality of sort parameters; and (d) selection of a first sort parameter displays the transfer destination identifications on the Remote Connection GUI in a sequence according to the first sort parameter as suggested in Goldfield into Srihari. Doing so would be desirable because trillions of transactions are made daily, including recurring transactions such as those for a subscription-based service. The records of those transactions can contain data that lack a standard protocol or format, leading to transaction data to appear noisy for a receiving party who does not have full information of data schemas and structures used. Organizations can subscribe to multiple subscriptions, which may be difficult to track when transactions of an organizations’ members (e.g., employees) can accumulate to tens of thousands of transactions in a day where not all are subscription-based transactions. Analyzing an organization’s transaction data using complex rules to compensate for the lack of a standard format can demand intense computing resources (see Goldfield [0002]). By identifying the named entities and recurring transactions using predetermined rules to create structured data, the computing server can identify opportunities to optimize transactions more efficiently in the structured data, utilizing resources that may otherwise have been spent on an unnecessarily intensive search for the same recurring transactions in unstructured data (see Goldfield [0005]). Additionally, the system of Goldfield would improve the interface of Srihari by enabling a user to flexibly sort by a plurality of desired parameters (see Goldfield [0102]). Providing a plurality of sorting options would better enable the user to quickly and easily find desired information, thereby increasing ease of use and user satisfaction.
Regarding claim 10, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the system further comprises a machine learning model; and (b) the machine learning model the operation to generate activity instructions for execution by the end user computing device (Srihari Figs. 1-11; [0045-0046], a financial institution may apply a machine learning model to generate an accurate prediction to an upcoming charge. Also, a predicted amount of the upcoming charge prediction a predicted date when an upcoming charge will be applied to a user's electronic payment method can be generated by a computing device of the financial institution. Thus, the user can, via the financial institution mobile app, be presented with a list of upcoming charges for specific subscription services determined to be recurring transactions on the display of their mobile device separately from other transactions, and manage the subscription services by selecting a subscription management option such as pause, cancel, or update payment method; [0048], the financial institution can identify all subscription related recurring transactions and provide at least the option to block charges; [0049], The determined probability that the past charges correspond to a subscription type recurring transaction may then be used to determine whether an upcoming charge should be presented to the user to provide a user with one or more options to alter the service associated with the upcoming charge such as by canceling, pausing, or updating the service, or an option allowing the user to update the payment method for the service associated with the subscription type recurring transaction; [0062], financial institution 220 may process the incoming charges for each corresponding user and then the server 230 may store the transaction data as historical transaction data in user transaction data storage 222 associated with the financial institution in step 305; [0065], Financial institution 220, for a user, may determine periodically, such as daily or responsive to a charge being received and processed to the user's electronic payment method for a service of a particular merchant, the probability that the historical transaction data, which includes past charges associated with the particular merchant, indicates that the past charges represent a subscription type recurring transaction that is expected to have an upcoming payment date in step 310; [0066], In step 310, the server(s) 230 may determine, based on a machine learning model 225 and the historical transaction data, a probability that historical transaction data of the user for past charges from a particular merchant indicates a subscription type recurring transaction for a service of the particular merchant; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0071], server 230 may associate a block charges or allow charges option with the upcoming transaction, by adding the block charge option to the upcoming transaction data in upcoming transaction data memory 224; [0073], After adding the block charge option to the upcoming transaction data in step 340, server 230 may send upcoming transaction data to financial institution mobile app on user mobile device 202 in step 350; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350. In this case, the upcoming transaction data may include expected upcoming charge date, expected upcoming charge amount, identity of the merchant, expected transaction description of upcoming charge, regular cadence of the charge, and the subscription management options available to the user to manage the subscription type service; [0097], FIG. 4 is an illustrative flowchart of a machine learning model determining a probability that historical charge data of a user associated with a merchant; [0102], The machine learning model may comprise parameters (e.g., adjustable weights and fixed biases) and each of the weights of the machine learning model may be adjusted based on the extent to which each of the weights contributes to increasing or decreasing the accuracy of output generated by the machine learning model; [0112], [0112] In step 1030, the machine learning model may determine, based on a merchant category code field being present in one or more of the past transactions of the historical transaction data, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with the merchant category code (e.g., a four digit code indicating the type of good or service provided by a merchant) field indicating that a category of goods or services provided by the merchant correspond to a subscription type recurring transaction)
However, Srihari fails to expressly disclose (a) the system further comprises a neural network; and (b) the neural network performs the operation. In the same field of endeavor, Goldfield teaches:
(a) the system further comprises a neural network; and (b) the neural network performs the operation (Goldfield Figs. 1-13; abs. the computing server classifies a list of named entities that offer subscription services and hence, create recurring transactions with the client organization. The computing server receives transaction data and determines that a target transacting named entity extracted from the received data belongs to the category (e.g., there is a named entity in the received transaction data that has sold a service to the client organization more than once). The computing server may then determine the presence and frequency of a subscription transaction series in the received transaction data, and cause a predicted a timing of an upcoming transaction in the subscription transaction series to be displayed in a graphical user interface; [0040], With respect to the identification of vendors that conduct businesses with the organization client, the named entity identification engine 215 may identify merchants that are associated with the transactions. The named entity identification engine 215 may apply a model to determine the merchant that is associated with a particular transaction. The model may be a machine learning model or an algorithmic model that includes a set of rules to determine the merchant; [0043], Each type of recommendation may be generated by a specific model. A model may be a machine learning model or an algorithmic model that includes a set of rules to generate a recommendation; [0093], a wide variety of machine learning techniques may be used. Examples of which include different forms of unsupervised learning, clustering, embeddings such as word embeddings, support vector regression (SVR) model, random forest classifiers, support vector machines (SVMs) such as kernel SVMs, gradient boosting, linear regression, logistic regression, and other forms of regressions. Deep learning techniques such as neural networks, including convolutional neural networks (CNN), recurrent neural networks (RNN), and long short-term memory networks (LSTM), may also be used; [0096], Referring to FIG. 9, a structure of an example neural network (NN) is illustrated, according to an embodiment; [0098-0099], Each of the functions in the neural network may be associated with different coefficients (e.g. weights and kernel coefficients) that are adjustable during training)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated (a) the system further comprises a neural network; and (b) the neural network performs the operation as suggested in Goldfield into Srihari. Doing so would be desirable because trillions of transactions are made daily, including recurring transactions such as those for a subscription-based service. The records of those transactions can contain data that lack a standard protocol or format, leading to transaction data to appear noisy for a receiving party who does not have full information of data schemas and structures used. Organizations can subscribe to multiple subscriptions, which may be difficult to track when transactions of an organizations’ members (e.g., employees) can accumulate to tens of thousands of transactions in a day where not all are subscription-based transactions. Analyzing an organization’s transaction data using complex rules to compensate for the lack of a standard format can demand intense computing resources (see Goldfield [0002]). By identifying the named entities and recurring transactions using predetermined rules to create structured data, the computing server can identify opportunities to optimize transactions more efficiently in the structured data, utilizing resources that may otherwise have been spent on an unnecessarily intensive search for the same recurring transactions in unstructured data (see Goldfield [0005]). Srihari discloses utilizing a machine learning model comprising a plurality of trained weights (see Srihari [0102], [0108]). Goldfield clarifies that a wide variety of machine learning models may be used (see Goldfield [0093]) to analyze recurring transactions (see Goldfield [0040]), such as a neural networks comprising a plurality of trained weights (see Goldfield [0093], [0096-0099]), thereby providing a well-known, effective, and efficient machine learning model.
Regarding claim 16, Srihari teaches all the limitations of claim 11, further comprising:
wherein: (a) the system further comprises a machine learning model; (b) the machine learning model performs an operation to determine the transfer destination identifications by processing transfer activity data to recognize transfers conducted through a remote connection (Srihari Figs. 1-11; [0045-0046], a financial institution may apply a machine learning model to generate an accurate prediction to an upcoming charge. Also, a predicted amount of the upcoming charge prediction a predicted date when an upcoming charge will be applied to a user's electronic payment method can be generated by a computing device of the financial institution. Thus, the user can, via the financial institution mobile app, be presented with a list of upcoming charges for specific subscription services determined to be recurring transactions on the display of their mobile device separately from other transactions, and manage the subscription services by selecting a subscription management option such as pause, cancel, or update payment method; [0048], the financial institution can identify all subscription related recurring transactions and provide at least the option to block charges; [0049], The determined probability that the past charges correspond to a subscription type recurring transaction may then be used to determine whether an upcoming charge should be presented to the user to provide a user with one or more options to alter the service associated with the upcoming charge such as by canceling, pausing, or updating the service, or an option allowing the user to update the payment method for the service associated with the subscription type recurring transaction; [0062], financial institution 220 may process the incoming charges for each corresponding user and then the server 230 may store the transaction data as historical transaction data in user transaction data storage 222 associated with the financial institution in step 305; [0065], Financial institution 220, for a user, may determine periodically, such as daily or responsive to a charge being received and processed to the user's electronic payment method for a service of a particular merchant, the probability that the historical transaction data, which includes past charges associated with the particular merchant, indicates that the past charges represent a subscription type recurring transaction that is expected to have an upcoming payment date in step 310; [0066], In step 310, the server(s) 230 may determine, based on a machine learning model 225 and the historical transaction data, a probability that historical transaction data of the user for past charges from a particular merchant indicates a subscription type recurring transaction for a service of the particular merchant; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0071], server 230 may associate a block charges or allow charges option with the upcoming transaction, by adding the block charge option to the upcoming transaction data in upcoming transaction data memory 224; [0073], After adding the block charge option to the upcoming transaction data in step 340, server 230 may send upcoming transaction data to financial institution mobile app on user mobile device 202 in step 350; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350. In this case, the upcoming transaction data may include expected upcoming charge date, expected upcoming charge amount, identity of the merchant, expected transaction description of upcoming charge, regular cadence of the charge, and the subscription management options available to the user to manage the subscription type service; [0097], FIG. 4 is an illustrative flowchart of a machine learning model determining a probability that historical charge data of a user associated with a merchant; [0102], The machine learning model may comprise parameters (e.g., adjustable weights and fixed biases) and each of the weights of the machine learning model may be adjusted based on the extent to which each of the weights contributes to increasing or decreasing the accuracy of output generated by the machine learning model; [0112], [0112] In step 1030, the machine learning model may determine, based on a merchant category code field being present in one or more of the past transactions of the historical transaction data, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with the merchant category code (e.g., a four digit code indicating the type of good or service provided by a merchant) field indicating that a category of goods or services provided by the merchant correspond to a subscription type recurring transaction)
However, Srihari fails to expressly disclose (a) the system further comprises a neural network; (b) the neural network performs an operation. In the same field of endeavor, Goldfield teaches:
(a) the system further comprises a neural network; (b) the neural network performs an operation (Goldfield Figs. 1-13; abs. the computing server classifies a list of named entities that offer subscription services and hence, create recurring transactions with the client organization. The computing server receives transaction data and determines that a target transacting named entity extracted from the received data belongs to the category (e.g., there is a named entity in the received transaction data that has sold a service to the client organization more than once). The computing server may then determine the presence and frequency of a subscription transaction series in the received transaction data, and cause a predicted a timing of an upcoming transaction in the subscription transaction series to be displayed in a graphical user interface; [0040], With respect to the identification of vendors that conduct businesses with the organization client, the named entity identification engine 215 may identify merchants that are associated with the transactions. The named entity identification engine 215 may apply a model to determine the merchant that is associated with a particular transaction. The model may be a machine learning model or an algorithmic model that includes a set of rules to determine the merchant; [0043], Each type of recommendation may be generated by a specific model. A model may be a machine learning model or an algorithmic model that includes a set of rules to generate a recommendation; [0093], a wide variety of machine learning techniques may be used. Examples of which include different forms of unsupervised learning, clustering, embeddings such as word embeddings, support vector regression (SVR) model, random forest classifiers, support vector machines (SVMs) such as kernel SVMs, gradient boosting, linear regression, logistic regression, and other forms of regressions. Deep learning techniques such as neural networks, including convolutional neural networks (CNN), recurrent neural networks (RNN), and long short-term memory networks (LSTM), may also be used; [0096], Referring to FIG. 9, a structure of an example neural network (NN) is illustrated, according to an embodiment; [0098-0099], Each of the functions in the neural network may be associated with different coefficients (e.g. weights and kernel coefficients) that are adjustable during training)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated (a) the system further comprises a neural network; (b) the neural network performs an operation as suggested in Goldfield into Srihari. Doing so would be desirable because trillions of transactions are made daily, including recurring transactions such as those for a subscription-based service. The records of those transactions can contain data that lack a standard protocol or format, leading to transaction data to appear noisy for a receiving party who does not have full information of data schemas and structures used. Organizations can subscribe to multiple subscriptions, which may be difficult to track when transactions of an organizations’ members (e.g., employees) can accumulate to tens of thousands of transactions in a day where not all are subscription-based transactions. Analyzing an organization’s transaction data using complex rules to compensate for the lack of a standard format can demand intense computing resources (see Goldfield [0002]). By identifying the named entities and recurring transactions using predetermined rules to create structured data, the computing server can identify opportunities to optimize transactions more efficiently in the structured data, utilizing resources that may otherwise have been spent on an unnecessarily intensive search for the same recurring transactions in unstructured data (see Goldfield [0005]). Srihari discloses utilizing a machine learning model comprising a plurality of trained weights (see Srihari [0102], [0108]). Goldfield clarifies that a wide variety of machine learning models may be used (see Goldfield [0093]) to analyze recurring transactions (see Goldfield [0040]), such as a neural networks comprising a plurality of trained weights (see Goldfield [0093], [0096-0099]), thereby providing a well-known, effective, and efficient machine learning model.
Regarding claim 17, Srihari in view of Goldfield teaches all the limitations of claim 16. Goldfield further teaches:
wherein the neural network comprises an architecture selected from one of a convolutional neural network architecture, Long short-term memory network architecture, or a recurrent network architecture (Goldfield Figs. 1-13; abs. the computing server classifies a list of named entities that offer subscription services and hence, create recurring transactions with the client organization. The computing server receives transaction data and determines that a target transacting named entity extracted from the received data belongs to the category (e.g., there is a named entity in the received transaction data that has sold a service to the client organization more than once). The computing server may then determine the presence and frequency of a subscription transaction series in the received transaction data, and cause a predicted a timing of an upcoming transaction in the subscription transaction series to be displayed in a graphical user interface; [0040], With respect to the identification of vendors that conduct businesses with the organization client, the named entity identification engine 215 may identify merchants that are associated with the transactions. The named entity identification engine 215 may apply a model to determine the merchant that is associated with a particular transaction. The model may be a machine learning model or an algorithmic model that includes a set of rules to determine the merchant; [0043], Each type of recommendation may be generated by a specific model. A model may be a machine learning model or an algorithmic model that includes a set of rules to generate a recommendation; [0093], a wide variety of machine learning techniques may be used. Examples of which include different forms of unsupervised learning, clustering, embeddings such as word embeddings, support vector regression (SVR) model, random forest classifiers, support vector machines (SVMs) such as kernel SVMs, gradient boosting, linear regression, logistic regression, and other forms of regressions. Deep learning techniques such as neural networks, including convolutional neural networks (CNN), recurrent neural networks (RNN), and long short-term memory networks (LSTM), may also be used; [0096], Referring to FIG. 9, a structure of an example neural network (NN) is illustrated, according to an embodiment; [0098-0099], Each of the functions in the neural network may be associated with different coefficients (e.g. weights and kernel coefficients) that are adjustable during training)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated wherein the neural network comprises an architecture selected from one of a convolutional neural network architecture, Long short-term memory network architecture, or a recurrent network architecture an as suggested in Goldfield into Srihari. Doing so would be desirable because trillions of transactions are made daily, including recurring transactions such as those for a subscription-based service. The records of those transactions can contain data that lack a standard protocol or format, leading to transaction data to appear noisy for a receiving party who does not have full information of data schemas and structures used. Organizations can subscribe to multiple subscriptions, which may be difficult to track when transactions of an organizations’ members (e.g., employees) can accumulate to tens of thousands of transactions in a day where not all are subscription-based transactions. Analyzing an organization’s transaction data using complex rules to compensate for the lack of a standard format can demand intense computing resources (see Goldfield [0002]). By identifying the named entities and recurring transactions using predetermined rules to create structured data, the computing server can identify opportunities to optimize transactions more efficiently in the structured data, utilizing resources that may otherwise have been spent on an unnecessarily intensive search for the same recurring transactions in unstructured data (see Goldfield [0005]). Srihari discloses utilizing a machine learning model comprising a plurality of trained weights (see Srihari [0102], [0108]). Goldfield clarifies that a wide variety of machine learning models may be used (see Goldfield [0093]) to analyze recurring transactions (see Goldfield [0040]), such as convolutional neural networks (CNN), recurrent neural networks (RNN), and long short-term memory networks (LSTM) (see Goldfield [0093], [0096-0099]), thereby providing a well-known, effective, and efficient machine learning model.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Srihari in view of Evans et al. (US 20200184434 A1, published 06/11/2020), hereinafter Evans.
Regarding claim 20, Srihari teaches the claim comprising:
A system for generating a user interface to operate remote connections comprising a computer that includes a processor and a memory device storing data and executable code that, when executed, causes the processor to (Srihari Figs. 1-11; [0053], As seen in FIG. 1, computing device 101 may include a processor 111, RAM 113, ROM 115, network interface 117, input/output interfaces (I/O) 119 (e.g., keyboard, mouse, display, printer, etc.), and memory 121. Processor 111 may include one or more computer processing units (CPUs), graphical processing units (GPUs), and/or other processing units such as a processor adapted to perform computations associated with machine learning. I/O 119 may include a variety of interface units and drives for reading, writing, displaying, and/or printing data or files. I/O 119 may be coupled with a display such as display 120. Memory 121 may store software for configuring computing device 101 into a special purpose computing device in order to perform one or more of the various functions discussed herein):
(a) transmit interface assembly instructions to an end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI (Srihari Figs. 1-11; [0045], it may be advantageous to utilize a third party intermediary that provides APIs that allows a bank to provide its customers with subscription management options to manage their subscriptions from the bank mobile app; The third party intermediary can send the subscription management options available to a financial institution. The financial institution in turn can make the subscription management options available to their customers through their mobile app; [0046], a financial institution may apply a machine learning model to generate an accurate prediction to an upcoming charge. Also, a predicted amount of the upcoming charge prediction a predicted date when an upcoming charge will be applied to a user's electronic payment method can be generated by a computing device of the financial institution. Thus, the user can, via the financial institution mobile app, be presented with a list of upcoming charges for specific subscription services determined to be recurring transactions on the display of their mobile device separately from other transactions, and manage the subscription services by selecting a subscription management option such as pause, cancel, or update payment method; [0048], the financial institution can identify all subscription related recurring transactions and provide at least the option to block charges; [0049], The determined probability that the past charges correspond to a subscription type recurring transaction may then be used to determine whether an upcoming charge should be presented to the user to provide a user with one or more options to alter the service associated with the upcoming charge such as by canceling, pausing, or updating the service, or an option allowing the user to update the payment method for the service associated with the subscription type recurring transaction; [0062], financial institution 220 may process the incoming charges for each corresponding user and then the server 230 may store the transaction data as historical transaction data in user transaction data storage 222 associated with the financial institution in step 305; [0065], Financial institution 220, for a user, may determine periodically, such as daily or responsive to a charge being received and processed to the user's electronic payment method for a service of a particular merchant, the probability that the historical transaction data, which includes past charges associated with the particular merchant, indicates that the past charges represent a subscription type recurring transaction that is expected to have an upcoming payment date in step 310; [0066], In step 310, the server(s) 230 may determine, based on a machine learning model 225 and the historical transaction data, a probability that historical transaction data of the user for past charges from a particular merchant indicates a subscription type recurring transaction for a service of the particular merchant; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge; If third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0071], server 230 may associate a block charges or allow charges option with the upcoming transaction, by adding the block charge option to the upcoming transaction data in upcoming transaction data memory 224; [0073], After adding the block charge option to the upcoming transaction data in step 340, server 230 may send upcoming transaction data to financial institution mobile app on user mobile device 202 in step 350; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0075], After adding the available subscription management option to the upcoming transaction data in step 340, server 230 sends upcoming transaction data to a financial institution mobile app on user mobile device 202 in step 350. In this case, the upcoming transaction data may include expected upcoming charge date, expected upcoming charge amount, identity of the merchant, expected transaction description of upcoming charge, regular cadence of the charge, and the subscription management options available to the user to manage the subscription type service; [0076], in step 355 when the user 201 accesses their account associated with their electronic payment method (e.g., credit account) on the financial mobile app on mobile device 202, the mobile app may display upcoming transactions, which are subscription type and any available options for managing the subscriptions; [0080], If the user does not confirm they wish to block charges then control may return to step 355; [0081], If the user does not confirm they wish to confirm the service management alter instruction (step 369: no), then control may return to step 355);
(ii) the Remote Connection GUI comprises (A) a transfer destination identification for a remote network that implements a remote connection, (B) a control component, and (C) remote connection transfer data (Srihari Figs. 1-11; [0070], if third party intermediary 240 supports one or more subscription management options, the third party intermediary may send a notice of the available subscription management options to server 230. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0074], server 230 adds the available subscription management options from the third party intermediary to the upcoming transaction data in upcoming transaction data memory 224; [0076] Following step 350 (taking either pathway from step 335), in step 355 when the user 201 accesses their account associated with their electronic payment method (e.g., credit account) on the financial mobile app on mobile device 202, the mobile app may display upcoming transactions, which are subscription type and any available options for managing the subscriptions. An illustrative user interface screen 600 in the mobile app displaying the upcoming transactions for a credit card is shown in FIG. 6A; [0077], On screen 600, upcoming transactions (recurring transactions) as may be identified as upcoming bills 610 may be listed separately from recent transactions for the user to view. In this example, three upcoming transactions are listed with their corresponding upcoming transaction data. For the second upcoming bill listed, the merchant name 610, expected upcoming charge amount 625, expected upcoming charge date 630, and recurring charge period (regular cadence) 635 may be displayed on screen 600. The upcoming bills listed may be presented to include the next three expected upcoming charges, or one, all or less than all of the expected upcoming charges, which may be limited based on the available screen real estate. Also, on the display next to the expected upcoming charge amount 625 may be three dots ( . . . ) as shown on screen 600. By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription);
(b) establish a secure communication session with the remote network (Srihari Figs. 1-11; [0005], Aspects described herein may address these and other problems, and generally improve user convenience by allowing a user, via an application executing on a mobile device, to manage a service from a merchant that has been determined, by the financial institution applying a machine learning model to historical transaction data of a user for the service, to be a recurring transaction. In this case, a user can manage recurring transactions (e.g., subscriptions) without the need to call or log on to the merchant's website; [0058], According to an illustrative operation of the system of FIG. 2, server(s) 230 such as computing device(s) (e.g., computing device 101) of financial institution 220 may receive a transaction stream 210 from a payment processor in step 300, which provides customer transaction data for incoming charges from merchants to an electronic payment method of a user (customer); [0060], The transaction data may comprise a merchant identifier field that indicates the name of the merchant and/or a merchant identifier (e.g., a numeric code) that may be used to identify the merchant associated with the incoming charge, a merchant category code (MCC), the amount of the charge, the date of the charge, and a transaction description of the charge; [0070], In step 335, server 230 may send, to a service provider API 242 of third party intermediary 240, a query asking what subscription management options are available for the service of the merchant corresponding to the upcoming transaction charge)
and (c) when the end user selects the control component, transmit a command to the remote network that implements the remote connection, wherein the remote network processes the command to (i) modify remote connection data stored to the remote network, or (ii) cause the remote network to return remote connection data that is transmitted to the end user computing device for display on the Remote Connection GUI (Srihari Figs. 1-11; [0007], receiving, by the application and via second user input, a reactivation instruction to reactivate the subscription type service, and sending, via the third party intermediary to the corresponding merchant, the reactivation instruction to reactivate the subscription type service; [0045], A customer of the financial institution may select a subscription management option, and subscription management instruction may be sent, via the third party intermediary, to the merchant. Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, upgrade or downgrade subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellation, and resubscribe; [0059], online video streaming; [0070], Subscription management options that may be provided include options to allow a user to cancel subscriptions and recurring payments, change (e.g., upgrade or downgrade) subscription plans, pause and resume subscriptions, update payment methods for subscriptions, and receive real-time offers at time of cancellations, and offers to resubscribe after cancellation; [0077], By user selection of three dots region 640, via a user input (e.g., tap, point and click, voice or other known input method) to mobile device 202, a menu may appear providing a list of one more options for managing the subscription; [0078], As shown illustrated in FIG. 6B, screen 660 may appear in response to the user input and provide an option 670 which the user may select. In step 360, the mobile app determines (e.g., detects) whether the user 202 has selected the option. If the user does not select any option (step 360: no), it may be that they have exited the display screen displaying the option in step 362; [0081], If the selected option corresponds to a subscription management option available from the third party intermediary such as by the user selecting the “cancel service” option 670 on screen 660 in FIG. 6B, the mobile app may display a confirmation screen in step 369 similar to screen 700 shown in FIG. 7; [0082], In the event, the user selects to continue with the alter instruction in step 369, then the alert instruction may be sent to server 230, which in turns may continue with the optional steps 375, 380 and 385 as shown in dotted box 370 or may skip steps 375, 380 and 385 in dotted box 370, and send the instruction to third party intermediary 240 in step 390; [0083], in FIG. 6B, based on the user selecting the “cancel service” option, a form may be provided to the user as illustrated on screen 680. The form may request user 201 to enter their name, email associated with their service account with the merchant and an authorization for financial institution 200 to cancel the service as requested by the user. Upon submission of the form confirming user cancellation of the service and providing financial institution authorization, the mobile app sends the form to server 230, which stores the authorization form in customer consent memory 226; [0084], Upon receiving a cancel instruction or pause instruction in step 360, server 230 may store user the corresponding cancellation data or pause in user cancellation and pause data store 228; [0085], In an example, in which user 201 selects to pause service in step 360, which is a service management option of the third party intermediary, prior to confirming the pause instruction in step 369, the mobile app may display screen 810, as shown in FIG. 8A, prompting user 201 to select the duration of the pause of service; [0086], By selecting three dots region 950 next to canceled service 930, the user may be presented with a subscription management option to “resubscribe to service”; [0087], in which user 201 selects to update their payment method in step 360, which is a service management option of the third party intermediary, prior to confirming the updated payment method instruction in step 369, the mobile app may display a screen 820, as shown in FIG. 8B, prompting user 201 to provide, for example, updated account information (e.g., virtual card number, credit card number, card expiration date, security code); [0089], after receiving confirmation of the alter instruction in step 369, the mobile app may present the user with a service update screen similar to screen 820 in FIG. 8B along with selection regions similar to 850 and 860, but tailored for a user updating their service type. As in the offer example, the user may select an option to update their service plan by selecting a service option and selecting an accept update region or decline to change/update their service plan and continue to cancel (or pause) service by selecting a decline region on the user interface of the mobile app; [0090], If the user has selected to accept the promotional offer or update their service plan in step 380, the mobile app sends an updated alter instruction corresponding to the accepted promotional offer or updated service plan to server 230. Server 230 may send the updated alter instruction, via third party intermediary APIs including service management functions API 244. Third party intermediary 240 then sends the updated alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385; [0091], If the user has selected to decline the promotional offer or not update their service plan in step 380, the mobile app sends the original alter instruction (e.g., cancel service, pause service) to server 230 as part of step 390. Server 230 may send the original alter instruction to third party intermediary 240, via third party intermediary APIs including service management functions API 244 as further part of step 390; [0092], Third party intermediary 240 may then send the original alter instruction to the appropriate merchant, such as merchant A 255, merchant B 265, or merchant C 275 in step 385. After receiving a cancel instruction, server 230 may store user cancellation data in user cancellation and pause data store 228; [0093], the merchant may respond to the third party intermediary with a message that the service may not be cancellable or is only cancellable by payment of early termination fee, or has been successfully executed; server 230 can send a notification to the user regarding status of their cancel request. Notification may be sent to any or all of the user's mobile app; [0095], The financial institution may maintain an inactive (e.g., paused, canceled, blocked) service list with the merchant identifier and user information in user cancellation and pause data store 228 and update that list each time a new service becomes inactive or a previously inactive service is reactivated. The list may be forwarded by server 230 to the user's mobile app for display to user 201 on the screen of mobile device 202; [0096], An example screen may include a list of upcoming transactions and a list of inactive subscription services such as illustrated in FIG. 9)
However, Srihari fails to expressly disclose (a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI. In the same field of endeavor, Evans teaches:
(a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI (Evans 1-4; [0029], The banking client application 214 may be a server-based application executable on the user device 102. In this regard, the user 101 may download the banking client application 214 prior to usage, or the banking client application 214 may be pre-installed (e.g., by a manufacturer, distributor, service provider, or the like) on the user device 102. In another arrangement, the banking client application 214 is coded into the memory 206 of the user device 110. In still another arrangement, the banking client application 214 is a web-based interface application. In this case, the user 101 logs onto or otherwise accesses the web-based interface. In this regard, the banking client application 214 may be supported by a separate computing system comprising one or more servers, processors, network interface modules, and/or the like, that transmit the application for use to the user device 102; [0054], Referring now to FIG. 3A, in some arrangements, the interactive display 300 presents a list 305 of the subscription (or membership) based goods and services identified by the usage analysis circuit 244; [0055], Referring now to FIG. 3B, in some arrangements, the interactive display 300 presents a details page 320 in response to the user selecting one of the interactive elements 310 corresponding to the details button shown in FIG. 3A; [0056], the interactive element 330 may be selected by the user to suspend (e.g., assuming that the merchant allows the subscription to be suspended) the subscription (or membership) associated with the merchant (e.g., Netflix); [0057], in FIG. 3C, the alternative options page includes interactive elements 350 for selecting one of the subscription plans, a modify button 344 to modify the subscription plan according to the selected plan indicated by the select button 350, and a back button 360 to return to the previous page)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have incorporated (a) transmit interface assembly instructions to an end user computing device in response to an interface request received from the end user computing device, wherein (i) the interface assembly instructions comprise executable software code that, when executed by the end user computing device, cause the end user computing device to display a Remote Connection GUI as suggested in Evans into Srihari. Doing so would be desirable because the present disclosure relates generally to the field of systems and methods for automatically identifying subscription-based (or membership-based) goods and services that are in disuse (or not used) and automatically managing the subscription (or membership) based on the disuse (see Evans [0001]). Users may forget to cancel the subscription (or membership), especially when recurring payments to the merchants are scheduled to automatically occur, which can lead to payments for goods or services that are no longer used. Further, merchants may exacerbate the problem by making it difficult or time consuming to cancel the subscription (or membership), since a large source of income for such subscription-based goods and services is generated from recurring payments received from the users regardless of whether the goods or services are being used. Thus, even if the user desires to cancel the subscription, the user may become frustrated with the cancellation process, which can cause delays or even forego cancellation even though the goods or services are disused (see Evans [0002]). Accordingly, systems and methods for automatically identifying goods and services that are disused (or not used) to enable efficient management of subscriptions (or memberships) associated with the goods and services may be desired (see Evans [0003]). Additionally, the system of Evans would improve the system of Srihari, by providing a plurality off different options for a user to request to access the transaction data, such as an app or a web-based interface provided by a server (see Evans [0029]). Providing a plurality of access options would better allow the user to utilize a preferred interaction modality and enable the user to maintain access to the system on devices where the user may be unable or unwilling to install a specific application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Villar (US 20240214459 A1) see Figs. 1-8 and [0103-0122].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN T REPSHER III whose telephone number is (571)272-7487. The examiner can normally be reached Monday - Friday, 8AM-5PM EST.
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, Jennifer Welch can be reached at (571) 272-7212. 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.
/JOHN T REPSHER III/ Primary Examiner, Art Unit 2143
Prosecution Insights