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 current claims 1-20 are acknowledged and considered for examination.
Claims 1, 10, and 19 are independent claims. Claims 1-20 are pending.
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
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 1/23/2024 was filed after the mailing date of the Claims on 1/23/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
5. Claims 1-20 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.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jacobs, et al. [10,693,658] in view of Bozicevich, et al. [US 20210090078].
As per claim 1: Jacobs, et al. teaches a blockchain-based system, comprising:
a processor; and [Jacob: col.9, lines 15-20]
a memory storing computer-executable instructions that, when executed by the processor [Jacob: col.9, lines 15-20], 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, the request including a blockchain ID associated with the user; [Jacob: col.7, lines 19-62 and col.14, lines 4-15; ledger of transactions may be in the form of an electronic ledger (e.g., blockchain). A ledger of transactions may include transaction records that are digitally signed (e.g., with a private key) in order to protect the transaction entries in the ledger from being doctored with false transaction data. The blockchain IDs can be given the broadest interpretation as data related to or that describe the blockchain, such as a private key, signature, or any data associated to a particular blockchain per se]
identify, from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Jacob: col.22, line 55-col.23, line 5; the ledger can take the form of a blockchain. Each block in the blockchain may include information about one or more transactions (e.g., digital assets). Each block include a data header that includes a hash of the previous block in the blockchain ledger and a root value of all past transactions. Since each block in the blockchain ledger may be generated in a similar manner by including a data header storing information referencing its previous entry and previous transactions, no entry can be modified without affecting all following entries. This ensures that any tampering of information related to transactions, such as an attempt to reassign a digital asset to an inappropriate entity, will not go unnoticed. Thus, the transactions associated to the blockchain IDs and that blockchain includes information of the transactions which are related to digital assets that associated to a particular entity/user per se]
generate, based on the one or more blockchain transactions, a trust profile of the user; [Jacob: col.7, lines 30-50 col.27, line 65-col.28, line 5 and col.21, lines 21-51; the ledger of transactions may be in the form of an electronic ledger (e.g., blockchain) in which data already stored in the electronic ledger is unalterable. One or more entities may have access to the ledger, and may be able to consult the ledger to determine whether a certain transaction actually took place, or whether a certain value is authentic. The ledger of transactions or blockchain are related to a verified party or entity per se, thus, suggests the claimed trust profile and the certain value is authentic and may be partially viewable the authentication level with respect to an activity. See also col.13, lines 54-65, col.14, lines 43-57; examples of trust profile]
determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity; [Jacobs: col.4, line 39-48; Digital assets associated with a value transfer can be digitally signed by a sending entity and/or an administrative entity where the sender's signature can indicate that the digital asset was legitimately sent by the indicated sender, and the administrator's signature can indicate that the digital asset was approved and/or recorded by the administrator. Also, the digital signature can indicate that the digital asset has been transferred, and that the value cannot be taken back]
determine, based on the trust profile and the indication of validity, that the request to perform the activity is authorized; and [Jacobs: col.6, line 18-26; A “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data). The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]
**transmit, via the network, an authorization to perform the activity to the computing device. [**rejected under a secondary reference, discussion below]
Jacobs discloses determining the request to perform the activity is authorized based on the trust profile and the indication of validity where a “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data) [Jacobs: col.6, line 18-26, See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]. The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. However, Jacobs did not clearly teach “transmit, via the network, an authorization to perform the activity to the computing device”.
Bozicevich teaches a user activity circuit receives activity data over the network that is indicative of an activity of an authorized user of the financial account specified in a transaction request. The transaction circuit authenticates the transaction request by determining that the activity data is indicative of an expected activity associated with a characteristic of the transaction request. The transaction circuit authorizes the transaction request based at least in part on whether the transaction request is authenticated and information in the customer database [Bozicevich: Abstract]. Bozicevich discloses the financial institution computing system authorizes the transaction and transmits a confirmation to the transaction terminal indicating that the transaction request has been authorized. As such, one would be motivated to include the feature to “transmit, via the network, an authorization to perform the activity to the computing device”, would suggest a non-authorized individual in possession of an authorized user's payment methodology is not able to make fraudulent transactions if the activity of the authorized user does not make sense (e.g., the activity of the user is not the same as or substantially similar to an expected activity) in the context of the transaction [Bozicevich: para 0010]. Bozicevich further discusses the activity data is indicative of an activity that the authorized user performs concurrent with the financial transaction request or prior to the financial transaction request. The activity data is indicative of an activity that the authorized user performs after the financial transaction request is received by the financial institution computing system [Bozicevich: para 0038]. There includes determination of whether the activity data is indicative of the expected activity by comparing the activity data with previous activity data of the authorized user. The previous activity data of the authorized user may be acquired by the FI user activity in conjunction with a previous transaction request or a series of previous transaction requests. The FI transaction circuit determines that the activity data is indicative of the expected activity by comparing the activity data to a user profile associated with the authorized user stored in the customer database. For example, the FI user activity circuit may store the activity data received by in the customer database to create a user profile for each authorized user [Bozicevich: para 0042].
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 Bozicevich with Jacob to teach to “transmit, via the network, an authorization to perform the activity to the computing device”, for the reason to prevent a non-authorized individual from making fraudulent transactions [Bozicevich: para 0010].
Claim 2: Jacob: col.7, lines 43-50 and col.27, line 65-col.28, line 5; discussing the blockchain-based system of claim 1, wherein the trust profile includes a first authentication level to perform the activity, and the computer-executable instructions, when executed by the processor, cause the blockchain-based system to: determine that the first authentication level satisfies a first criteria; and determine that the request to perform the activity is authorized.
Claim 3: Jacobs: col.7, line 60-col.8, line 3, col.15, lines 42-48 [; an identifier for a person issued by a trusted entity suggest trust profile of the user]; discussing the blockchain-based system of claim 2, 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. [Jacobs: col.22, line 16-col.23, line 5, col.26, line 25-45; able to decide which parties can participate, as well as set rules and protocols for participating in the network and update ledger transactions]
Claim 4: Jacobs: col.7, line 60-col.8, line 3 [an identifier for a person issued by a trusted entity suggest trust profile of the user]; discussing the blockchain-based system of claim 2, 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. [Jacobs: col.23, line 5-17, col.26, line 25-45; able to decide which parties can participate, as well as set rules and protocols for participating in the network and update ledger transactions]
Claim 5: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred]; 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. [Jacobs: col.13, line 30-col.14, line 5]
Claim 6: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred] [Jacobs: col.13, line 30-col.14, line 5]Jacobs: col.25, line 40-60 [conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]; 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: Jacobs: col.25, line 40-60, col.31, line 32-55 [conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]; 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: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred]; 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: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred] in view of Bozicevich: para 0038 [suggesting “a communication session… performing the activity”, under the same pretext and motivation as in claim 1]; 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: Jacobs, et al. 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, the request including a blockchain ID associated with the user; [Jacob: col.7, lines 19-62 and col.14, lines 4-15; ledger of transactions may be in the form of an electronic ledger (e.g., blockchain). A ledger of transactions may include transaction records that are digitally signed (e.g., with a private key) in order to protect the transaction entries in the ledger from being doctored with false transaction data. The blockchain IDs can be given the broadest interpretation as data related to or that describe the blockchain, such as a private key, signature, or any data associated to a particular blockchain per se]
identifying, by the processor and from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Jacob: col.22, line 55-col.23, line 5; the ledger can take the form of a blockchain. Each block in the blockchain may include information about one or more transactions (e.g., digital assets). Each block include a data header that includes a hash of the previous block in the blockchain ledger and a root value of all past transactions. Since each block in the blockchain ledger may be generated in a similar manner by including a data header storing information referencing its previous entry and previous transactions, no entry can be modified without affecting all following entries. This ensures that any tampering of information related to transactions, such as an attempt to reassign a digital asset to an inappropriate entity, will not go unnoticed. Thus, the transactions associated to the blockchain IDs and that blockchain includes information of the transactions which are related to digital assets that associated to a particular entity/user per se]
generating, by the processor and based on the one or more blockchain transactions, a trust profile of the user; [Jacob: col.7, lines 30-50 col.27, line 65-col.28, line 5 and col.21, lines 21-51; the ledger of transactions may be in the form of an electronic ledger (e.g., blockchain) in which data already stored in the electronic ledger is unalterable. One or more entities may have access to the ledger, and may be able to consult the ledger to determine whether a certain transaction actually took place, or whether a certain value is authentic. The ledger of transactions or blockchain are related to a verified party or entity per se, thus, suggests the claimed trust profile and the certain value is authentic and may be partially viewable the authentication level with respect to an activity. See also col.13, lines 54-65, col.14, lines 43-57; examples of trust profile]
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; [Jacobs: col.4, line 39-48; Digital assets associated with a value transfer can be digitally signed by a sending entity and/or an administrative entity where the sender's signature can indicate that the digital asset was legitimately sent by the indicated sender, and the administrator's signature can indicate that the digital asset was approved and/or recorded by the administrator. Also, the digital signature can indicate that the digital asset has been transferred, and that the value cannot be taken back]
determining, by the processor and based on the trust profile and the indication of validity, that the request to perform the activity is authorized; and [Jacobs: col.6, line 18-26; A “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data). The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]
**transmitting, by the processor and via the network, an authorization to perform the activity to the computing device. [**rejected under a secondary reference, discussion below]
Jacobs discloses determining the request to perform the activity is authorized based on the trust profile and the indication of validity where a “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data) [Jacobs: col.6, line 18-26, See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]. The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. However, Jacobs did not clearly teach “transmit, via the network, an authorization to perform the activity to the computing device”.
Bozicevich teaches a user activity circuit receives activity data over the network that is indicative of an activity of an authorized user of the financial account specified in a transaction request. The transaction circuit authenticates the transaction request by determining that the activity data is indicative of an expected activity associated with a characteristic of the transaction request. The transaction circuit authorizes the transaction request based at least in part on whether the transaction request is authenticated and information in the customer database [Bozicevich: Abstract]. Bozicevich discloses the financial institution computing system authorizes the transaction and transmits a confirmation to the transaction terminal indicating that the transaction request has been authorized. As such, one would be motivated to include the feature to “transmit, via the network, an authorization to perform the activity to the computing device”, would suggest a non-authorized individual in possession of an authorized user's payment methodology is not able to make fraudulent transactions if the activity of the authorized user does not make sense (e.g., the activity of the user is not the same as or substantially similar to an expected activity) in the context of the transaction [Bozicevich: para 0010]. Bozicevich further discusses the activity data is indicative of an activity that the authorized user performs concurrent with the financial transaction request or prior to the financial transaction request. The activity data is indicative of an activity that the authorized user performs after the financial transaction request is received by the financial institution computing system [Bozicevich: para 0038]. There includes determination of whether the activity data is indicative of the expected activity by comparing the activity data with previous activity data of the authorized user. The previous activity data of the authorized user may be acquired by the FI user activity in conjunction with a previous transaction request or a series of previous transaction requests. The FI transaction circuit determines that the activity data is indicative of the expected activity by comparing the activity data to a user profile associated with the authorized user stored in the customer database. For example, the FI user activity circuit may store the activity data received by in the customer database to create a user profile for each authorized user [Bozicevich: para 0042].
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 Bozicevich with Jacob to teach to “transmit, via the network, an authorization to perform the activity to the computing device”, for the reason to prevent a non-authorized individual from making fraudulent transactions [Bozicevich: para 0010].
Claim 11: Jacob: col.7, lines 43-50 and col.27, line 65-col.28, line 5; discussing the method of claim 10, wherein the trust profile includes a first authentication level to perform the activity, and the method further comprises: determining, by the processor, that the first authentication level satisfies a first criteria; and determining, by the processor, that the request to perform the activity is authorized.
Claim 12: Jacobs: col.7, line 60-col.8, line 3, col.15, lines 42-48 [; an identifier for a person issued by a trusted entity suggest trust profile of the user]; discussing the method of claim 11, 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. [Jacobs: col.22, line 16-col.23, line 5, col.26, line 25-45; able to decide which parties can participate, as well as set rules and protocols for participating in the network and update ledger transactions]
Claim 13: Jacobs: col.7, line 60-col.8, line 3 [an identifier for a person issued by a trusted entity suggest trust profile of the user]; discussing the method of claim 11, 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. [Jacobs: col.23, line 5-17, col.26, line 25-45; able to decide which parties can participate, as well as set rules and protocols for participating in the network and update ledger transactions]
Claim 14: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred]; 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. [Jacobs: col.13, line 30-col.14, line 5, col.25, line 40-60; conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]
Claim 15: Jacobs: col.25, line 40-60 [conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]; 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: Jacobs: col.25, line 40-60, col.31, line 32-55 [conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]; 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: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred]; 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: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred] in view of Bozicevich: para 0038 [suggesting “a communication session… performing the activity”, under the same pretext and motivation as in claim 1]; 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: Jacobs, et al. 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, the request including a blockchain ID associated with the user; [Jacob: col.7, lines 19-62 and col.14, lines 4-15; ledger of transactions may be in the form of an electronic ledger (e.g., blockchain). A ledger of transactions may include transaction records that are digitally signed (e.g., with a private key) in order to protect the transaction entries in the ledger from being doctored with false transaction data. The blockchain IDs can be given the broadest interpretation as data related to or that describe the blockchain, such as a private key, signature, or any data associated to a particular blockchain per se]
identify, from a blockchain, one or more blockchain transactions associated with the blockchain ID; [Jacob: col.22, line 55-col.23, line 5; the ledger can take the form of a blockchain. Each block in the blockchain may include information about one or more transactions (e.g., digital assets). Each block include a data header that includes a hash of the previous block in the blockchain ledger and a root value of all past transactions. Since each block in the blockchain ledger may be generated in a similar manner by including a data header storing information referencing its previous entry and previous transactions, no entry can be modified without affecting all following entries. This ensures that any tampering of information related to transactions, such as an attempt to reassign a digital asset to an inappropriate entity, will not go unnoticed. Thus, the transactions associated to the blockchain IDs and that blockchain includes information of the transactions which are related to digital assets that associated to a particular entity/user per se]
generate, based on the one or more blockchain transactions, a trust profile of the user; [Jacob: col.7, lines 30-50 col.27, line 65-col.28, line 5 and col.21, lines 21-51; the ledger of transactions may be in the form of an electronic ledger (e.g., blockchain) in which data already stored in the electronic ledger is unalterable. One or more entities may have access to the ledger, and may be able to consult the ledger to determine whether a certain transaction actually took place, or whether a certain value is authentic. The ledger of transactions or blockchain are related to a verified party or entity per se, thus, suggests the claimed trust profile and the certain value is authentic and may be partially viewable the authentication level with respect to an activity. See also col.13, lines 54-65, col.14, lines 43-57; examples of trust profile]
determine, based on the one or more blockchain transactions, an event that provides an indication of validity to perform the activity; [Jacobs: col.4, line 39-48; Digital assets associated with a value transfer can be digitally signed by a sending entity and/or an administrative entity where the sender's signature can indicate that the digital asset was legitimately sent by the indicated sender, and the administrator's signature can indicate that the digital asset was approved and/or recorded by the administrator. Also, the digital signature can indicate that the digital asset has been transferred, and that the value cannot be taken back]
determine, based on the trust profile and the indication of validity, that the request to perform the activity is authorized; and [Jacobs: col.6, line 18-26; A “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data). The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]
**transmit, via the network, an authorization to perform the activity to the computing device. [**rejected under a secondary reference, discussion below]
Jacobs discloses determining the request to perform the activity is authorized based on the trust profile and the indication of validity where a “digital asset” may refer to digital content associated with a value, that may indicate a transfer of the value. For example, a digital asset include data that indicates a transfer of a currency value (e.g., fiat currency or crypto currency) and correspond to other non-currency values, such as access privileges data (e.g., a number of authorized usages or a time allotment for accessing information) and ownership data (e.g., digital right data) [Jacobs: col.6, line 18-26, See another example on col.13, line 5-25, col.14, line 61-col.15, line 5]. The access privilege data suggest the request of a usage or time allotment as an activity that is authorized. However, Jacobs did not clearly teach “transmit, via the network, an authorization to perform the activity to the computing device”.
Bozicevich teaches a user activity circuit receives activity data over the network that is indicative of an activity of an authorized user of the financial account specified in a transaction request. The transaction circuit authenticates the transaction request by determining that the activity data is indicative of an expected activity associated with a characteristic of the transaction request. The transaction circuit authorizes the transaction request based at least in part on whether the transaction request is authenticated and information in the customer database [Bozicevich: Abstract]. Bozicevich discloses the financial institution computing system authorizes the transaction and transmits a confirmation to the transaction terminal indicating that the transaction request has been authorized. As such, one would be motivated to include the feature to “transmit, via the network, an authorization to perform the activity to the computing device”, would suggest a non-authorized individual in possession of an authorized user's payment methodology is not able to make fraudulent transactions if the activity of the authorized user does not make sense (e.g., the activity of the user is not the same as or substantially similar to an expected activity) in the context of the transaction [Bozicevich: para 0010]. Bozicevich further discusses the activity data is indicative of an activity that the authorized user performs concurrent with the financial transaction request or prior to the financial transaction request. The activity data is indicative of an activity that the authorized user performs after the financial transaction request is received by the financial institution computing system [Bozicevich: para 0038]. There includes determination of whether the activity data is indicative of the expected activity by comparing the activity data with previous activity data of the authorized user. The previous activity data of the authorized user may be acquired by the FI user activity in conjunction with a previous transaction request or a series of previous transaction requests. The FI transaction circuit determines that the activity data is indicative of the expected activity by comparing the activity data to a user profile associated with the authorized user stored in the customer database. For example, the FI user activity circuit may store the activity data received by in the customer database to create a user profile for each authorized user [Bozicevich: para 0042].
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 Bozicevich with Jacob to teach to “transmit, via the network, an authorization to perform the activity to the computing device”, for the reason to prevent a non-authorized individual from making fraudulent transactions [Bozicevich: para 0010].
Claim 20: Jacobs: col.4, line 39-48 [sender's signature can indicate that the digital asset was legitimately sent and indicate that the digital asset was approved and transferred]; 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. [Jacobs: col.13, line 30-col.14, line 5, col.25, line 40-60; conforms to rules, protocols and thresholds suggest the difference in weight, i.e. greater or lesser or to a certain amount]
Conclusion
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, Joseph Hirl can be reached at 571-272-3685. 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
/JOSEPH P HIRL/Supervisory Patent Examiner, Art Unit 2435