DETAILED ACTION
This office action is in response to the above identified application filed on December 30, 2025. The application contains claims 1-20.
Claims 1, 9, and 17 are amended
Claims 1-20 are pending
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 .
Response to Arguments
Applicant's arguments and amendments filed on December 30, 2025 have been fully considered and the objections and rejections are updated accordingly.
Claim Rejections - 35 USC § 112
In view of the amendments to the claims, the 35 USC § 112 rejections to claims 1-20 are withdrawn.
Claim Rejections - 35 USC § 103
In response to Applicant’s main argument on page 3 of Applicant’s Arguments/Remarks Made in an Amendment that “The cited references, including Caldwell and Harik, at most describe credential usage or identity verification, but do not teach maintaining or using cross-system identifier mappings to enable simultaneous access to multiple incompatible core systems within a single interface”, the examiner disagrees.
As discussed in details in the previous office action and as set forth in the 35 U.S.C. 103 rejections below, Caldwell (US 20200067900 A1) teaches “simultaneous access to multiple incompatible core systems within a single interface” in Fig. 7; [0131]; Fig. 1; [0045], where downloading data concurrently from the plurality of different third-party service providers 108 explicitly teaches “simultaneous … access” to the different third-party systems. While Caldwell also implicitly teaches a mechanism that links each user to the various credentials by that user to access different third-party systems, Harik et al. (US 20080155669 A1) was cited to explicitly teach the “cross-system identifier mappings” in Fig. 1; [0014], where after gaining access to authenticated accounts by presenting the corresponding proper credentials (step 102), e.g., presenting the username and password, the credentials are captured and recorded by the website (step 103) and linked with other linked accounts (step 104), wherein the linking of multiple authenticated accounts on different information systems corresponds to "cross-system mappings between user identifiers across incompatible core processing systems", and the website capturing and recording the credentials indicates "store".
As such, the 35 U.S.C. 103 rejections are updated and maintained. Please refer to the updated 35 U.S.C. 103 rejections below for details.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Caldwell (US 20200067900 A1), in view of Harik et al. (US 20080155669 A1), and in further view of Cottingham et al. (US 20210117942 A1).
With regard to claim 1,
Caldwell teaches
an apparatus (Abstract), comprising:
a processor ([0039]: a processor);
a memory ([0039]: a memory) that stores code executable by the processor to:
authenticate a user with electronic credentials for the user (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
query a first core processing system to determine a first identifier for a first account for the user with the first core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the third party service provider, which involves looking up and locating the user’s identity in the third party service provider to ensure its validity, i.e., “query a first core processing system”, wherein the third party service provider corresponds to “a first core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a first identifier for a first account for the user”);
query a second core processing system to determine a different identifier for a different account for the user with the second core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the different third party service provider, which involves looking up and locating the user’s identity in the different third party service provider to ensure its validity, i.e., “query a second core processing system”, wherein the different third party service provider corresponds to “a second core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a different identifier for a different account for the user”);
access the first account for the user with the first core processing system using the first identifier for the user from the identity repository and the electronic credentials for the first account to receive data associated with the first account (Fig. 7; [0130]; [0068]-[0070]: after successfully authenticating the user, the direct access module 204 may download data associated with the user (e.g., from a user's account or the like) from the server 108, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the first identifier” that has no patentable weight, because no matter where “the first identifier” is originally from, the function recited in this limitation would have performed the same);
access the different account for the user with the second core processing system using the different identifier for the user from the identity repository and the electronic credentials for the different account to receive data associated with the different account (Fig. 7; [0130]; [0068]-[0070]: after successfully authenticating the user, the direct access module 204 accesses data associated with the different account the user has with the different third party service provider in the same manner as discussed with respect to the first account above, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the different identifier” that has no patentable weight, because no matter where “the different identifier” is originally from, the function recited in this limitation would have performed the same);
provide simultaneous, real-time access to both the data associated with the first account and the data associated with the different account within a single electronic interface (Fig. 7; [0131]: the direct access module 204 aggregates 708 the downloaded 706 data from the plurality of different third party service providers 108, and an interface module 206 provides 710 the aggregated 708 data to the user, wherein “real-time access” is taught by the fact that the downloaded data is made available as soon as it is acquired. Fig. 1; [0045]: downloading data concurrently teaches “simultaneous … access”);
Caldwell does not explicitly teach
store the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems;
determine previously-stored electronic credentials for the user for the first account and the different account;
migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Harik teaches
store the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems (Fig. 1; [0014]: after gaining access to authenticated accounts by presenting the corresponding proper credentials (step 102), e.g., presenting the username and password, the credentials are captured and recorded by the website (step 103) and linked with other linked accounts (step 104), wherein the linking of multiple authenticated accounts on different information systems corresponds to "cross-system mappings between user identifiers across incompatible core processing systems", and the website capturing and recording the credentials indicates "store". Fig. 4; [0017]: store the encrypted credentials in an encrypted record (e.g., encrypted credentials record 403-1) in an encrypted file (e.g., encrypted file 402), wherein "store" is explicitly taught and an encrypted file corresponds to "an identity repository");
determine previously-stored electronic credentials for the user for the first account and the different account (Fig. 1; [0014]: on a subsequent visit to the website (step 105), when the user supplies credentials to any one of the systems and gains access (step 106), the website accesses its records for the user's credentials for accounts in the other systems or networks, and gains access to these other accounts on the user's behalf (step 107));
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell to incorporate the teachings of Harik to store the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems and determine previously-stored electronic credentials for the user for the first account and the different account. Doing so would allow a user having access to multiple selected accounts to be authenticated for all such accounts in a simple and secure manner as taught by Harik ([0003]).
Caldwell and Harik do not teach
migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Cottingham teaches
migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity (Fig. 7I; [0083]; Fig. 7J; [0084]; Fig. 7K; [0085]: select bank accounts to migrate in Fig. 7I and click "Finish" button 764 in Fig. 7J to migrate the selected bank accounts to get the results of migration shown in Fig. 7K, wherein the "Finish" button 764 in Fig. 7J corresponds to “a displayed interface element” that provides the user an option to “opt-in” for account migration. Since the migration does not happen until the "Finish" button is selected by a user, the migration between the selected accounts is “delayed until user interaction”. As different users may select the “Finish” button at different times, migration operations at a particular time are initiated only for the users who have opted in, i.e., “selectively initiated for users”, and migration operations for different users are naturally distributed over time based on when they opt in, i,e., “authenticated user activity”, a teaching that is consistent with the relevant disclosure in paragraph [0036] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell and Harik to incorporate the teachings of Cottingham to migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity. Doing so would provide an automated portal to migrate one or more relationships with one entity to another entity that the user may wish to migrate as taught by Cottingham ([0004]-[0013]).
With regard to claim 2,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 1, wherein the code is further executable by the processor to:
receive a first set of electronic credentials; authenticate the user with the first core processing system using the first set of electronic credentials (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
receive a different set of electronic credentials; authenticate the user with the second core processing system using the different set of electronic credentials (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
Harik further teaches
associate the first set of electronic credentials with the user and with the first account; store the first set of electronic credentials for subsequent access to the first core processing system on behalf of the user (Fig. 1; [0014]: the credentials associated with accounts on different information systems are captured and recorded by the website (step 103), and on a subsequent visit to the website (step 105), the website accesses its records for the user's credentials for accounts in the other systems or networks, and gains access to these other accounts on the user's behalf (step 107), i.e., the credentials are associated with the user and stored for subsequence access to the other accounts without the user having to provide the credentials);
associate the different set of electronic credentials with the user and with the different account; and store the different set of electronic credentials for subsequent access to the second core processing system on behalf of the user (Fig. 1; [0014]: this is taught in the same manner as discussed above).
With regard to claim 3,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 1, wherein the code is further executable by the processor to:
store the first identifier associated with the user and the first account; associate the first identifier with the data associated with the first account (Fig. 5A, 5B; [0121]-[0128]: user name credentials that include user name and user id, i.e., “the first identifier associated with the user and the first account” are associated with user data location, i.e., “the data associated with the first account”, and all the information is stored in the source code of the web browser extension);
store the different identifier associated with the user and the different account; and associate the different identifier with the data associated with the different account (Fig. 5A, 5B; [0121]-[0128]: this is taught in the same manner as discussed above).
With regard to claim 4,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 1, wherein the single electronic interface comprises one or more of an application programming interface accessible over a data network by one or more data recipients on behalf of the user and a graphical user interface displayed on an electronic display screen of a hardware computing device for the user (Fig. 7; [0131]; [0079]: an interface module 206 provides 710 the aggregated 708 data to the user (e.g., displaying the data on a hardware device 102 of the user), i.e., “a graphical user interface”).
With regard to claim 5,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 1, wherein the first core processing system is configured to process a first set of transactions for the user and to post updates to the first account based on the first set of transactions for the user and the second core processing system is configured to process a different set of transactions for the user and to post updates to the different account based on the different set of transactions for the user ([0079]: the data associated with a user comprises the user's financial transaction history (e.g., purchases and/or other financial transactions downloaded from one or more financial institutions 108 such as banks, credit unions, lenders, or the like), the interface module 206 may provide a personal financial management interface, with a list of transactions, one or more budgets, one or more financial goals, a debt management interface, a net worth interface, and/or another personal financial management interface wherein the user may view the user's downloaded and/or aggregated financial transaction history, and/or alerts or recommendations based thereon, wherein different banks process different sets of financial transactions and post them to their own separate bank accounts).
With regard to claim 6,
As discussed in claim 5, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 5, wherein the data associated with the first account comprises the first set of transactions and the data associated with the different account comprises the different set of transactions and both the first set of transactions and the different set of transactions are accessible within the single electronic interface ([0078]: the data associated with different accounts of the user comprises different sets of transactions with different banks. Fig. 7; [0131]; [0079]: the aggregated data is displayed on a hardware device of the user).
With regard to claim 7,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 1, wherein the first core processing system and the second core processing system execute on different hardware computing devices, process different types of accounts, and are accessible using different protocols ([0065]: receive different credentials from a user for different accounts of the user with different third party service providers 108 (e.g., different social networks, different photo sharing sites, different financial institutions) so that the aggregation module 104 may download, aggregate, and/or combine the user's data from the multiple different third party service providers 108. [0069]: use a different access protocol of a server).
With regard to claim 8,
As discussed in claim 1, Caldwell and Harik and Cottingham teach all the limitations therein.
Cottingham further teaches
the apparatus of claim 1, wherein the code is further executable by the processor to migrate the first account to the different account based at least in part on the data associated with the first account (Fig. 7I; [0083]: migrate bank accounts based on comparative information of the selected bank accounts to be migrated, which includes “the data associated with the first account”).
With regard to claim 9,
Caldwell teaches
a method (Abstract), comprising:
authenticating a user with electronic credentials for the user (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
querying a first core processing system to determine a first identifier for a first account for the user with the first core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the third party service provider, which involves looking up and locating the user’s identity in the third party service provider to ensure its validity, i.e., “query a first core processing system”, wherein the third party service provider corresponds to “a first core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a first identifier for a first account for the user”);
querying a second core processing system to determine a different identifier for a different account for the user with the second core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the different third party service provider, which involves looking up and locating the user’s identity in the different third party service provider to ensure its validity, i.e., “query a second core processing system”, wherein the different third party service provider corresponds to “a second core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a different identifier for a different account for the user”);
accessing the first account for the user with the first core processing system using the first identifier for the user from the identity repository and the electronic credentials for the first account to receive data associated with the first account (Fig. 7; [0130]; [0068]-[0070]: after successfully authenticating the user, the direct access module 204 may download data associated with the user (e.g., from a user's account or the like) from the server 108, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the first identifier” that has no patentable weight, because no matter where “the first identifier” is originally from, the function recited in this limitation would have performed the same);
accessing the different account for the user with the second core processing system using the different identifier for the user from the identity repository and the electronic credentials for the different account to receive data associated with the different account (, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the first identifier” that has no patentable weight, because no matter where “the first identifier” is originally from, the function recited in this limitation would have performed the same);
providing simultaneous, real-time access to both the data associated with the first account and the data associated with the different account within a single electronic interface (Fig. 7; [0131]: the direct access module 204 aggregates 708 the downloaded 706 data from the plurality of different third party service providers 108, and an interface module 206 provides 710 the aggregated 708 data to the user, wherein “real-time access” is taught by the fact that the downloaded data is made available as soon as it is acquired. Fig. 1; [0045]: downloading data concurrently teaches “simultaneous … access”);
Caldwell does not explicitly teach
storing the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems;
determining previously-stored electronic credentials for the user for the first account and the different account;
migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Harik teaches
storing the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems (Fig. 1; [0014]: after gaining access to authenticated accounts by presenting the corresponding proper credentials (step 102), e.g., presenting the username and password, the credentials are captured and recorded by the website (step 103) and linked with other linked accounts (step 104), wherein the linking of multiple authenticated accounts on different information systems corresponds to "cross-system mappings between user identifiers across incompatible core processing systems", and the website capturing and recording the credentials indicates "store". Fig. 4; [0017]: store the encrypted credentials in an encrypted record (e.g., encrypted credentials record 403-1) in an encrypted file (e.g., encrypted file 402), wherein "store" is explicitly taught and an encrypted file corresponds to "an identity repository");
determining previously-stored electronic credentials for the user for the first account and the different account (Fig. 1; [0014]: on a subsequent visit to the website (step 105), when the user supplies credentials to any one of the systems and gains access (step 106), the website accesses its records for the user's credentials for accounts in the other systems or networks, and gains access to these other accounts on the user's behalf (step 107));
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell to incorporate the teachings of Harik to store the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems and determine previously-stored electronic credentials for the user for the first account and the different account. Doing so would allow a user having access to multiple selected accounts to be authenticated for all such accounts in a simple and secure manner as taught by Harik ([0003]).
Caldwell and Harik do not teach
migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Cottingham teaches
migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity (Fig. 7I; [0083]; Fig. 7J; [0084]; Fig. 7K; [0085]: select bank accounts to migrate in Fig. 7I and click "Finish" button 764 in Fig. 7J to migrate the selected bank accounts to get the results of migration shown in Fig. 7K, wherein the "Finish" button 764 in Fig. 7J corresponds to “a displayed interface element” that provides the user an option to “opt-in” for account migration. Since the migration does not happen until the "Finish" button is selected by a user, the migration between the selected accounts is “delayed until user interaction”. As different users may select the “Finish” button at different times, migration operations at a particular time are initiated only for the users who have opted in, i.e., “selectively initiated for users”, and migration operations for different users are naturally distributed over time based on when they opt in, i,e., “authenticated user activity”, a teaching that is consistent with the relevant disclosure in paragraph [0036] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell and Harik to incorporate the teachings of Cottingham to migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity. Doing so would provide an automated portal to migrate one or more relationships with one entity to another entity that the user may wish to migrate as taught by Cottingham ([0004]-[0013]).
With regard to claim 10,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 9, further comprising:
receiving a first set of electronic credentials; authenticating the user with the first core processing system using the first set of electronic credentials (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
receiving a different set of electronic credentials; authenticating the user with the second core processing system using the different set of electronic credentials (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
Harik further teaches
associating the first set of electronic credentials with the user and with the first account; storing the first set of electronic credentials for subsequent access to the first core processing system on behalf of the user (Fig. 1; [0014]: the credentials associated with accounts on different information systems are captured and recorded by the website (step 103), and on a subsequent visit to the website (step 105), the website accesses its records for the user's credentials for accounts in the other systems or networks, and gains access to these other accounts on the user's behalf (step 107), i.e., the credentials are associated with the user and stored for subsequence access to the other accounts without the user having to provide the credentials);
associating the different set of electronic credentials with the user and with the different account; and storing the different set of electronic credentials for subsequent access to the second core processing system on behalf of the user (Fig. 1; [0014]: this is taught in the same manner as discussed above).
With regard to claim 11,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 9, further comprising:
storing the first identifier associated with the user and the first account; associating the first identifier with the data associated with the first account (Fig. 5A, 5B; [0121]-[0128]: user name credentials that include user name and user id, i.e., “the first identifier associated with the user and the first account” are associated with user data location, i.e., “the data associated with the first account”, and all the information is stored in the source code of the web browser extension);
storing the different identifier associated with the user and the different account; and associating the different identifier with the data associated with the different account (Fig. 5A, 5B; [0121]-[0128]: this is taught in the same manner as discussed above).
With regard to claim 12,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 9, wherein the single electronic interface comprises one or more of an application programming interface accessible over a data network by one or more data recipients on behalf of the user and a graphical user interface displayed on an electronic display screen of a hardware computing device for the user (Fig. 7; [0131]; [0079]: an interface module 206 provides 710 the aggregated 708 data to the user (e.g., displaying the data on a hardware device 102 of the user), i.e., “a graphical user interface”).
With regard to claim 13,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 9, wherein the first core processing system is configured to process a first set of transactions for the user and to post updates to the first account based on the first set of transactions for the user and the second core processing system is configured to process a different set of transactions for the user and to post updates to the different account based on the different set of transactions for the user ([0079]: the data associated with a user comprises the user's financial transaction history (e.g., purchases and/or other financial transactions downloaded from one or more financial institutions 108 such as banks, credit unions, lenders, or the like), the interface module 206 may provide a personal financial management interface, with a list of transactions, one or more budgets, one or more financial goals, a debt management interface, a net worth interface, and/or another personal financial management interface wherein the user may view the user's downloaded and/or aggregated financial transaction history, and/or alerts or recommendations based thereon, wherein different banks process different sets of financial transactions and post them to their own separate bank accounts).
With regard to claim 14,
As discussed in claim 13, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 13, wherein the data associated with the first account comprises the first set of transactions and the data associated with the different account comprises the different set of transactions and both the first set of transactions and the different set of transactions are accessible within the single electronic interface ([0078]: the data associated with different accounts of the user comprises different sets of transactions with different banks. Fig. 7; [0131]; [0079]: the aggregated data is displayed on a hardware device of the user).
With regard to claim 15,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the method of claim 9, wherein the first core processing system and the second core processing system execute on different hardware computing devices, process different types of accounts, and are accessible using different protocols ([0065]: receive different credentials from a user for different accounts of the user with different third party service providers 108 (e.g., different social networks, different photo sharing sites, different financial institutions) so that the aggregation module 104 may download, aggregate, and/or combine the user's data from the multiple different third party service providers 108. [0069]: use a different access protocol of a server).
With regard to claim 16,
As discussed in claim 9, Caldwell and Harik and Cottingham teach all the limitations therein.
Cottingham further teaches
the method of claim 9, further comprising migrating the first account to the different account based at least in part on the data associated with the first account (Fig. 7I; [0083]: migrate bank accounts based on comparative information of the selected bank accounts to be migrated, which includes “the data associated with the first account”).
With regard to claim 17,
Caldwell teaches
an apparatus (Abstract), comprising:
means for authenticating a user with electronic credentials for the user (Fig. 7; [0130]; [0064]-[0065]; [0068]: receive different credentials from a user for different accounts of the user with different third party service providers 108 and successfully authenticate with and access a server 108 of a third party service provider 108 with a user's electronic credentials);
means for querying a first core processing system to determine a first identifier for a first account for the user with the first core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the third party service provider, which involves looking up and locating the user’s identity in the third party service provider to ensure its validity, i.e., “query a first core processing system”, wherein the third party service provider corresponds to “a first core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a first identifier for a first account for the user”);
means for querying a second core processing system to determine a different identifier for a different account for the user with the second core processing system (Fig. 7; [0130]; [0064]-[0065]; [0068]: a direct access module 204 accesses 704 servers of the plurality of third party service providers 108 using the determined 702 electronic credentials. The authentication and accessing process inherently teaches this limitation because the process validates an identity of and/or an authorization of the user with the different third party service provider, which involves looking up and locating the user’s identity in the different third party service provider to ensure its validity, i.e., “query a second core processing system”, wherein the different third party service provider corresponds to “a second core processing system” and a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), etc. are examples of “a different identifier for a different account for the user”);
means for accessing the first account for the user with the first core processing system using the first identifier for the user from the identity repository and the electronic credentials for the first account to receive data associated with the first account (Fig. 7; [0130]; [0068]-[0070]: after successfully authenticating the user, the direct access module 204 may download data associated with the user (e.g., from a user's account or the like) from the server 108, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the first identifier” that has no patentable weight, because no matter where “the first identifier” is originally from, the function recited in this limitation would have performed the same);
means for accessing the different account for the user with the second core processing system using the different identifier for the user from the identity repository and the electronic credentials for the different account to receive data associated with the different account (, wherein “the electronic credentials” is taught in receiving different credentials from a user for different accounts of the user with different third party service providers 108 (discussed in Fig. 7; [0130]; [0064]-[0065]; [0068]), and “from the identity repository” is non-functional descriptive language describing “the first identifier” that has no patentable weight, because no matter where “the first identifier” is originally from, the function recited in this limitation would have performed the same);
means for providing simultaneous, real-time access to both the data associated with the first account and the data associated with the different account within a single electronic interface (Fig. 7; [0131]: the direct access module 204 aggregates 708 the downloaded 706 data from the plurality of different third party service providers 108, and an interface module 206 provides 710 the aggregated 708 data to the user, wherein “real-time access” is taught by the fact that the downloaded data is made available as soon as it is acquired. Fig. 1; [0045]: downloading data concurrently teaches “simultaneous … access”);
Caldwell does not explicitly teach
means for storing the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems;
means for determining previously-stored electronic credentials for the user for the first account and the different account;
means for migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Harik teaches
means for storing the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems (Fig. 1; [0014]: after gaining access to authenticated accounts by presenting the corresponding proper credentials (step 102), e.g., presenting the username and password, the credentials are captured and recorded by the website (step 103) and linked with other linked accounts (step 104), wherein the linking of multiple authenticated accounts on different information systems corresponds to "cross-system mappings between user identifiers across incompatible core processing systems", and the website capturing and recording the credentials indicates "store". Fig. 4; [0017]: store the encrypted credentials in an encrypted record (e.g., encrypted credentials record 403-1) in an encrypted file (e.g., encrypted file 402), wherein "store" is explicitly taught and an encrypted file corresponds to "an identity repository");
means for determining previously-stored electronic credentials for the user for the first account and the different account (Fig. 1; [0014]: on a subsequent visit to the website (step 105), when the user supplies credentials to any one of the systems and gains access (step 106), the website accesses its records for the user's credentials for accounts in the other systems or networks, and gains access to these other accounts on the user's behalf (step 107));
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell to incorporate the teachings of Harik to store the first identifier and the different identifier in an identity repository that maintains cross-system mappings between user identifiers across incompatible core processing systems and determine previously-stored electronic credentials for the user for the first account and the different account. Doing so would allow a user having access to multiple selected accounts to be authenticated for all such accounts in a simple and secure manner as taught by Harik ([0003]).
Caldwell and Harik do not teach
means for migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity.
Cottingham teaches
means for migrating user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity (Fig. 7I; [0083]; Fig. 7J; [0084]; Fig. 7K; [0085]: select bank accounts to migrate in Fig. 7I and click "Finish" button 764 in Fig. 7J to migrate the selected bank accounts to get the results of migration shown in Fig. 7K, wherein the "Finish" button 764 in Fig. 7J corresponds to “a displayed interface element” that provides the user an option to “opt-in” for account migration. Since the migration does not happen until the "Finish" button is selected by a user, the migration between the selected accounts is “delayed until user interaction”. As different users may select the “Finish” button at different times, migration operations at a particular time are initiated only for the users who have opted in, i.e., “selectively initiated for users”, and migration operations for different users are naturally distributed over time based on when they opt in, i,e., “authenticated user activity”, a teaching that is consistent with the relevant disclosure in paragraph [0036] of the specification).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Caldwell and Harik to incorporate the teachings of Cottingham to migrate user accounts between the first core processing system and the second core processing system in response to authenticated user activity, wherein the user activity comprises interacting with a displayed interface element to opt-in, such that migration is delayed until user interaction and migration operations are selectively initiated for users that opt in and distributed over time across a plurality of users based on authenticated user activity. Doing so would provide an automated portal to migrate one or more relationships with one entity to another entity that the user may wish to migrate as taught by Cottingham ([0004]-[0013]).
With regard to claim 18,
As discussed in claim 17, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 17, wherein the single electronic interface comprises one or more of an application programming interface accessible over a data network by one or more data recipients on behalf of the user and a graphical user interface displayed on an electronic display screen of a hardware computing device for the user (Fig. 7; [0131]; [0079]: an interface module 206 provides 710 the aggregated 708 data to the user (e.g., displaying the data on a hardware device 102 of the user), i.e., “a graphical user interface”).
With regard to claim 19,
As discussed in claim 17, Caldwell and Harik and Cottingham teach all the limitations therein.
Caldwell further teaches
the apparatus of claim 17, wherein the first core processing system is configured to process a first set of transactions for the user and to post updates to the first account based on the first set of transactions for the user, the second core processing system is configured to process a different set of transactions for the user and to post updates to the different account based on the different set of transactions for the user ([0079]: the data associated with a user comprises the user's financial transaction history (e.g., purchases and/or other financial transactions downloaded from one or more financial institutions 108 such as banks, credit unions, lenders, or the like), the interface module 206 may provide a personal financial management interface, with a list of transactions, one or more budgets, one or more financial goals, a debt management interface, a net worth interface, and/or another personal financial management interface wherein the user may view the user's downloaded and/or aggregated financial transaction history, and/or alerts or recommendations based thereon, wherein different banks process different sets of financial transactions and post them to their own separate bank accounts), the data associated with the first account comprises the first set of transactions, the data associated with the different account comprises the different set of transactions, and both the first set of transactions and the different set of transactions are accessible within the single electronic interface ([0078]: the data associated with different accounts of the user comprises different sets of transactions with different banks. Fig. 7; [0131]; [0079]: the aggregated data is displayed on a hardware device of the user).
With regard to claim 20,
As discussed in claim 17, Caldwell and Harik and Cottingham teach all the limitations therein.
Cottingham further teaches
the apparatus of claim 17, further comprising means for migrating the first account to the different account based at least in part on the data associated with the first account (Fig. 7I; [0083]: migrate bank accounts based on comparative information of the selected bank accounts to be migrated, which includes “the data associated with the first account”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to XIAOQIN HU whose telephone number is (571)272-1792. The examiner can normally be reached on Monday-Friday 7:00am-3:30pm.
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, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/XIAOQIN HU/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168