DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This communication is in response to the amendment filed on 07/07/2026.
Claims 1-20 are pending and are rejected.
Response to Arguments
Applicant's arguments, with respect to the rejections under 35. U.S.C §103 have been fully considered but they are not persuasive. Applicants are arguing in substance the following:
Argument to claims 1, 15, and 20: The prior art does not teach or suggest: “monitor a transaction activity pool for user account activity associated with the first user account, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information.”
Response to the arguments of claims 1, 15, and 20:
Babar’s discloses monitoring for user account activity via the maintenance start contract that determines whether an update to stored transaction account data is needed ([0066], fig. 3). Babar further expressly teaches that “the operations may be machine operations or any of the operations may be conducted or enhanced by AI or machine learning ([0083]). Thus, Babar itself contemplates that the monitoring and related operations may be performed or enhanced using a machine learning engine.
With respect to tracking activity “associated with the first hash value and without user account information,” Babar’s system operates on cryptographic account hashes rather than plaintext user account information for the purpose of locating and updating records ([0055], [0064], [0066]). The account hash functions as an immutable identifier corresponding to the user account and subsequent matching and updating operations are performed with reference to the hash values. One or ordinary skill in the art would understand that monitoring and tracking performed with respect to such has values inherently occurs without requiring the underlying user account information one the hash has been computed.
The Rejection is maintained accordingly.
Terminal Disclaimer has not been file, the Double Patenting rejections are also maintained.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1-3, 5-9, 11-16, and 18-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-3, 5-9, 11-16, and 18-20 of Patent No. US 11799658.
Present Application
Patent No. US 11799658
Claims 1, 15-15, and 20
compute, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account;
monitor a transaction activity pool for user account activity associated with the first user account, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information;
based on monitoring the transaction activity pool, append a user account activity entry to a record in a trackable log linked to the first hash value;
upon receiving an account termination instruction, determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance;
transmit instructions to the one or more computing locations to scrub account data associated with to the first user account; and
retain the record in the trackable log linked to the first hash value and account termination activity of the first user account that includes an indication that account data associated with the one or more computing locations has been scrubbed.
Claims 1, 16, and 20
receive, via the communication interface, user account information as part of an onboarding process in which a first user account is created; compute, using a cryptographic hash function, a first hash value associated with the first user account, wherein the first hash value provides a trackable, immutable code corresponding to the first user account; create a record in a trackable log linked to the first hash value; search, using a first activity descriptor, a transaction activity pool to locate a new activity, wherein the transaction activity pool comprises a plurality of activities that each comprise an activity descriptor and user account information, and wherein the new activity comprises first user account information and an activity descriptor matching the first activity descriptor; determine that the first user account information is associated with the first user account; upon determining that the first user account information is associated with the first user account, append the new activity to the record in the trackable log linked to the first hash value; monitor the transaction activity pool for additional user account activity associated with the first user account; based on monitoring the transaction activity pool, append additional user account activity to the record in the trackable log linked to the first hash value; receive, via the communication interface, a notification as part of an account termination process in which the first user account is terminated; determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance; and transmit instructions to the one or more computing locations to scrub account data associated with to the first user account.
Claim 2
receive a request to access one or more records in the trackable log.
Claims 2 and 16
receive a request to access one or more records in the trackable log; generate an asset lifecycle interface and one or more commands directing an enterprise computing device to display the asset lifecycle interface; and send, to the enterprise computing device, the asset lifecycle interface and the one or more commands directing the enterprise computing device to display the asset lifecycle interface.
Claim 3
receiving the request to access one or more records in the trackable log includes receiving a request, from the enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts.
Claim 3
receiving the request to access one or more records in the trackable log includes receiving a request, from the enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts.
Claim 5
computing the first hash value includes verifying that there is no existing hash value matching the first hash value.
Claim 5
computing the first hash value includes verifying that there is no existing hash value matching the first hash value.
Claim 6
upon determining that there is an existing hash value matching the first hash value, append an onboard activity data entry to the record in the trackable log linked to the existing hash value.
Claim 6
upon determining that there is an existing hash value matching the first hash value, append an onboard activity data entry to the record in the trackable log linked to the existing hash value.
Claim 7
computing the first hash value includes storing the first hash value and an onboard activity data entry to the record in the trackable log.
Claim 7
computing the first hash value includes storing the first hash value and an onboard activity data entry to the record in the trackable log.
Claim 8
monitoring the transaction activity pool includes receiving a notification of a user account activity upon a user computing device transmitting instructions to an enterprise computing device to perform the user account activity.
Claim 8
monitoring the transaction activity pool includes receiving a notification of a user account activity upon a user computing device transmitting instructions to an enterprise computing device to perform the user account activity.
Claim 9
monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account.
Claim 9
monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account.
Claims 11 and 18
compare one of the one or more hash values to one or more stored hash values in the trackable log; and
upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, add a new record in the trackable log, wherein the new record includes the one of the one or more hash values.
Claim 11
compare one of the one or more hash values to one or more stored hash values in the trackable log; and upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, add a new record in the trackable log, wherein the new record includes the one of the one or more hash values.
Claims 12 and 19
determine if a new activity in the transaction activity pool is indicative of a data change with the first user account;
upon determining that the new activity is not indicative of a data change, append the new activity to the record in the trackable log linked to the first hash value; and upon determining that the new activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the new activity, and add a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the new activity.
Claim 12
determine if the new activity is indicative of a data change, wherein appending the new activity to the record in the trackable log includes: upon determining that the new activity is not indicative of a data change, appending the new activity to the record in the trackable log linked to the first hash value; and upon determining that the new activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the new activity, and adding a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the new activity.
Claim 13
receiving the account termination instruction includes monitoring the activity transaction pool for a notification of account termination activity.
Claim 13
receiving the notification as part of the account termination process includes monitoring the activity transaction pool for a notification of account termination activity.
Claim 14
append account termination activity to the record in the trackable log linked to the first hash value.
Claim 14
append account termination activity to the record in the trackable log linked to the first hash value.
Although the claims at issue are not identical, they are not patentably distinct from each other because the claimed subject matter of the present applicant and that of Patent No. US 11799658 are substantially the same and the claimed subject matter of the present application would have been obvious to one of ordinary skill in the art based on the claimed subject matter of Patent No. US 11799658.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of Patent No. US 12166894.
Present Application
Patent No. US 12166894
Claims 1, 15-16, and 20
compute, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account;
monitor a transaction activity pool for user account activity associated with the first user account, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information;
based on monitoring the transaction activity pool, append an user account activity entry to a record in a trackable log linked to the first hash value;
upon receiving an account termination instruction, determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance;
transmit instructions to the one or more computing locations to scrub account data associated with to the first user account; and
retain the record in the trackable log linked to the first hash value and account termination activity of the first user account that includes an indication that account data associated with the one or more computing locations has been scrubbed.
Claims 1, 15, and 20
compute, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account; search a transaction activity pool to detect a new activity, wherein the new activity comprises first user account information; determine that the first user account information is associated with the first user account; upon determining that the first user account information is associated with the first user account, append the new activity to a record in a trackable log linked to the first hash value; monitor the transaction activity pool for additional user account activity associated with the first user account; based on monitoring the transaction activity pool, append additional user account activity to the record in the trackable log linked to the first hash value; receive, via the communication interface, a notification as part of an account termination process in which the first user account is terminated; determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance; and transmit instructions to the one or more computing locations to scrub account data associated with to the first user account.
Claim 2
receive a request to access one or more records in the trackable log.
Claims 2 and 16
receive a request to access one or more records in the trackable log; and send, to an enterprise computing device, an asset lifecycle interface and one or more commands directing the enterprise computing device to display the asset lifecycle interface.
Claim 3
receiving the request to access one or more records in the trackable log includes receiving a request, from the enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts.
Claim 3
receiving the request to access one or more records in the trackable log includes receiving a request, from the enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts.
Claim 4
the first hash value is computed as a result of receiving user account information as part of an onboarding process in which the first user account was created.
Claim 4
the first hash value is computed as a result of receiving user account information as part of an onboarding process in which the first user account was created.
Claim 5
computing the first hash value includes verifying that there is no existing hash value matching the first hash value.
Claim 5
computing the first hash value includes verifying that there is no existing hash value matching the first hash value.
Claim 6
upon determining that there is an existing hash value matching the first hash value, append an onboard activity data entry to the record in the trackable log linked to the existing hash value.
Claim 6
upon determining that there is an existing hash value matching the first hash value, append an onboard activity data entry to the record in the trackable log linked to the existing hash value.
Claim 7
computing the first hash value includes storing the first hash value and an onboard activity data entry to the record in the trackable log.
Claim 7
computing the first hash value includes storing the first hash value and an onboard activity data entry to the record in the trackable log.
Claim 8
monitoring the transaction activity pool includes receiving a notification of a user account activity upon a user computing device transmitting instructions to an enterprise computing device to perform the user account activity.
Claim 8
monitoring the transaction activity pool includes receiving a notification of a user account activity upon a user computing device transmitting instructions to an enterprise computing device to perform the user account activity.
Claim 9
monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account.
Claim 9
monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account.
Claims 10 and 17
computing one or more hash values from account information associated with respective events in the transaction activity pool.
Claims 10 and 17
computing one or more hash values from account information associated with respective events in the transaction activity pool; and comparing the one or more hash values to the first hash value, wherein the new activity is appended to the record in the trackable log linked to the first hash value upon determining a match between a hash value of the one or more hash values and the first hash value.
Claims 11 and 18
compare one of the one or more hash values to one or more stored hash values in the trackable log; and
upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, add a new record in the trackable log, wherein the new record includes the one of the one or more hash values.
Claims 11 and 18
compare one of the one or more hash values to one or more stored hash values in the trackable log; and upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, add a new record in the trackable log, wherein the new record includes the one of the one or more hash values.
Claims 12 and 19
determine if a new activity in the transaction activity pool is indicative of a data change with the first user account;
upon determining that the new activity is not indicative of a data change, append the new activity to the record in the trackable log linked to the first hash value; and upon determining that the new activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the new activity, and add a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the new activity.
Claims 12 and 19
determine if the new activity is indicative of a data change, wherein appending the new activity to the record in the trackable log includes: upon determining that the new activity is not indicative of a data change, appending the new activity to the record in the trackable log linked to the first hash value; and upon determining that the new activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the new activity, and adding a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the new activity.
Claim 13
receiving the account termination instruction includes monitoring the activity transaction pool for a notification of account termination activity.
Claim 13
receiving the notification as part of the account termination process includes monitoring the activity transaction pool for a notification of account termination activity.
Claim 14
append account termination activity to the record in the trackable log linked to the first hash value.
Claim 14
append account termination activity to the record in the trackable log linked to the first hash value.
Although the claims at issue are not identical, they are not patentably distinct from each other because the claimed subject matter of the present applicant and that of Patent No. US 12166894 are substantially the same and the claimed subject matter of the present application would have been obvious to one of ordinary skill in the art based on the claimed subject matter of Patent No. US 12166894.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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 (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 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 Barbar (US 20200193429 A1) in view of Fakhraie (US 11227064 B1).
Regarding claim 1, Barbar teaches a computing platform comprising:
at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to ([0082] a memory coupled to the processor for storing digital data):
compute, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account ([0055] merchant system generates an account hash. The account hash may comprise a one-way cryptographic hash of one or more of the users first name, the user last name, the transaction account number, the transaction account security code (immutable code));
monitor a transaction activity pool for user account activity associated with the first user account, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information ([0066], fig. 3, in response to maintenance smart contract 105 determining that an update to the stored transaction account data is needed (monitor… user account activity); [0083] the operations may be machine operations or any of the operations may be conducted or enhanced by artificial intelligence (AI) or machine learning);
based on monitoring the transaction activity pool, append a user account activity entry to a record in a trackable log linked to the first hash value ([0066] maintenance smart contract returns an updated account hash. The updated account hash may comprise the primary account hash corresponding to the past account hash located by maintenance smart contract);
Barbar does not explicitly teach
upon receiving an account termination instruction, determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance;
transmit instructions to the one or more computing locations to scrub account data associated with to the first user account; and
retain the record in the trackable log linked to the first hash value and account termination activity of the first user account that includes an indication that account data associated with the one or more computing locations has been scrubbed (col. 47, lines 44-50, devices from which customer data have been deleted or accounts deleted are marked as having been “scrubbed” by scrubbed icon 2104. As shown in customer interface 2100, the smart vehicle has been scrubbed. The customer may wish to scrub a device if, for example, the device is lost, stolen, sold, or donate).
Fakhraie teaches
upon receiving an account termination instruction (col. 7, lines 16-18, the message may indicate that the customer wishes to delete customer data stored in a database of the third-party computing system), determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance (col. 7, lines 21-22, the scrub command may identify the customer and/or the customer data to be deleted; col. 12, lines 9-11, the command may instruct the third-party platform to delete the data from all computer-readable storage media controlled by the third-party platform; col. 6, lines 24-27, the computing device may receive a request to link a third-party account of the customer with customer information stored at a service provider computing system (computing locations for each instance));
transmit instructions to the one or more computing locations to scrub account data associated with to the first user account (col. 7, lines 24-26, the scrub command may be transmitted to cause the third-party computing system to delete the customer data that may have been identified by the scrub command).
retain the record in the trackable log linked to the first hash value and account termination activity of the first user account that includes an indication that account data associated with the one or more computing locations has been scrubbed (col. 43, lines 8-16, deletion of a channel may dissociate the account from the channel and sever the link between the account and the deleted channel, such that subsequent steps may be required for relinking. In some implementations, deleting a channel may include deletion or deactivation of encryption keys and access tokens such that a new key and/or access token would need to be generated if a new link is to be established; col. 47, lines 44-50, fig. 21, devices from which customer data have been deleted or accounts deleted are marked as having been “scrubbed” by scrubbed icon 2104. As shown in customer interface 2100, the smart vehicle has been scrubbed. The customer may wish to scrub a device if, for example, the device is lost, stolen, sold, or donate).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar and Brown disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Regarding claim 2 , Barbar and Fakhraie teach the computing platform of claim 1, wherein Barbar further teaches the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
receive a request to access one or more records in the trackable log ([0061] merchant system receives a transaction request. The transaction request may comprise transaction data and merchant-stored transaction account data); and
send, to an enterprise computing device, an asset lifecycle interface and one or more commands directing the enterprise computing device to display the asset lifecycle interface ([0084] the computer system can include a display interface that forwards graphics, text, and other data from the communication infrastructure (or from a frame buffer not shown) for display on a display unit).
Regarding claim 3 , Barbar and Fakhraie teach the computing platform of claim 2, wherein Barbar further teaches receiving the request to access one or more records in the trackable log includes receiving a request, from the enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts ([0031], fig. 1, each issuer blockchain node 115 may be configured to allow the associated issuer system 110 access to blockchain network 101 and/or maintained accounts blockchain 107. Each issuer system 110 may comprise hardware and/or software components capable of performing cryptographic operations and generating the account hash).
Regarding claim 4 , Barbar and Fakhraie teach the computing platform of claim 1, wherein Barbar further teaches the first hash value is computed as a result of receiving user account information as part of an onboarding process in which the first user account was created ([0039] each merchant system 120 comprises a network interface; [0061], fig. 2, merchant system 120 receives an account on file request. For example, the account on file request may be received by merchant system 120 during a user registration process (a first user account is created). The account on file request may comprise user data (user account information)).
Regarding claim 5 , Barbar and Fakhraie teach the computing platform of claim 4, wherein Barbar further teaches computing the first hash value includes verifying that there is no existing hash value matching the first hash value ([0004] the maintenance smart contract may be configured to determine whether the account hash matches a stored primary account hash or a stored past account hash. Examiner note: It is noted that the determine whether includes both cases, match and not match).
Regarding claim 6 , Barbar and Fakhraie teach the computing platform of claim 5, wherein Barbar further teaches the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
upon determining that there is an existing hash value matching the first hash value, append an onboard activity data entry to the record in the trackable log linked to the existing hash value ([0004] update the merchant-stored transaction account data based on the updated transaction account data; [0059] issuer system 110 may generate updated account record data that includes the new transaction account data (append the new activity to a record in a trackable log) and the issuer ID corresponding to issuer system).
Regarding claim 7 , Barbar and Fakhraie teach the computing platform of claim 4, wherein Barbar further teaches computing the first hash value includes storing the first hash value and an onboard activity data entry to the record in the trackable log ([0071] Issuer system 110 may update the data record to comprise the updated transaction account data and the (new) account hash. In that regard, issuer system 110 may designate the (new) account hash as the primary account hash, and may change the designation on the previously stored account hash to be a past account hash).
Regarding claim 8 , Barbar and Fakhraie teach the computing platform of claim 1, wherein Barbar further teaches monitoring the transaction activity pool includes receiving a notification of a user account activity upon a user computing device transmitting instructions to an enterprise computing device to perform the user account activity ([0038] merchant system 120 may be configured to receive and process account on file requests. The account on file request may be received in response to a user desiring to store a transaction account (account activity) with merchant system 120).
Regarding claim 9 , Barbar and Fakhraie teach the computing platform of claim 1, Barbar does not explicitly teach wherein monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account.
Fakhraie teaches
monitoring the transaction activity pool includes receiving an indication that an enterprise computing device has decrypted enterprise data corresponding to the first user account (col. 19, lines 49-52, fig. 1, the network interface 112 is structured to encrypt data sent over the network 126 and decrypt received encrypted data).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so to enhance the security of sensitive customer information by better controlling its availability and retention.
Regarding claim 10 , Barbar and Fakhraie teach the computing platform of claim 1, wherein Barbar further teaches monitoring the transaction activity pool for user account activity includes:
computing one or more hash values from account information associated with respective events in the transaction activity pool ([0004] the system may generate an account hash comprising a cryptographic hash of at least one data element from a merchant-stored transaction account data); and
comparing the one or more hash values to the first hash value ([0004] determine whether the account hash matches a stored primary account hash or a stored past account hash),
wherein the user account activity is appended to the record in the trackable log linked to the first hash value upon determining a match between a hash value of the one or more hash values and the first hash value ([0059] in response to the associated issuer system 110 updating transaction account data and generating a new account hash, local issuer repository 117 may store the new account hash and designate the new account hash as the primary hash).
Regarding claim 11, Barbar and Fakhraie teach the computing platform of claim 10, wherein Barbar further teaches the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
compare one of the one or more hash values to one or more stored hash values in the trackable log ([0064] Maintenance smart contract may query the blockchain state repository to determine whether the account hash exists as a primary account hash (stored hash values) or a past account hash); and
upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, add a new record in the trackable log, wherein the new record includes the one of the one or more hash values ([0064] In response to locating the account hash as a past account hash (no match between the one of the one or more hash values and the one or more stored hash values), the merchant-stored transaction account data may need to be updated).
Regarding claim 12, Barbar and Fakhraie teach the computing platform of claim 1, wherein Barbar further teaches the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
determine if a new activity in the transaction activity pool is indicative of a data change with the first user account ([0064] determine whether the account hash exists as a primary account hash or a past account hash);
upon determining that the new activity is not indicative of a data change, append the new activity to the record in the trackable log linked to the first hash value; and upon determining that the new activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the new activity, and add a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the new activity ([0064] maintenance smart contract 105 may query the blockchain state repository to determine whether the account hash exists as a primary account hash or a past account hash. In response to locating the account hash as a primary account hash, the merchant-stored transaction account data may not need any updating (not indicative of a data change). In response to locating the account hash as a past account hash, the merchant-stored transaction account data may need to be updated (indicative of a data change); [0044] local merchant repository may store the new account hash and designate the new account hash as the primary hash).
Regarding claim 13, Barbar and Fakhraie teach the computing platform of claim 1, Barbar does not explicitly teach wherein receiving the account termination instruction includes monitoring the activity transaction pool for a notification of account termination activity.
Fakhraie teaches
wherein receiving the account termination instruction includes monitoring the activity transaction pool for a notification of account termination activity (col. 6, lines 5-10, Status information indicating (monitoring the activity transaction pool) whether the link is active or inactive may be transmitted to the computing device of the customer. The status information may be presented via the service provider client application running on the computing device. The scrub command may instruct the third-party computing system to delete the third-party account of the customer from the third-party computing system).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Regarding claim 14, Barbar and Fakhraie teach the computing platform of claim 1, Barbar does not explicitly teach wherein the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
append account termination activity to the record in the trackable log linked to the first hash value.
Fakhraie teaches
append account termination activity to the record in the trackable log linked to the first hash value (col. 38, lines 29-30, the customer may subsequently change his or her mind and wish that the saved account information (append account termination) be deleted).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Regarding claim 15, Barbar teaches a method comprising:
at a computing platform comprising at least one processor, a communication interface, and memory ([0082] a memory coupled to the processor for storing digital data):
computing, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account ([0055] merchant system generates an account hash. The account hash may comprise a one-way cryptographic hash of one or more of the users first name, the user last name, the transaction account number, the transaction account security code (immutable code));
based on monitoring a transaction activity pool for user account activity associated with the first user account, append user account activity to a record in a trackable log linked to the first hash value, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information ([0066], fig. 3, in response to maintenance smart contract 105 determining that an update to the stored transaction account data is needed (monitor… user account activity); [0083] the operations may be machine operations or any of the operations may be conducted or enhanced by artificial intelligence (AI) or machine learning; [0066] maintenance smart contract returns an updated account hash. The updated account hash may comprise the primary account hash corresponding to the past account hash located by maintenance smart contract);
receiving a request to access one or more records in the trackable log, wherein receiving the request to access one or more records in the trackable log includes receiving a request, from an enterprise computing device to access one or more user accounts, and identifying one or more hash values corresponding to the one or more user accounts ([0031], fig. 1, each issuer blockchain node 115 may be configured to allow the associated issuer system 110 access to blockchain network 101 and/or maintained accounts blockchain 107. Each issuer system 110 may comprise hardware and/or software components capable of performing cryptographic operations and generating the account hash);
Barbar does not explicitly teach
sending, to an enterprise computing device, an asset lifecycle interface and one or more commands directing the enterprise computing device to display the asset lifecycle interface that provide details on relationships between the one or more records in the trackable log.
Fakhraie teaches
sending, to an enterprise computing device, an asset lifecycle interface and one or more commands directing the enterprise computing device to display the asset lifecycle interface that provide details on relationships between the one or more records in the trackable log (col. 57, lines 21-28, the mobile application may track or otherwise determine whether certain activities have been performed through interaction with the user and the devices of the mobile device. The signals from the devices (e.g., GPS, microphone, etc.) of the mobile device may be received (via, e.g., an operating system of the mobile device) and processed by the application and/or by a remote server receiving data from the mobile device).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar and Brown disclosure, identify the relationship between stored users in database , as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Regarding claim 16, Barbar and Fakhraie teach the method of claim 15, Fakhraie further teaches:
upon receiving a termination account notification associated with the first user account, determining one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance (col. 7, lines 21-22, the scrub command may identify the customer and/or the customer data to be deleted; col. 12, lines 9-11, the command may instruct the third-party platform to delete the data from all computer-readable storage media controlled by the third-party platform; col. 6, lines 24-27, the computing device may receive a request to link a third-party account of the customer with customer information stored at a service provider computing system (computing locations for each instance));
transmit instructions to the one or more computing locations to scrub account data associated with to the first user account (col. 7, lines 24-26, the scrub command may be transmitted to cause the third-party computing system to delete the customer data that may have been identified by the scrub command); and
retain the record in the trackable log linked to the first hash value and account termination activity of the first user account that includes an indication that account data associated with the one or more computing locations has been scrubbed (col. 43, lines 8-16, deletion of a channel may dissociate the account from the channel and sever the link between the account and the deleted channel, such that subsequent steps may be required for relinking. In some implementations, deleting a channel may include deletion or deactivation of encryption keys and access tokens such that a new key and/or access token would need to be generated if a new link is to be established; col. 47, lines 44-50, fig. 21, devices from which customer data have been deleted or accounts deleted are marked as having been “scrubbed” by scrubbed icon 2104. As shown in customer interface 2100, the smart vehicle has been scrubbed. The customer may wish to scrub a device if, for example, the device is lost, stolen, sold, or donate).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar and Brown disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Regarding claim 17, Barbar and Fakhraie teach the method of claim 15, wherein Barbar further teaches monitoring the transaction activity pool for user account activity includes:
computing one or more hash values from account information associated with respective events in the transaction activity pool; and
comparing the one or more hash values to the first hash value ([0004] determine whether the account hash matches a stored primary account hash or a stored past account hash)),
wherein the user account activity is appended to the record in the trackable log linked to the first hash value upon determining a match between a hash value of the one or more hash values and the first hash value ([0059] in response to the associated issuer system 110 updating transaction account data and generating a new account hash, local issuer repository 117 may store the new account hash and designate the new account hash as the primary hash).
Regarding claim 18, Barbar and Fakhraie teach the method of claim 17, Barbar further teaches:
comparing one of the one or more hash values to one or more stored hash values in the trackable log ([0064] Maintenance smart contract may query the blockchain state repository to determine whether the account hash exists as a primary account hash (stored hash values) or a past account hash); and
upon determining that there is no match between the one of the one or more hash values and the one or more stored hash values, adding a new record in the trackable log, wherein the new record includes the one of the one or more hash values ([0064] In response to locating the account hash as a past account hash (no match between the one of the one or more hash values and the one or more stored hash values), the merchant-stored transaction account data may need to be updated).
Regarding claim 19, Barbar and Fakhraie teach the method of claim 15, further comprising:
determine if the user account activity is indicative of a data change ([0064] determine whether the account hash exists as a primary account hash or a past account hash), wherein appending the user account activity to the record in the trackable log includes:
upon determining that the user account activity is not indicative of a data change, appending the user account activity to the record in the trackable log linked to the first hash value; and upon determining that the user account activity is indicative of a data change, compute, using the cryptographic hash function, a second hash value associated with the user account activity, and adding a second record in the trackable log, wherein the second record includes the second hash value, the first hash value, and the user account activity ([0064] maintenance smart contract 105 may query the blockchain state repository to determine whether the account hash exists as a primary account hash or a past account hash. In response to locating the account hash as a primary account hash, the merchant-stored transaction account data may not need any updating (not indicative of a data change). In response to locating the account hash as a past account hash, the merchant-stored transaction account data may need to be updated (indicative of a data change); [0044] local merchant repository may store the new account hash and designate the new account hash as the primary hash).
Regarding claim 20, Barbar teaches the one or more non-transitory computer-readable media storing instructions that, when executed by a computing platform comprising at least one processor, a communication interface, and memory, cause the computing platform to:
compute, using a cryptographic hash function, a first hash value associated with a first user account, wherein the first hash value provides an immutable code corresponding to the first user account ([0055] merchant system 120 generates an account hash. The account hash may comprise a one-way cryptographic hash of one or more of the users first name, the user last name, the transaction account number (trackable), the transaction account security code (immutable code));
based on monitoring a transaction activity pool for user account activity associated with the first user account, append user account activity to a record in a trackable log linked to the first hash value, wherein monitoring the transaction activity pool includes using a machine learning engine to track activity associated with the first hash value and without user account information ([0066], fig. 3, in response to maintenance smart contract 105 determining that an update to the stored transaction account data is needed (monitor… user account activity); [0083] the operations may be machine operations or any of the operations may be conducted or enhanced by artificial intelligence (AI) or machine learning; [0066] maintenance smart contract returns an updated account hash. The updated account hash may comprise the primary account hash corresponding to the past account hash located by maintenance smart contract);
Barbar does not explicitly teach
upon receiving an account data inquiry associated with the first user account, determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance; and
retain the record in the trackable log linked to the first hash value and account inquiry activity of the first user account that includes an indication of account data associated with the one or more computing locations.
Fakhraie teaches
upon receiving an account data inquiry associated with the first user account (col. 7, lines 16-18, the message may indicate that the customer wishes to delete customer data stored in a database of the third-party computing system), determine one or more computing locations of account data linked to the first user account, wherein the one or more computing locations are determined based on identifying all instances in the trackable log linked to the first user account and associated computing locations for each instance (col. 7, lines 21-22, the scrub command may identify the customer and/or the customer data to be deleted; col. 12, lines 9-11, the command may instruct the third-party platform to delete the data from all computer-readable storage media controlled by the third-party platform; col. 6, lines 24-27, the computing device may receive a request to link a third-party account of the customer with customer information stored at a service provider computing system (computing locations for each instance)); and
retain the record in the trackable log linked to the first hash value and account inquiry activity of the first user account that includes an indication of account data associated with the one or more computing locations (col. 43, lines 8-16, deletion of a channel may dissociate the account from the channel and sever the link between the account and the deleted channel, such that subsequent steps may be required for relinking. In some implementations, deleting a channel may include deletion or deactivation of encryption keys and access tokens such that a new key and/or access token would need to be generated if a new link is to be established; col. 47, lines 44-50, fig. 21, devices from which customer data have been deleted or accounts deleted are marked as having been “scrubbed” by scrubbed icon 2104. As shown in customer interface 2100, the smart vehicle has been scrubbed. The customer may wish to scrub a device if, for example, the device is lost, stolen, sold, or donate).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Barbar and Brown disclosure, an instruction to delete user data, as taught by Fakhraie. One would be motivated to do so for managing customer data and customer preferences across a plurality of platforms.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANH NGUYEN whose telephone number is (571)270-0657. The examiner can normally be reached M-F.
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, Umar Cheema can be reached at 5712703037. 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.
/ANH NGUYEN/Primary Examiner, Art Unit 2458
Prosecution Insights