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 .
2. The amendment to claims 1-22, filed 12/25/2025, is acknowledged and considered for examination.
Claims 1, 3-10, 12-22 are pending.
Claims 21-22 are new. Claims 2 and 11 are cancelled by Applicant.
Claims 1, 10, and 19 are independent claims.
Priority
3. The current application has relationship to the following:
CON of 15604178, filing date 5/24/2017
CON of 17306529, filing date 5/3/2021
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
4. Claims 1, 3-10, 12-22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 11917050. Although the claims at issue are not identical, they are not patentably distinct from each other because of the claimed invention of the current application ‘641 is an obvious variation to the claimed invention as recited in US patent ‘050.
Claims 1-20 of the current application ‘641 recites similar features as to claims 1-16 of US Patent ‘050 the blockchain-based method, system and non-transitory computer readable medium comprising blockchain transactions associated with the one or more blockchain IDs for use to identify the blockchain transaction, generation of a trust profile, an indication of validity to perform the activity where determination of activity is authorized and transmit authorization t0 perform the activity. Although, the claimed invention of ‘641 are similar, there are small indifferences such to which broadens the current claimed invention from that to the claimed invention of ‘050. Claims 1-20 of the current application ‘641 are anticipated by claims 1-16 of US Patent ‘050. This is a non-provisional non-statutory double patenting rejection because the conflicting claims have been patented.
Response to Arguments
5. Applicant’s arguments with respect to claim(s) 1, 3-10, 12-22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments are moot as they are directed towards new limitations that are now addressed by Hanna in view of Gross, et al. rejection.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
6. Claim(s) 1, 3-10, 12-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hanna [US 20180374097] in view of Gross, et al [US 10997595].
As per claim 1: Hanna teaches a blockchain-based system, comprising:
a processor; and [Hanna: para 0075]
a memory storing computer-executable instructions that, when executed by the processor [Hanna: para 0075], cause the blockchain-based system to:
receive, via a network and from a computing device, a request to perform an activity associated with a user [Hanna: para 0017, 0062-0063; The “activity” being performed is not explicitly defined. Thus, regarding the limitation “request to perform an activity associate with a user”, where the request to perform an activity can broadly be in the form of a inquiry or query either to perform an activity such as verification/authentication process or verifying for online transactions, of the user. Examples of “perform an activity” may be a user identity verification request and responding with a user identity verification response comprising a verification level, subsequently performing a verification task - Para 0017. Another example, verifying users for online transactions, the distributed ledger may be queried – Para 0063], the request including a blockchain ID associated with the user; [Hanna: para 0002; a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records]
identify, from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Hanna: para 0002; pushing a verification level blockchain update record to the ledger. The “transaction” may broadly be in the form of a record to the ledger, as the ledger is part of the blockchain and includes information for identification]
generate, based on the one or more blockchain transactions, a trust profile of the user [Hanna: para 0033; an online user profile identity verification and authentication, to create a trusted online environment enabling secure e-commerce transactions and other online transactions. The system verify user identity such that such verified user identity may be subsequently used when transacting online. As such, the verified user identity associated to the profile suggest “a trust profile of the user”], the trust profile including a first authentication level to perform the activity; [Hanna: para 0017; a user identity verification request and responding with a user identity verification response comprising at least a verification level. Para 0042; verify online users in accordance with verification levels of increasing verification stringency, where subsequent online transactions is enabled depending on the verification levels of users]
determine that the first authentication level is less than a threshold; [Hanna: para 0016, 0042; a minimum verification threshold level within the ledger. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se]
**based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity; [**rejected under a secondary reference, discussion below]
determine, based on the indication of validity, that the request to perform the activity is authorized; and [Hanna: para 0063; verifying users for online transactions, the distributed ledger may be queried. When transferring electronic funds to a second user, a first user initially query the ledger to ascertain whether the second user is verified and to what level]
transmit, via the network, an authorization to perform the activity to the computing device. [Hanna: para 0059-0060; one example of transmitting an authorization to perform the activity may be in the form of updates to the user record within the block chain ledger is chained to chain together the user updates/transactions from initial user entry. For example, should the user attain a further verification level, the further verification level would be pushed to the distributed ledger and digitally signed to be linked to the previous block in the user data. Para 0065; another example, a verification icon provided representing the verification level of users to attest to the verification level or trustworthiness of a user. The browser retrieve the web content from the content server or the social media server and the verification icon content from another server, such as the verification server]
Hanna teaches a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records [Hanna: para 0002]. Hanna includes user identity verification request and responding with a user identity verification response comprising at least a verification level [Hanna: para 0016-0017]. Hanna also a user profile record having a minimum verification threshold level within the ledger. The system may be configured for receiving a user identity verification request and responding with a user identity verification response comprising at least a verification level. [Hanna: para 0042]. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se. As such, Hanna suggest determine that the first authentication level is less than a threshold. However, Hanna did not clearly teach “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”.
Gross teaches the social authentication circuit to reduce the authentication requirements based on a measure of social identity, where the social authentication circuit reduce authentication requirements based on a relationship measure between the one or more parties engaged in a transaction and based on the previous transaction history between the two or more parties. The social authentication circuit determine a level of trust based on the relationship measure being above a threshold relationship measure. Different threshold relationship measures correspond to a different levels of trust and accordingly require decreasing amounts of additional authentication. The social authentication circuit assign the threshold relationship measures to differing values for a maximum currency amount that can be part of the transaction and obtain further authentication through the use of financial information associated with an account of one or more of the parties. The social authentication circuit mitigate a low relationship measure by accessing or receiving additional information about the social media use of the potential receiving party [Gross: col.5, line 42-67]. As such, one would be motivated to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity” to determine a measure of social identity of the receiving party and a threshold level determines the receiving party is not a fake or fraudulent identity [Gross: col.6, line 5-10].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gross with Hanna to teach to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”, for the reason to determine a measure of social identity correspond to a different levels of trust to determines the receiving party is not a fake or fraudulent identity and accordingly require decreasing amounts of additional authentication [Gross: col.15, line 57-col.6, line 10].
Claim 2: Cancelled
Claim 3: Hanna: para 0002, 0059 [updates to the user record within the block chain ledger may be further chained so as to chain together the user updates/transactions]; discussing the blockchain-based system of claim 1, wherein the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: receive an additional blockchain ID associated with the user; identify, from the blockchain, one or more additional blockchain transactions associated with the additional blockchain ID; and update the trust profile of the user based on the one or more additional blockchain transactions.
Claim 4: Hanna: para 0002 in view of Gross: col.6, line 10-20 [authentication data include biometric information such as a finger print by the party (user) to initiate the transaction, suggesting “one or more non-blockchain transactions associated with the user based on the user ID”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 1, wherein the request includes a user ID associated with the user, and the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: identify, from a database, one or more non-blockchain transactions associated with the user based on the user ID; and update the trust profile of the user based on the one or more non-blockchain transactions.
Claim 5: Hanna: para 0016-0017 [verification threshold level within the ledger] in view of Gross: col.1, line 50-5 and col.9, line 37-57 [weighting the relationship measure by a factor consisting of a value and types of social media associations, suggesting “assign a first weight …the second weight”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 1, wherein the event includes a first event that provides a first indication of validity to perform the activity and a second event that provides a second indication of validity to perform the activity, and the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: assign a first weight to the first event; assign a second weight to the second event; and determine the indication of validity to perform the activity based on the first event with the first weight and the second event with the second weight.
Claim 6: Hanna: para 0002, 0067-0068 [the verification level blockchain update record comprising a second verification being greater than the first verification level] in view of Gross: col.9, line 37-57 [associations between the parties with weighting for certain types of social media associations, the relationship measure is weighted or further weighted by one or more factors, suggesting “first event…first weight”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 5, wherein the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: determine that the first event occurs earlier than the second event; and configure the second weight to be greater than the first weight.
Claim 7: Hanna: para 0002, 0067-0068 [the verification level blockchain update record comprising a second verification being greater than the first verification level] in view of Gross: col.11, line 57-col.12, line 10 [interactions with profile information includes location and demographics, suggesting “first event is associated with a first location…a second location”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 5, wherein the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: determine that the first event is associated with a first location, the first location being observed to be used by the user; determine that the second event is associated with a second location; and configure the first weight to be greater than the second weight.
Claim 8: Hanna: para 0017, 0062-0063 [request verification/authentication process or verifying for online transactions, of the user]; discussing the blockchain-based system of claim 1, where the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: receive a security-based indicator of the user; and determine, based on the security-based indicator of the user, that the request to perform the activity is authorized.
Claim 9: Hanna: para 0002, 0037; discussing the blockchain-based system of claim 1, where the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: establish, via the network, a communication session between the computing device and the blockchain-based system to facilitate data transmission associated with performing the activity.
As per claim 10: Hanna teaches a method implemented on a blockchain-based system having a processor and a memory storing computer-executable instructions, the method comprising:
receiving, by the processor and via a network, a request to perform an activity associated with a user from a computing device [Hanna: para 0017, 0062-0063; The “activity” being performed is not explicitly defined. Thus, regarding the limitation “request to perform an activity associate with a user”, where the request to perform an activity can broadly be in the form of a inquiry or query either to perform an activity such as verification/authentication process or verifying for online transactions, of the user. Examples of “perform an activity” may be a user identity verification request and responding with a user identity verification response comprising a verification level, subsequently performing a verification task - Para 0017. Another example, verifying users for online transactions, the distributed ledger may be queried – Para 0063], the request including a blockchain ID associated with the user; [Hanna: para 0002; a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records]
identifying, by the processor and from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Hanna: para 0002; pushing a verification level blockchain update record to the ledger. The “transaction” may broadly be in the form of a record to the ledger, as the ledger is part of the blockchain and includes information for identification]
generating, by the processor and based on the one or more blockchain transactions, a trust profile of the user [Hanna: para 0033; an online user profile identity verification and authentication, to create a trusted online environment enabling secure e-commerce transactions and other online transactions. The system verify user identity such that such verified user identity may be subsequently used when transacting online. As such, the verified user identity associated to the profile suggest “a trust profile of the user”], the trust profile including a first authentication level to perform the activity; [Hanna: para 0017; a user identity verification request and responding with a user identity verification response comprising at least a verification level. Para 0042; verify online users in accordance with verification levels of increasing verification stringency, where subsequent online transactions is enabled depending on the verification levels of users]
determine, by the processor, that the first authentication level is less than a threshold; [Hanna: para 0016, 0042; a minimum verification threshold level within the ledger. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se]
**based on the first authentication level being less than the threshold, determining, by the processor and based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity; [**rejected under a secondary reference, discussion below]
determining, by the processor and based the indication of validity, that the request to perform the activity is authorized; and [Hanna: para 0063; verifying users for online transactions, the distributed ledger may be queried. When transferring electronic funds to a second user, a first user initially query the ledger to ascertain whether the second user is verified and to what level]
transmitting, by the processor and via the network, an authorization to perform the activity to the computing device. [Hanna: para 0059-0060; one example of transmitting an authorization to perform the activity may be in the form of updates to the user record within the block chain ledger is chained to chain together the user updates/transactions from initial user entry. For example, should the user attain a further verification level, the further verification level would be pushed to the distributed ledger and digitally signed to be linked to the previous block in the user data. Para 0065; another example, a verification icon provided representing the verification level of users to attest to the verification level or trustworthiness of a user. The browser retrieve the web content from the content server or the social media server and the verification icon content from another server, such as the verification server]
Hanna teaches a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records [Hanna: para 0002]. Hanna includes user identity verification request and responding with a user identity verification response comprising at least a verification level [Hanna: para 0016-0017]. Hanna also a user profile record having a minimum verification threshold level within the ledger. The system may be configured for receiving a user identity verification request and responding with a user identity verification response comprising at least a verification level. [Hanna: para 0042]. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se. As such, Hanna suggest determine that the first authentication level is less than a threshold. However, Hanna did not clearly teach “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”.
Gross teaches the social authentication circuit to reduce the authentication requirements based on a measure of social identity, where the social authentication circuit reduce authentication requirements based on a relationship measure between the one or more parties engaged in a transaction and based on the previous transaction history between the two or more parties. The social authentication circuit determine a level of trust based on the relationship measure being above a threshold relationship measure. Different threshold relationship measures correspond to a different levels of trust and accordingly require decreasing amounts of additional authentication. The social authentication circuit assign the threshold relationship measures to differing values for a maximum currency amount that can be part of the transaction and obtain further authentication through the use of financial information associated with an account of one or more of the parties. The social authentication circuit mitigate a low relationship measure by accessing or receiving additional information about the social media use of the potential receiving party [Gross: col.5, line 42-67]. As such, one would be motivated to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity” to determine a measure of social identity of the receiving party and a threshold level determines the receiving party is not a fake or fraudulent identity [Gross: col.6, line 5-10].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gross with Hanna to teach to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”, for the reason to determine a measure of social identity correspond to a different levels of trust to determines the receiving party is not a fake or fraudulent identity and accordingly require decreasing amounts of additional authentication [Gross: col.15, line 57-col.6, line 10].
Claim 11: Cancelled
Claim 12: Hanna: para 0002, 0059 [updates to the user record within the block chain ledger may be further chained so as to chain together the user updates/transactions]; discussing the method of claim 10, further comprising: receiving, by the processor, an additional blockchain ID associated with the user; identifying, by the processor and from the blockchain, one or more additional blockchain transactions associated with the additional blockchain ID; and updating, by the processor, the trust profile of the user based on the one or more additional blockchain transactions.
Claim 13: Hanna: para 0002 in view of Gross: col.6, line 10-20 [authentication data include biometric information such as a finger print by the party (user) to initiate the transaction, suggesting “one or more non-blockchain transactions associated with the user based on the user ID”, under the same pretext and motivation as in claim 1]; discussing the method of claim 10, wherein the request includes a user ID associated with the user, and the method further comprises: further comprising: identifying, by the processor and from a database, one or more non-blockchain transactions associated with the user based on the user ID; and updating, by the processor, the trust profile of the user based on the one or more non-blockchain transactions.
Claim 14: Hanna: para 0016-0017 [verification threshold level within the ledger] in view of Gross: col.1, line 50-5 and col.9, line 37-57 [weighting the relationship measure by a factor consisting of a value and types of social media associations, suggesting “assign a first weight …the second weight”, under the same pretext and motivation as in claim 1]; discussing the method of claim 10, wherein the event includes a first event that provides a first indication of validity to perform the activity and a second event that provides a second indication of validity to perform the activity, and the method further comprises: assigning, by the processor, a first weight to the first event; assigning, by the processor, a second weight to the second event; and determining, by the processor, the indication of validity to perform the activity based on the first event with the first weight and the second event with the second weight.
Claim 15: Hanna: para 0002, 0067-0068 [the verification level blockchain update record comprising a second verification being greater than the first verification level] in view of Gross: col.9, line 37-57 [associations between the parties with weighting for certain types of social media associations, the relationship measure is weighted or further weighted by one or more factors, suggesting “first event…first weight”, under the same pretext and motivation as in claim 1]; discussing the method of claim 14, further comprising: determining, by the processor, that the first event occurs earlier than the second event; and configuring, by the processor, the second weight to be greater than the first weight.
Claim 16: Hanna: para 0002, 0067-0068 [the verification level blockchain update record comprising a second verification being greater than the first verification level] in view of Gross: col.1, line 50-5 and col.9, line 37-57 [weighting the relationship measure by a factor consisting of a value and types of social media associations, suggesting “assign a first weight …the second weight”, under the same pretext and motivation as in claim 1]; discussing the method of claim 14, further comprising: determining, by the processor, that the first event is associated with a first location, the first location being observed to be used by the user; determining, by the processor, that the second event is associated with a second location; and configuring, by the processor, the first weight to be greater than the second weight.
Claim 17: Hanna: para 0017, 0062-0063 [request verification/authentication process or verifying for online transactions, of the user]; discussing the method of claim 10, further comprising: receiving a security-based indicator of the user; and determining, by the processor and based on the security-based indicator of the user, that the request to perform the activity is authorized.
Claim 18: Hanna: para 0002, 0037; discussing the method of claim 10, further comprising: establishing, by the processor and via the network, a communication session between the computing device and the blockchain-based system to facilitate data transmission associated with performing the activity.
As per claim 19: Hanna teaches a non-transitory computer-readable medium storing computer-executable instructions, that when executed by a processor of a blockchain-based system, cause the blockchain-based system to:
receive, via a network and from a computing device, a request to perform an activity associated with a user [Hanna: para 0017, 0062-0063; The “activity” being performed is not explicitly defined. Thus, regarding the limitation “request to perform an activity associate with a user”, where the request to perform an activity can broadly be in the form of a inquiry or query either to perform an activity such as verification/authentication process or verifying for online transactions, of the user. Examples of “perform an activity” may be a user identity verification request and responding with a user identity verification response comprising a verification level, subsequently performing a verification task - Para 0017. Another example, verifying users for online transactions, the distributed ledger may be queried – Para 0063], the request including a blockchain ID associated with the user; [Hanna: para 0002; a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records]
identify, from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Hanna: para 0002; pushing a verification level blockchain update record to the ledger. The “transaction” may broadly be in the form of a record to the ledger, as the ledger is part of the blockchain and includes information for identification]
generate, based on the one or more blockchain transactions, a trust profile of the user [Hanna: para 0033; an online user profile identity verification and authentication, to create a trusted online environment enabling secure e-commerce transactions and other online transactions. The system verify user identity such that such verified user identity may be subsequently used when transacting online. As such, the verified user identity associated to the profile suggest “a trust profile of the user”], the trust profile including a first authentication level to perform the activity; [Hanna: para 0017; a user identity verification request and responding with a user identity verification response comprising at least a verification level. Para 0042; verify online users in accordance with verification levels of increasing verification stringency, where subsequent online transactions is enabled depending on the verification levels of users]
determine that the first authentication level is less than a threshold; [Hanna: para 0016, 0042; a minimum verification threshold level within the ledger. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se]
**based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity; [**rejected under a secondary reference, discussion below]
determine, based on the indication of validity, that the request to perform the activity is authorized; and [Hanna: para 0063; verifying users for online transactions, the distributed ledger may be queried. When transferring electronic funds to a second user, a first user initially query the ledger to ascertain whether the second user is verified and to what level]
transmit, via the network, an authorization to perform the activity to the computing device. [Hanna: para 0059-0060; one example of transmitting an authorization to perform the activity may be in the form of updates to the user record within the block chain ledger is chained to chain together the user updates/transactions from initial user entry. For example, should the user attain a further verification level, the further verification level would be pushed to the distributed ledger and digitally signed to be linked to the previous block in the user data. Para 0065; another example, a verification icon provided representing the verification level of users to attest to the verification level or trustworthiness of a user. The browser retrieve the web content from the content server or the social media server and the verification icon content from another server, such as the verification server]
Hanna teaches a distributed blockchain identity verification ledger comprising a plurality of synchronized distributed identity verification databases with unique user profile identifier records and associated verification level records [Hanna: para 0002]. Hanna includes user identity verification request and responding with a user identity verification response comprising at least a verification level [Hanna: para 0016-0017]. Hanna also a user profile record having a minimum verification threshold level within the ledger. The system may be configured for receiving a user identity verification request and responding with a user identity verification response comprising at least a verification level. [Hanna: para 0042]. A “less than a threshold” may broadly be a form of minimum or minimal which is lesser than a greater form in terms of being greater or lesser per se. As such, Hanna suggest determine that the first authentication level is less than a threshold. However, Hanna did not clearly teach “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”.
Gross teaches the social authentication circuit to reduce the authentication requirements based on a measure of social identity, where the social authentication circuit reduce authentication requirements based on a relationship measure between the one or more parties engaged in a transaction and based on the previous transaction history between the two or more parties. The social authentication circuit determine a level of trust based on the relationship measure being above a threshold relationship measure. Different threshold relationship measures correspond to a different levels of trust and accordingly require decreasing amounts of additional authentication. The social authentication circuit assign the threshold relationship measures to differing values for a maximum currency amount that can be part of the transaction and obtain further authentication through the use of financial information associated with an account of one or more of the parties. The social authentication circuit mitigate a low relationship measure by accessing or receiving additional information about the social media use of the potential receiving party [Gross: col.5, line 42-67]. As such, one would be motivated to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity” to determine a measure of social identity of the receiving party and a threshold level determines the receiving party is not a fake or fraudulent identity [Gross: col.6, line 5-10].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gross with Hanna to teach to “based on the first authentication level being less than the threshold, determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity”, for the reason to determine a measure of social identity correspond to a different levels of trust to determines the receiving party is not a fake or fraudulent identity and accordingly require decreasing amounts of additional authentication [Gross: col.15, line 57-col.6, line 10].
Claim 20: Hanna: para 0016-0017 [verification threshold level within the ledger] in view of Gross: col.1, line 50-5 and col.9, line 37-57 [weighting the relationship measure by a factor consisting of a value and types of social media associations, suggesting “assign a first weight …the second weight”, under the same pretext and motivation as in claim 1]; discussing the non-transitory computer-readable medium of claim 19, wherein the event includes a first event that provides a first indication of validity to perform the activity and a second event that provides a second indication of validity to perform the activity, and the computer-executable instructions that, when executed by the processor, cause the blockchain-based system further to: assign a first weight to the first event; assign a second weight to the second event; and determine the indication of validity to perform the activity based on the first event with the first weight and the second event with the second weight.
Claim 21: Hanna: para 0016-0017, 0067-0068 [the verification level blockchain update record] in view of Gross: col.5, line 5-30 and col.12, line 45-67[suggesting “a second event … ignoring the event”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 3, wherein the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: aggregating the one or more blockchain transactions and the one or more additional blockchain transactions to generate aggregated blockchain transactions; identifying, from the aggregated blockchain transactions, a second event that provides a second indication of validity to perform the activity, wherein the second event occurs later than the event; and updating, based on the second event and by ignoring the event, the first authentication level in the trust profile.
Claim 22: Hanna: para 0002 in view of Gross: col.5, line 50-col.6, line 10 [suggesting “aggregating…decreasing the validity to perform the activity”, under the same pretext and motivation as in claim 1]; discussing the blockchain-based system of claim 3, wherein the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: aggregating the one or more blockchain transactions and the one or more additional blockchain transactions to generate aggregate0d blockchain transactions; identifying, from the aggregated blockchain transaction, a second event that provides a second indication of validity to perform the activity; that the second event occurs in a location different from past locations being associated with the user, and based on the location being different from past locations being associated with the user, decreasing the validity to perform the activity.
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 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 Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
Prosecution Insights