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
Claims 1, 6, 8-10, 13-15, 18, and 20 are objected to because of the following informalities:
Claims 1, 13, and 18 recite ‘the transmission’; however, it should recite - - a transmission - -.
Claim 1 recites ‘the selection’; however, it should recite - - a selection - -.
Claims 6, 8, 10, 14, 15, and 20 recite ‘the operation’; however, it should recite - - an operation - -.
Claim 9 recites ‘an end user computing device’; however, it should recite - - the end user computing device - -.
Claim 13 recites ‘the remote connection’; however, it should recite - - a remote connection - -.
Claim 13 recites ‘the plurality of remote networks’; however, it should recite - - a plurality of remote networks - -.
Claim 18 recites ‘by an end user’; however, it should recite - - by the end user - -.
Claim 18 recites ‘to an end user computing device’; however, it should recite - - to the end user computing device - -.
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, 13, and 18, the claims recite “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
Claim 1 further recites “transmit a command to a first remote network that implements a first remote connection in response to the selection of a function control component”. It is unclear whether “that implements a first remote connection” is intended to modify the command or the first remote network. It is unclear whether “in response to the selection of a function control component” is intended to modify the transmitting, the command, the first remote network, or the first remote connection. For the purposes of examination, this limitation is interpreted as: transmit a command to a first remote network, wherein a first remote connection is implemented, wherein in response to the selection of a function control component
Regarding claims 2-12, 14-17, 19, and 20, claims 2-12, 14-17, 19, and 20 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-7, 9, 13, and 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 11-14, and 16-20 of application 18918628 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:
18918651 (Instant Application)
18918628
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:
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:
(a) determine that transfer activity data comprises transfers conducted as part of a plurality of remote connections, wherein each of the remote connections is configured to enable the transmission of remote connection data between an end user computing device and a remote network
(b) establish a secure communication session with each of the remote networks; and
(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;
(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.
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.
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 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 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 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 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 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 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 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 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 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 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 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 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
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 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:
Claim 20) 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:
(a) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, (iii) is implemented by a remote provider, and (iv) requires periodic resource transfers approved by an end user to maintain the remote connection
(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
(b) establish a secure communication session with the remote network; and
(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
(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
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:
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:
(a) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, and (iii) is implemented by a remote provider;
(b) establish a secure communication session with each of the remote networks;
(c) receive remote connection transfer data from the remote network;
(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
(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;
(iii) the interface assembly instructions are transmitted to an end user computing device;
(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
(e) receive a command in response to the end user selecting a control component; (f) transmit the command to a first remote network.
(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.
Regarding claim 1, in the same field of endeavor, Srihari teaches (a) determine that transfer activity data comprises transfers conducted as part of a plurality of remote connections, wherein each of the remote connections is configured to enable the transmission of remote connection data between an end user computing device and a remote network (Srihari Figs. 1-11; [0045-0049], [0062-0066], [0070-0077]). 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 13, in the same field of endeavor, Srihari teaches (a) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, (iii) is implemented by a remote provider, and (iv) requires periodic resource transfers approved by an end user to maintain the remote connection (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) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, (iii) is implemented by a remote provider, and (iv) requires periodic resource transfers approved by an end user to maintain the remote connection 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 20, in the same field of endeavor, Srihari teaches (a) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, and (iii) is implemented by a remote provider (Srihari Figs. 1-11; [0045-0049], [0062-0066], [0070-0077], [0081-0091]); (b) establish a secure communication session with each of the remote networks (Srihari Figs. 1-11; [0005], [0058], [0060], [0070]); (c) receive remote connection transfer data from the remote network ((Srihari Figs. 1-11; [0045-0046], [0048-0049], [0070-0075]). It would have been obvious to one of ordinary skill in the art at the time the invention was made to have incorporated (a) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, and (iii) is implemented by a remote provider; (b) establish a secure communication session with each of the remote networks; (c) receive remote connection transfer data from the remote network 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-5, 8, 9, 11, and 13-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 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 (Srihari Figs. 1-11; abs. providing a user with options to manage the service; [0039], These good or services may include subscriptions to online streaming media services; [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) determine that transfer activity data comprises transfers conducted as part of a plurality of remote connections, wherein each of the remote connections is configured to enable the transmission of remote connection data between an end user computing device and a remote network (Srihari Figs. 1-11; [0039], These good or services may include subscriptions to online streaming media services, fitness club memberships, food delivery services, online gaming services, or any other goods or services to which a user may create a subscription and pay incoming charges for the service on a recurring basis; [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; streaming media subscription services like HBO Max; [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-0071], 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; [0073-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);
(b) establish a secure communication session with each of the remote networks (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) 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 (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: (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 16, the claim contains substantially similar limitations to those found in claim 2. Consequently, the claim is rejected for the same reasons.
Regarding claim 3, 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 17, 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 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 5, 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)
Regarding claim 8, Srihari teaches all the limitations of claim 1, further comprising:
wherein the processor executes a further operation of searching transfer destination identifications for keywords that match known remote connections as part of the processor performing the operation to determine whether the transfer activity data comprises transfers conducted as part of the plurality of remote connections (Srihari Figs. 1-11; [0017], the transaction details for one or more of the past charges may comprise a transaction description field, and the machine learning model may be further configured to perform steps comprising determining, based on the transaction description field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with one or more key words describing the past charges as 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; [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 corresponds to a recurring transaction; [0098-0099], In step 410, the server 230 may determine one or more websites to scrape based on use of a browser extension that is configured to detect one or more keywords associated with subscription type recurring transactions. For example, after the browser extension detects that a web page of a website associated with a merchant has been accessed, the browser extension may scrape one or more web pages to determine whether web pages of the websites comprise one or more key words associated with a subscription type recurring transaction for the merchant. For example, the browser extension may detect that a user is at a web page associated with a transaction (e.g., a subscription page, a payment page, and/or a service renewal page associated with the merchant). The determination that a user is at a web page associated with a transaction may be based on detection of one or more payment fields within a web page. Based on detecting the one or more payment fields, the browser extension may then search the web page for one or more key words associated with subscription type recurring transactions. For example, the browser extension may search for one or more key words comprising subscription, subscribe, preauthorized, recurring, transaction, renewal, payment, monthly, quarterly, weekly, biweekly, annual, and/or yearly; [0103], the machine learning model may receive input comprising key words (combinations of key words may form key phrases) from a web site of a merchant. The ground truth data may comprise sets of key words that are present in the transaction data (e.g., the transaction description field) of incoming charges that are subscription type recurring transactions. The machine learning model may be trained to determine the probability that historical charge data corresponds to a subscription type recurring transaction based on the extent to which the probability that historical charge data represents a subscription type recurring transaction corresponds to whether the historical charge data actually represents a subscription type recurring transaction; [0115], In step 1050, the machine learning model may determine, based on a transaction description field of the transaction data, that the probability of the past charges corresponding to a subscription type recurring transaction is positively correlated with one or more key words describing the past charges as a subscription type recurring transaction. For example, the machine learning model may receive historical transaction data in which the transaction description field indicates that the one or more past charge is for a “MONTHLY MAGAZINE SUBSCRIPTION PAYMENT” which includes the key words “monthly” and “subscription” which are associated with a subscription type recurring transaction. Based on the one or more key words comprising “monthly” and “subscription” the machine learning model may increase the probability of the past charges corresponding to a subscription type recurring transaction; see also [0077-0087], [0090-0096])
Regarding claim 9, Srihari teaches all the limitations of claim 1, further comprising:
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 (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 11, Srihari teaches all the limitations of claim 1, further comprising:
wherein: (a) the processor executes a further operation to generate activity instructions for execution by the end user computing device; and (b) 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 13, Srihari teaches the claim comprising:
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 (Srihari Figs. 1-11; abs. providing a user with options to manage the service; [0039], These good or services may include subscriptions to online streaming media services; [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) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, (iii) is implemented by a remote provider, and (iv) requires periodic resource transfers approved by an end user to maintain the remote connection (Srihari Figs. 1-11; [0039], These good or services may include subscriptions to online streaming media services, fitness club memberships, food delivery services, online gaming services, or any other goods or services to which a user may create a subscription and pay incoming charges for the service on a recurring basis; it may be difficult for a user to keep track of the services to which the user is currently subscribed; [0042], provide the user with an option to block charges from the merchant; [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; streaming media subscription services like HBO Max; [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-0071], 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; [0073-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);
(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 (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) 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 (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 14, Srihari teaches all the limitations of claim 13, further comprising:
wherein: (a) the system further comprises connection identification software code; and (b) the connection identification software code executes the operation to identify a plurality of remote connections by applying a set of rules to transfer activity data, wherein the set of rules determines transfer activity data that matches a known remote connection (Srihari Figs. 1-11; [0013], the one or more of the past charges comprise a card verification value (CVV) field, and the machine learning model may be further configured to perform steps comprising determining, based on the CVV field, that the probability of the one or more past charges being based on a subscription type recurring transaction is negatively correlated with the CVV field indicating that one or more of the past charge were based on a card present transaction; [0014], the transaction details for one or more of the past charges may comprise a payment method field, and the machine learning model may be further configured to perform steps comprising determining, based on the payment method field, that the probability of the past charges being based on a subscription type recurring transaction is negatively correlated with the payment method field indicating that the past charges are based on a card transaction using a card reader device or a mobile wallet transaction using a mobile device and a contactless point of sale system; [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; [0016], the transaction details for one or more of the past charges may comprise a recurring transaction field, and the machine learning model may be further configured to perform steps comprising determining, based on the recurring transaction field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with the recurring transaction field indicating that the past charges corresponded to a subscription type recurring transaction; [0017], the transaction details for one or more of the past charges may comprise a transaction description field, and the machine learning model may be further configured to perform steps comprising determining, based on the transaction description field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with one or more key words describing the past charges as a subscription type recurring transaction; [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-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; streaming media subscription services like HBO Max; [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; see also [0070-0075], [0077-0087], [0090-0096])
Regarding claim 15, Srihari teaches all the limitations of claim 13, further comprising:
wherein: (a) the system further comprises connection identification software code; and (b) the connection identification software code executes the operation to identify a plurality of remote connections by searching each of the transfer destination identifications for keywords that match a known remote connection (Srihari Figs. 1-11; [0017], the transaction details for one or more of the past charges may comprise a transaction description field, and the machine learning model may be further configured to perform steps comprising determining, based on the transaction description field, that the probability of the past charges being based on a subscription type recurring transaction is positively correlated with one or more key words describing the past charges as 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; [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 corresponds to a recurring transaction; [0098-0099], In step 410, the server 230 may determine one or more websites to scrape based on use of a browser extension that is configured to detect one or more keywords associated with subscription type recurring transactions. For example, after the browser extension detects that a web page of a website associated with a merchant has been accessed, the browser extension may scrape one or more web pages to determine whether web pages of the websites comprise one or more key words associated with a subscription type recurring transaction for the merchant. For example, the browser extension may detect that a user is at a web page associated with a transaction (e.g., a subscription page, a payment page, and/or a service renewal page associated with the merchant). The determination that a user is at a web page associated with a transaction may be based on detection of one or more payment fields within a web page. Based on detecting the one or more payment fields, the browser extension may then search the web page for one or more key words associated with subscription type recurring transactions. For example, the browser extension may search for one or more key words comprising subscription, subscribe, preauthorized, recurring, transaction, renewal, payment, monthly, quarterly, weekly, biweekly, annual, and/or yearly; [0103], the machine learning model may receive input comprising key words (combinations of key words may form key phrases) from a web site of a merchant. The ground truth data may comprise sets of key words that are present in the transaction data (e.g., the transaction description field) of incoming charges that are subscription type recurring transactions. The machine learning model may be trained to determine the probability that historical charge data corresponds to a subscription type recurring transaction based on the extent to which the probability that historical charge data represents a subscription type recurring transaction corresponds to whether the historical charge data actually represents a subscription type recurring transaction; [0115], In step 1050, the machine learning model may determine, based on a transaction description field of the transaction data, that the probability of the past charges corresponding to a subscription type recurring transaction is positively correlated with one or more key words describing the past charges as a subscription type recurring transaction. For example, the machine learning model may receive historical transaction data in which the transaction description field indicates that the one or more past charge is for a “MONTHLY MAGAZINE SUBSCRIPTION PAYMENT” which includes the key words “monthly” and “subscription” which are associated with a subscription type recurring transaction. Based on the one or more key words comprising “monthly” and “subscription” the machine learning model may increase the probability of the past charges corresponding to a subscription type recurring transaction; see also [0077-0087], [0090-0096])
Regarding claim 18, Srihari teaches the claim comprising:
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 (Srihari Figs. 1-11; abs. providing a user with options to manage the service; [0039], These good or services may include subscriptions to online streaming media services; [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) identify a plurality of remote connections, wherein each of the remote connections (i) has a transfer destination identification, (ii) is configured to enable the transmission of remote connection data between an end user computing device and a remote network, and (iii) is implemented by a remote provider (Srihari Figs. 1-11; [0039], These good or services may include subscriptions to online streaming media services, fitness club memberships, food delivery services, online gaming services, or any other goods or services to which a user may create a subscription and pay incoming charges for the service on a recurring basis; [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; streaming media subscription services like HBO Max; [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-0071], 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; [0073-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);
(b) establish a secure communication session with each of the remote networks (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);
(c) receive remote connection transfer data from the 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; [0046], 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-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; [0070-0071], 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; [0073-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);
(d) generate interface assembly instructions that comprise a plurality of transfer destination identifications, control components, and 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; [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)
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 (iii) the interface assembly instructions are transmitted to an end user computing device; (e) receive a command in response to the end user selecting a control component; (f) transmit the command to a first remote network (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; [0073-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; [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; [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; [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; [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 19, Srihari teaches all the limitations of claim 18, further comprising:
wherein the system further comprises a Remote Connection application programming interface (API) that, prior to transmitting the command to the first remote network, converts the command to a format 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 6, 7, 10, 12, and 20 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 6, Srihari teaches all the limitations of claim 11, further comprising:
wherein: (a) the system further comprises a machine learning model; and (b) the machine learning model performs the operation to determine that transfer activity data comprises transfers conducted through a plurality of remote connections (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 7, Srihari in view of Goldfield teaches all the limitations of claim 6. 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.
Regarding claim 10, Srihari teaches all the limitations of claim 9, further comprising:
wherein: (a) the system further comprises a machine learning model; and (b) the machine learning model performs the operation to classify the first 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; 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 12, Srihari teaches all the limitations of claim 11, further comprising:
wherein: (a) the system further comprises a machine learning model; and (b) the machine learning model performs 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 20, Srihari teaches all the limitations of claim 18, further comprising:
wherein (a) the system further comprises a machine learning model; and (b) the machine learning model performs the operation to identify a plurality of remote connections based on transfer activity data and end user data (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.
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