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 .
DETAILED ACTION
This Office Action is in response to the application 19/320,881 filed 09/05/2025
Claims 1-20 have been examined and are pending in this application.This Action is made Non-FINAL
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/05/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 13-20 are objected to because of the following informalities:
Regarding claim 13, claim 13 is objected to as the claim recites “the memory being configured to store a computer program…” To avoid any uncertainty in interpreting the claim with respect to non-statutory subject matter and to be consistent with definitions in the specification, it’s suggested that the aforementioned limitation be further amended to “a computer program stored on a non-transitory computer-readable storage medium” or “a computer program product stored on a computer-readable storage device” or the like.
Regarding claim 14, claim 14 recite the limitations “The computer device according to claim 13, further comprising: obtaining/performing …” (emphasis added). To properly recite embodiment and corresponding functions performed by the embodiment of the claimed computer device, it’s suggested that the aforementioned limitation be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: obtaining/performing.”
Regarding claim 15, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, wherein … obtaining… comprises: obtaining/performing …” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: obtaining/obtaining/performing.”
Regarding claim 16, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, wherein … obtaining … comprises: /obtaining/performing/determining …” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: obtaining/obtaining /performing/determining…”
Regarding claim 17, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, further comprising: obtaining/determining …” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: obtaining/determining…”
Regarding claim 18, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, wherein … participating … comprises: receiving/transmitting” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: participating/receiving/transmitting.”
Regarding claim 19, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, further comprising: receiving/forwarding” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: receiving/forwarding.”
Regarding claim 20, similar to issues addressed above, it’s suggested that the limitations “The computer device according to claim 13, further comprising: generating/obtaining …” (emphasis added) be further amended to “The computer device according to claim 13, wherein the processor further to invoke the computer program to perform the steps of: generating/obtaining…”
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) 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-3, 5-7, 9, 10, 12, 13-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hung et al. (“Hung,” US20210359863), published November 18, 2021, in view of Tang et al. (“Tang,” US20200280444), published November 9, 2021.
Regarding claim 1, Hung discloses a blockchain key-based data processing method (Hung: pars. 0070-0072 and Fig. 3), comprising:
obtaining communication channels respectively communicating with N clients, and respectively performing key shard negotiation with the N clients based on the N communication channels, to obtain a local private key shard and a complete public key, N being a positive integer greater than 1, the complete public key being a unique public key corresponding to the local private key shard and N target private key shards, and an
i
t
h
target private key shard in the N target private key shards being a private key shard held by an
i
t
h
client in the N clients after the key shard negotiation (Hung: 0016, 0056-0057; Fig. 4 step 403 (par. 0084); Platform 101 and multiple users devices 102 [N clients, N > 1] jointly run the hierarchical threshold key-generation protocol 400 over communication network 107, exchanging shares [i.e. shards] over a secure channel provided for each participant [i.e., obtaining communication channels with N clients and performing key shard negotiation over those channels]; pars. 0071-0072, 0087-0092; Fig3. steps 302-303, Fig. 4 step 409; Platform secures/controls “platform secure shares” [i.e. local private key shards]; each user secures/controls “user secure shares”, each
P
i
holding share
x
i
[i.e.
i
t
h
target private key shard held by
i
t
h
client]; public key is set to y=Πiyi [i.e. a single/unique complete public key corresponding to all shards jointly]);
receiving signature requests transmitted by M-1 clients in the N clients, and obtaining [[identity association information in the M-1 signature]] requests, M being a quantity threshold of private key shard for performing signature verification based on the complete public key, and M being a positive integer less than or equal to N+1 (Hung: pars. 0067, 0073; Fig. 3 step 304; A requesting user sends a transaction signing request through wallet service API 201 to platform, and the requesting user/device is authenticated by the account management module [i.e. receiving signatures request from clients and obtaining association information from the module]; see also par. 0021; pars. 0013-0014, 0055, and 0066; Authorized subsets are defined by threshold parameters
t
0
<
t
1
<
…
<
t
m
, and a valid signature is produced only when the subset satisfies the threshold requirement [i.e. M is a quantity threshold of shards required to sign/verify]; M signers
≤
(N clients + platform) = N+1 [i.e. M
≤
N+1]);
Hung discloses receiving a signature request as recited above, but does not explicitly disclose identity association information in the M-1 signature request.
However, in an analogous art, Tang discloses a method of identity and electronic signature verification in blockchains that includes the steps of receiving identity association information in the M-1 signature request (Tang: pars. 0045-0046; verification request includes an identifier of the user and a digital address; par. 0068; verification request carries the user’s identifier and identity feature data [i.e. identity association information in the signature request]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Tang with the method of Hung. One would have been motivated to include client identity association information in the request to ensure secure, authentic, and verifiable communication within the blockchain network (Tang: pars. 0018 and 0049).
The combination of Hung and Tang further discloses that if the identity association information in the M-1 signature requests is legitimate identity information, determining a client that is in the M-1 clients and that is configured to initiate a blockchain service as a target client, and obtaining service execution data associated with the target client (Hung: pars. 0062 and 0067; Account management module/application-interface key pairs determine whether the requesting user is the initiator of the transaction [i.e. on legitimate identity, the initiating client is the target client]; par. 0064; transaction details are obtained for the legitimacy determination (values, destination, time, etc.) [i.e. obtaining service execution data associated with the target client]; Tang: Fig. 2, Fig. 4 step 410; par. 0081; Trusted independent system 225 verifies the user’s identity from the supplied personal information and issues an ownership endorsement token/digital credential 227 [i.e. determining the identity association information to be legitimate identity information]); and
The motivation is the same as that recited above.
Hung and Tang further disclose if the service execution data conforms to a risk management policy corresponding to identity association information of the target client, jointly participating in joint signature processing on the blockchain service with the M-1 clients, a joint signature result being generated based on both the local private key shard and target private key shards respectively held by the M-1 clients, and the joint signature result being configured for the target client to execute the blockchain service (Hung: Fig. 3 step 305-306, pars. 0064-0065 and 0074-0077; policy enforcement module 204 validates whether the transaction signing request adheres to a predefined access policy (value, destination, time, etc.); on successful validation the platform facilitate the user device and platform to jointly run the hierarchical threshold signature protocol 500 [i.e. on conformance to a risk management policy, jointly participating in join signature processing with the M-1 clients]; pars. 0102-0107, Fig. 5; The threshold signature is jointly generated from the platform and user’s shares [i.e. joint signature results generated from both the local private key shard and the client’s target private key shards]; pars. 0068, 0079 and Fig. 3 step 308; the blockchain service module uploads the signed transaction to the corresponding blockchain network and monitors its execution [i.e. joint signature result configured for the target client to execute the blockchain service]).
Regarding claim 2, Hung and Tang disclose the methods of claim 1.
The combination of Hung and Tang further discloses the method further comprising:
obtaining target shard public keys respectively corresponding to the M-1 clients, a target shard public key corresponding to one client being generated based on a target private key shard corresponding to the client (Hung: pars. 0088-0092 and 0091, Fig. 4 steps 406-409; Each user broadcast a per-share public component and the platform checks the broadcast
A
j
values; a public component derived from that user’s private share
x
i
[i.e. a target shard public key generated from the client’s target private key shard]);
respectively performing, by using the M-1 target shard public keys, signature verification on shard signature results transmitted by the M-1 clients, to obtain M-1 signature verification results, one shard signature result being data obtained by signing identity association information by one client by using a target private key shard corresponding to the client (Hung: pars. 0088-0092 and 0091, Fig. 4 steps 406-409; each user proves in zero-knowledge (Schnorr) knowledge of its share
x
i
, aborting on failure [i.e. shard public keys generated per target shard, used to verify each client’s shard signature; on all success the process proceeds]; Tang: pars. 0043, 0050 and 0056; The signer’s contribution/credential is verified as authentic using the obtained hash value and the identifier stored in the wallet, the ownership document endorsement token (ODET) [i.e. verifying the data a client signed with its shard]); and
The motivation is the same as that recited in claim 1.
if all the M-1 signature verification results are verification success results, performing legitimate identity verification on the identity association information in the signature requests transmitted by the M-1 clients (Hung: pars. 0086, 0090 and 0067; the protocol proceeds only when every consistency checks passes [aborts otherwise], and the request then proceeds to authentication/validation [i.e. all success is a pre-condition to the next stage]; Tang: pars. 0071 and 0081; Legitimate identity verification via the trusted independent system then follows [performing legitimate identity verification once all shard verifications succeed]).
The motivation is the same as that recited in claim 1.
Regarding claim 3, Hung and Tang disclose the methods of claim 1.
The combination of Hung and Tang further discloses wherein the M-1 clients comprise a client
S
i
, i being a positive integer less than or equal to M-1; and the performing legitimate identity verification on the identity association information in the signature requests transmitted by the M-1 clients comprises (Hung: par. 0070; The users U= {
P
1
,
P
2
, …,
P
n
} are the clients, any representative
P
i
being signing client [i.e. the M-1 clients comprise a representative client
S
i
]; Tang: par. 0080; the process extends to any number of signatories [
S
i
is one of the M-1 signing clients]):
The motivation is the same as that recited in claim 1.
Tang further discloses obtaining service types of blockchain services initiated and associated by the M-1 clients, and obtaining an identity identifier and identity feature data in identity association information corresponding to the client
S
i
(Tang: par. 0027; smart contract repository holds different classes of documents, like mortgages, auto loans of various terms, wills, trusts, bankruptcy, etc. [i.e. services types of the initiated services]; pars. 0046 and 0050; verification request carries an identifier of the user and a digital address [i.e. identity identifier]; see also par. 0069; name, residence address, electronic contact information, social security number, driver's license information [i.e. identity feature data corresponding to client
S
i
]);
determining identity verification policies matching the service types, and selecting, from the identity identifier and the identity feature data, data matching verification dimensions indicated by the identity verification policies as to-be-verified data (Tang: pars. 0037 and 0115; contract/settings (number of signers, required signers, list of entities) vary by the selected smart contract class [i.e. identity verification policies matching the service type]; par. 0068; a predetermined list of identifiers is used to prevent spoofing by signers who sign in place of intended signers [i.e. selecting, per the policy’s verification dimensions, particular identifier/feature data as the to-be-verified data]); and
if the to-be-verified data exists in an identity database, determining that the identity association information in a signature request corresponding to the client S, is legitimate identity information (Tang: pars. 0047, 0081; the trusted independent system compares the user’s information in the digital credentials against information it can access (e.g. memory 143, enterprise records 150, etc.) and on a successful match stores the ODET confirming legitimacy [i.e. if the to-be-verified data exists in an identity database/repository, the identity information is determined legitimate]).
The motivation is the same as that recited in claim 1.
Regarding claim 5, Hung and Tang disclose the methods of claim 1.
The combination of Hung and Tang further disclose the method further comprising:
obtaining an application on-chain address corresponding to the target client from the service execution data, and performing address risk detection on the application on-chain address (Hung: par. 0064; the predefined access policy includes checks pertaining to a destination [i.e. address] to determine the transaction’s legitimacy; Tang par. 0035; unique digital address associated with the user/wallet; [i.e. obtaining the on-chain/destination address and performing address risk detection]); and
The motivation is the same as that recited in claim 1.
Hung further discloses if the application on-chain address exists in a legitimate address list, determining that the service execution data conforms to the risk management policy corresponding to the identity association information of the target client (pars. 0021, 0064 and 0076; account management module is configured to register and identify a user based on a user information in a database [contain list legitimate addresses] and a plurality of security features; destination check passes, validation succeeds and the request proceeds [maintaining a list of legitimate destination addresses is an obvious security feature]); or
if the application on-chain address does not exist in a legitimate address list, determining that the application on-chain address is a risky address, and prohibiting responding to the blockchain service initiated by the target client (Hung: pars. 0021 and 0075; when policy determination is “NO” [destination not permitted], method 300 ends and the request is no processed [a non-listed address (in the database) is treated as risky and the service is not responded to]).
Regarding claim 6, Hung and Tang disclose the methods of claim 1.
Hung further discloses wherein the jointly participating in joint signature processing on the blockchain service with the M-1 clients (Hung: pars. 0093-0102) comprises:
receiving an intermediate encryption result that is transmitted by the target client and that is obtained by performing encryption processing by using a target private key shard corresponding to the target client, and signing the received intermediate encryption result by using the local private key shard, to obtain a server end signature result (Hung: Fig. 5 steps 501-511, pars. 0093-0102, and 0107; joint threshold digital signature using the signature protocol; [in threshold-signature protocol each device participating (including the platform) receives the other devices committed/intermediate values and contributes to own intermediate computation si using its own share]); and
transmitting the server end signature result to the target client. the server end signature result being configured for indicating the target client to generate a joint signature result (Hung: Fig. 5 step 511, pars. 0107-0108; each player broadcasts its si and the players compute final s; if (r,s) is a valid signature it is accepted [i.e. the platform’s partial result is transmitted so the target client combines the contributions into the join signature results]).
Regarding claim 7, Hung and Tang disclose the methods of claim 1.
Hung further discloses the method further comprising:
receiving to-be-uploaded service data transmitted by the target client, the to-be-uploaded service data comprising the target service execution data in the blockchain service and the joint signature result (Hung: Fig. 3 step 308, pars. 0068 and 0079; the blockchain service module handles the signed transaction [transaction data and its signature]; signed transaction [to-be-uploaded] is sent to a corresponding digital asset blockchain network [i.e. uploaded]; [receiving the to-be-uploaded service data comprising the transaction data and the joint signature result]); and
The combination of Hung and Tang further disclose forwarding the to-be-uploaded service data to a blockchain consensus network, so that the blockchain consensus network performs signature verification on the joint signature result based on the complete public key in a consensus process, and when the consensus is reached, storing execution result data corresponding to the target service execution data into a blockchain ledger (Hung: pars. 0058 and 0079; the signed transaction is sent [i.e. uploaded] to the blockchain network, which sends, receives and verifies the digital asset transaction [i.e. forwarding to the consensus network for verification]; Tang: pars. 0022 and 0083; Nodes compare blocks and, once a majority agree, the block is encrypted and chained; blocks must satisfy a proof-of-work and an electronic signature condition verified with a key available to members [i.e. verifying the signature during consensus, and, on consensus, storing the result in the ledger]).
The motivation is the same as that recited in claim 1.
Regarding claim 9, Hung and Tang disclose the methods of claim 1.
Hung further discloses wherein the obtaining communication channels respectively communicating with N clients, and respectively performing key shard negotiation with the N clients based on the N communication channels, to obtain a local private key shard and a complete public key (Hung: 0016, 0056-0057; Fig. 4 step 403 (par. 0084); Platform 101 and multiple users devices 102 [N clients, N > 1] jointly run the hierarchical threshold key-generation protocol 400 over communication network 107, exchanging shares [i.e. shards] over a secure channel provided for each participant [i.e., obtaining communication channels with N clients and performing key shard negotiation over those channels]; par. 0092; supplies the complete public key y [i.e. complete public key ]) comprises:
randomly generating a local test private key configured for performing key shard negotiation, and performing encryption processing on local negotiation data by using the local test private key, to obtain local test information (Hung: Fig. 4 step 401 and 402, pars. 0082-0083; each participant generates keys for a homomorphic (Paillier) cryptosystem and selects random polynomial coefficients, then broadcasts committed values
C
i
j
over the negotiation [i.e. randomly generating a negotiation (test) key and producing encrypted/committed local negotiation data]);
obtaining the communication channels respectively communicating with the N clients, and transmitting the local test information to the N clients through each communication channel (Hung: Fig. 4 step 403, pars. 0016 and 0083-0084; Broadcasting channel and per-participant secure channel are provided; committed values are broadcast and shares are sent over the secure channel to each participant [i.e. transmitting the local test information to the N clients over the channels]);
receiving target test public keys and target test information that are respectively transmitted by the N clients, and decrypting, by using the target test public keys, target test information belonging to a same client, to obtain N pieces of target decrypted data, one target test public key being a public key that is generated by one client and that corresponds to a target test private key configured for performing key shard negotiation, and one piece of target test information being information obtained by performing encryption processing on target negotiation data by using a generated target test private key in one client (Hung: Fig. 4 step 401-403, pars. 0081-0084; each user broadcasts its homomorphic encryption public key
E
i
and its committed values/shares; the platform receives and processes each user’s public key and encrypted contribution [i.e. receiving each client’s test public key and test information and recovering the corresponding decrypted data]);
decrypting the local test information based on a local test public key corresponding to the local test private key, to obtain local decrypted data, and determining the local decrypted data and the N pieces of target decrypted data as a first hash result (Hung: Fig. 4 step 404, par. 0085; Each participant derives from all received and locally held values, the quantity used in the consistency verification [i.e. the aggregate of local plus N target derived values is the first (computed) result]);
performing a hash operation on the local negotiation data and N pieces of target negotiation data, to obtain a second hash result (Hung: Fig. 4 step 404, par. 0085; the consistency check verifies that computed quantity equals the expected value formed from the committed polynomial values [i.e. the expected value formed from the negotiation data is second result]);
determining that key negotiation succeeds if the first hash result is equal to the second hash result, and determining the local test private key as the local private key shard (Hung: Fig. 4 steps 404-405, pars. 0085-0087; if the equality holds the check passes (otherwise the participant aborts), and each participant then computes its private share
x
i
by adding the received private shares [i.e. on equality negotiation succeeds and the negotiation key becomes the local private key shard]); and
generating the complete public key in a process of performing key shard negotiation with the N clients (Hung: Fig. 4 steps 409-410, par. 0092; each participant sets
y
i
=
A
i
0
and the public key is set to y during the DKG [generating the complete public key during negotiation]).
Regarding claim 10, Hung discloses a blockchain key-based data processing method, performed by a target client configured to initiate a blockchain service, and the method (Hung: Fig. 4 step 400) comprising:
obtaining, by the target client, communication channels respectively communicating with N-1 clients and a server end, and performing key shard negotiation with the server end and the N-1 clients based on the communication channels, to obtain a target private key shard corresponding to the target client and a complete public key, N being a positive integer greater than 1, the complete public key being a unique public key to which the target private key shard corresponding to the target client, a server end private key shard, and target private key shards corresponding to the N-1 clients jointly correspond, an
i
t
h
target private key shard in the target private key shards corresponding to the N-1 clients being a private key shard held by an
i
t
h
client in the N-1 clients after the key shard negotiation, and the server end private key shard being a private key shard held by the server end after the key shard negotiation (Hung: Fig. 4 step 403 pars. 0019, 0056, and 0084; User device 102 operates as a service client that jointly runs, sends, and receives the DKG and signature data to/from platform 101 with each user
P
i
exchanging shares with other users and the platform over secure channels [i.e. the target client obtains channels with the N-1 other clients and the server end and performs key shard negotiation, obtaining its own target private key shard]; Fig.4 step 409, pars. 0072, 0087 and 0092; Public key y=Πiyi corresponds jointly to the platform’s shares [server end shard] and all user’s shares [target client’s shard + N-1 clients’ shards] [i.e. a single complete public key to which the target, server end, and N-1 client shards jointly correspond]);
generating, [[based on identity association information corresponding to the target client]], a signature request corresponding to the target client, and transmitting the signature request corresponding to the target client to the server end, so that the server end performs legitimate identity verification [[on identity association information in received M-1 signature requests]], the M-1 signature requests comprising the signature request corresponding to the target client, and M being a quantity threshold of private key shard for performing signature verification based on the complete public key, and M being a positive integer less than or equal to N+1 (Hung: Fig. 3 step 304, pars. 0067, 0072-0073; User device transmits a transaction signing request via wallet API 201 to the platform, which authenticates the requesting user [i.e. generating and transmitting a signature request based on the target client’s identity association information for server-end legitimate identity verification]; pars. 0013-0014 and 0066; threshold of shares [M is the shard-quantity threshold, M
≤
N+1]);
Hung discloses generating and verifying a signature request as recited above, but does not explicitly disclose generating a signature request based on identity association information corresponding to the target client and performing verification on identity association information in received M-1 signature requests.
However, in an analogous art, Tang discloses a method of identity and electronic signature verification in blockchains that includes the steps generating a signature request based on identity association information corresponding to the target client and performing verification on identity association information in received M-1 signature requests. (Tang: par. 0068; verification request carries the user’s identifier and identity feature data [i.e. identity association information in the signature request]; pars. 0080-0081, Fig. 4 steps 410; [supply the identity association information and its verification]; each respective user may establish a respective verified identity [i.e. legitimate identity verification on the M-1 requests, extendable to any number of signatories]).
The motivation is the same as that recited in claim 1.
The combination of Hung and Yang further discloses that if the server end determines that the identity association information in the M-1 signature requests is legitimate identity information, transmitting service execution data associated with the target client to the server end (pars. 0062, 0064, and 0067; After the requesting user is authenticated as legitimate transaction details are provided to the platform for policy validation [i.e. upon legitimate identity determination, transmitting the target client’s service execution data to the server end]; Tang: par. 0081, Fig. 4 step 410; confirms the legitimate-identity determination [i.e. server end determines identity is legitimate]); and
The motivation is the same as that recited in claim 1.
Hung and Yang further disclose that if the service execution data conforms to a risk management policy corresponding to the identity association information of the target client, jointly participating in joint signature processing on the blockchain service with a client that initiates a signature request and the server end, a joint signature result generated through the joint signature processing being generated based on both a target private key shard that corresponds to the client that initiates the signature request and the server end private key shard, and the joint signature result being configured for being provided for the target client to execute the blockchain service (Hung: Fig. 3 steps 305-306, pars. 0064 and 0077; On successful validation against the predefined access policy, the user device jointly runs the threshold signature protocol 500 with the platform (and participating users) [i.e. on risk-policy conformance, jointly participating in joint signature processing with the initiating client and the server end]; Fig. 5 step 308, pars. 0065-0066, 0079; the joint signature is generated from the participating client’s shares and the platform’s shares, and the signed transaction is uploaded to the blockchain for execution [i.e. joint signature result from the initiating client’s target shard and the server end shard, configured for the target client to execute the blockchain service]).
Regarding claim 12, Hung and Tang disclose the methods of claim 10.
The combination of Hung and Tang further discloses wherein the generating, based on identity association information corresponding to the target client, a signature request corresponding to the target client, and transmitting the signature request corresponding to the target client to the server end (Hung: Fig. 3 step 304, pars. 0067, 0072-0073; User device transmits a transaction signing request via wallet API 201 to the platform, which authenticates the requesting user [i.e. generating and transmitting a signature request based on the target client’s identity association information for server-end legitimate identity verification]; Tang: par. 0068; verification request carries the user’s identifier and identity feature data [i.e. identity association information in the signature request]) comprises:
The motivation is the same as that recited in claim 1.
displaying a service initiation control, and an application on-chain address and virtual resource data that correspond to the target client in a blockchain function interface, the virtual resource data being configured for representing service data in a blockchain service account corresponding to the target client (Hung: par. 0056 and 0060; client application [i.e. mobile app, browser, etc. ] provide the wallet user interface, and the digital-asset wallet holds user’s assets [i.e. a blockchain function interface displaying the on-chain address and virtual resource data from the target client]; Tang pars. 0041 and 0066; the application presents indication on the display and exposes user interface with a selectable button [i.e. a service initiation control in the interface]; see also par. 0022; digital wallets hold cryptocurrency [i.e. virtual resource data representing account service data]); and
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Tang with the method of Hung. One would have been motivated to include the specific display elements and user interface controls within the blockchain functional digital-asset wallet interface, to identify and verify digital asset transactions (Tang: pars. 0017 and 0018).
in response to a blockchain service initiation operation of the service initiation control in the blockchain function interface, transmitting, to the server end, the signature request that corresponds to the target client and that is generated based on the identity association information corresponding to the target client (Tang: par. 0066; the signing application makes the call in response to input into the user interface (selectable button) [i.e. in response to the service-initiation control operation]; Hung: par. 0073, Fig. step 304; the user sends the transaction signing request via the wallet API to the platform [i.e. transmitting the identity-based signature request to the server end]); and
The motivation is the same as that recited above.
Hung and Tang further disclose a method that further comprises:
transmitting to-be-uploaded service data to the server end, the to-be-uploaded service data comprising target service execution data in the blockchain service and the joint signature result (Hung: pars. 0068 and 0079; the signed transaction (transaction data and signature) is provided for uploading [i.e. transmitting the to-be-uploaded service data comprising the transaction data and the joint signature result); and
The combination of Hung and Tang further discloses if signature verification performed by a blockchain consensus network on the joint signature result based on the complete public key succeeds and a consensus on the to-be-uploaded service data is reached, receiving feedback data that is transmitted by the server end and that is for the to-be-uploaded service data, and updating and displaying the virtual resource data on the blockchain function interface based on the feedback data (Hung: pars. 0058 and 0068; the blockchain network verifies the transaction and the platform monitors execution [i.e. consensus-network verification with the complete public key]; Tang: par. 0083; proof-of-work/electronic signature consensus [i.e. consensus reached]; pars. 0062 and 0112-0113; notifications pushed to the application that a document is signed/complete, and the confirmation is presented on the user’s display [i.e. receiving feedback data and updating the displayed virtual resource data]).
The motivation is the same as that recited above.
Regarding claim 13, Hung discloses a computer device, comprising a processor, a memory, and a network interface, the processor being connected to the memory and the network interface, the network interface being configured to provide a data communication function, the memory being configured to store a computer program, and the processor being configured to invoke the computer program, to enable the computer device to perform a blockchain key-based data processing method (Hung: Fig. 1, pars. 0017 and 0051-0052; digital asset wallet service platform 101 with communication network 107 (network interface) executing the disclosed process), comprising:
The method performed by the computer device corresponds to the method recited in claim 1. The method is similar in scope to claim 1, and is therefore rejected under a similar rationale.
Regarding claims 14, 15 and 17-19, claims 14, 15, 17, 18, and 19 are directed at a computer device corresponding to the method recited in claims 2, 3, 5, 6, and 7. The claims are similar in scope to claims 2, 3, 5, 6 and 7 and are therefore rejected under the same rationale.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hung et al. (“Hung,” US20210359863), published November 18, 2021, in view of Tang et al. (“Tang,” US20200280444), published November 9, 2021, and further in view of Jevans et al. (“Jevans,” US20200160344), published May 21, 2020.
Regarding claim 4, Hung and Tang disclose the methods of claim 1.
wherein the obtaining service execution data associated with the target client (Hung: par. 0064; transaction value, destination, time of the current request [i.e. service execution data of the target client]) comprises:
obtaining [[historical service]] execution data of the target client and target service execution data in the initiated blockchain service, and determining the [[historical service]] execution data and the target service execution data as the service execution data associated with the target client (Hung: par. 0064; transaction value, destination, time of the current request [i.e. service execution data of the target client]; Tang: pars. 0032, 0060 and 0086; ledger, authentication record [i.e. service execution data]); and the method further comprises:
Hung and Tang disclose obtaining execution data of the target client and determining the execution data as the service execution data associated with the target client, but does not explicitly disclose obtaining historical service execution data of the target client and determining the historical service execution data as the service execution data associated with the target client.
However, in an analogous art, Jevans discloses a method of analyzing transactions that includes the steps of obtaining historical service execution data of the target client and determining the historical service execution data as the service execution data associated with the target client (Jevans: pars. 0023, 0029, and 0032; the service returns a transaction history for an address over a given date range, plus per-address balance, number of deposits/spends, and totals [i.e. historical service execution data of the target client is obtained and combined with the current transaction data]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Jevans with the method of Hung and Tang. One would have been motivated to evaluate historical execution data to reduce the risk of fraud and enhance transaction validation within the blockchain network (Jevans: pars. 0017).
Hung, Tang, and Jevans further disclose performing data analysis on the historical service execution data in the service execution data to obtain a historical service operation range, and setting a service threshold based on the historical service operation range (Jevans: par. 0034; a proposed transaction is modeled using historical transaction involving one or more of the parties, and allowed if the resulting score is below a critical threshold [i.e. analyzing historical service execution data to derive the operating profile against which a threshold is set]; pars. 0003 and 0005; the transaction is allowed, flagged, or denied according to whether the transaction risk score falls within a first, second and third range value [i.e. the historical analysis yields ranges/bands, and the boundary between “allow” and “flag/deny” is the service threshold]); and
The motivation is the same as that recited above.
if the target service execution data in the service execution data is less than or equal to the service threshold, determining that the service execution data conforms to the risk management policy corresponding to the identity association information of the target client (Hung: pars. 0064, 0074 and 0076; compare against the policy limit; on adherence, procced; see also Jevans: pars. 0034 and 0048; a transaction is allowed to procced when its score is below the critical threshold/ of no apparent risk [i.e. conforms and proceeds]).
The motivation is the same as that recited above.
Regarding claim 16, claim 16 is directed at a computer device corresponding to the method recited in claim 4. The claim is similar in scope to claim 4 and is therefore rejected under the same rationale.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hung et al. (“Hung,” US20210359863), published November 18, 2021, in view of Tang et al. (“Tang,” US20200280444), published November 9, 2021, and further in view of Gennaro et al. (“Gennaro,” “One Round Threshold ECDSA with Identifiable Abort” Cryptology ePrint Archive), published 2020.
Regarding claim 8, Hung and Tang disclose the methods of claim 1.
The combination of Hung and Tang further discloses the method further comprising:
generating a target service address based on the complete public key (Tang: pars. 0020 and 0035; the electronic signature application generates a unique digital address (a 30-plus-character alphanumeric codename) associated with the user’s key/credentials [i.e. generating a service address from the complete public key]; Hung: par. 0092; supplies the complete public key y [public key from which such an address is conventionally derived]);
obtaining to-be-verified addresses respectively transmitted by the N clients, a to-be-verified address transmitted by one client being generated based on the complete public key (Hung: Fig. 4, par. 0092; every participant independently derives the same public key y, at the end of the DKG, each client can generate the corresponding address from the shared public key [i.e. each of the N clients generates and transmits its address derived from the complete public key]; Tang: pars. 0020 and 0035; target service address); and
if the target service address is the same as the N to-be-verified addresses, determining that the target service address is a legitimate address, and determining the target service address as an application on-chain address (Hung: Fig. 4 step 404 and 407, pars. 0085 and 0089; each participant is required to cross-check received/broadcasted values for consistency across all participants before proceeding [i.e. requiring all N client-derived addresses to match the server’s before adopting the address]; Tang: pars. 0020 and 0035; target service address); or
Hung discloses if there is a to-be-verified address different from the target service address in the N to-be-verified addresses abort the protocol (Hung: pars. 0086 and 0090: On a failed consistency check, the participant aborts the protocol [i.e. on mismatch the generated addresses are discarded]).
Hung and Tang do not explicitly disclose if there is a to-be-verified address different from the target service address in the N to-be-verified addresses, deleting the target service address and the N to-be-verified addresses that have been generated, and transmitting application on-chain address regeneration requests to the N clients, the application on-chain address regeneration request indicating the N clients to regenerate new to-be-verified addresses based on the complete public key.
However, in an analogous art, Gennaro discloses a protocol for performing a simple identification, which includes the steps of if there is a to-be-verified address different from the target service address in the N to-be-verified addresses, deleting the target service address and the N to-be-verified addresses that have been generated, and transmitting application on-chain address regeneration requests to the N clients, the application on-chain address regeneration request indicating the N clients to regenerate new to-be-verified addresses based on the complete public key (Gennaro: Section 4.1 Phase 2 and “Simple Identification Protocol” page 16 and 17; on failed check, the protocol aborts; it is safe to abandon the protocol and publish the would be private key [i.e. not-yet-established keys or used]; the protocol would need to be re-run to established new secure keys [i.e. on address mismatch, deleting the target service address and re-running generation to regenerate new to-be-verified addresses from the public key]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Gennaro with the method of Hung and Tang. One would have been motivated to use an abort-and-re-run mechanism after cross-check validation failure to avoid adopting inconsistent addresses (Gennaro: Section 4.1).
Regarding claim 20, claim 20 is directed at a computer device corresponding to the method recited in claim 8. The claim is similar in scope to claim 8 and is therefore rejected under the same rationale.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Hung et al. (“Hung,” US20210359863), published November 18, 2021, in view of Tang et al. (“Tang,” US20200280444), published November 9, 2021, and further in view of Sudia et al. (“Sudia,” US5825880), published October 20, 1998.
Regarding claim 11, Hung and Tang disclose the methods of claim 10.
Tang further discloses wherein the M-1 clients comprise the target client and a signing client; and the method further (Tang: pars. 0055, 0057, and 0080; scheme involves a first user and a second user as signatories and expressly extends to any number of signatories [the M-1 clients comprise the target client and at least one further signing client]) comprises:
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Tang with the method of Hung. One would have been motivated to include a plurality of signatories, specifically comprising a target client and a signing client, to accurately verify and authenticate other client operations. (Tang: pars. 0018 and 0049).
The combination of Hung and Tang further discloses [[if server end fault information transmitted by the server end is received]], performing encryption processing on obtained to-be-signed information by using the target private key shard corresponding to the target client, to obtain an initial signature result (Hung: par. 0071, Fig 5; a user secures shares such that a signature is generated using at least one user secure share [the client can sign with its own shard; the target client encrypts/signs the to-be-signed information with its shard to produce an initial signature result]; Tang: par. 0063; first user signs the document hash, generating a refreshed hash [i.e. initial signature result]);
The motivation is the same as that recited in claim above.
The combination of Hung and Tang discloses performing encryption processing on obtained to-be-signed information as recited above, but does not explicitly disclose if server end fault information transmitted by the server end is received, performing encryption processing on obtained to-be-signed information.
However, in an analogous art, Sudia discloses a multi-step signing system which includes the step of if server end fault information transmitted by the server end is received, performing encryption processing on obtained to-be-signed information (Sudia: Fig. 9 and 10, Col. 5 Lines 23-47 and Col; private key exist only as operational shares, and a signing device affixes an initial partial signature by hashing the document [i.e. to-be-signed data] and exponentiating it with its own shares [i.e. the client signs the to-be-signed information with its shard]; Col. 3 Lines 1-8; each signing device’s contents may be duplicated for remote backup / plug-in replacement / got standby, so that if any device fails it can be replaced and service resumes quickly; and a mechanism deactivates or routes around a device on detected fault [i.e. on device fault, signing proceeds through the remaining devices]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Sudia with the method of Hung and Tang. One would be motivated to include a device-fault failover mechanism to reduce the risk of loss from the theft or compromise of any other device (Sudia: Col. 3 Lines 1-8).
Hung, Tang, and Sudia further disclose transmitting the initial signature result to the signing client, so that the signing client performs encryption processing on the initial signature result by using a target private key shard corresponding to the signing client, to obtain a target signature result (Tang: pars. 0063 and 0078; the refreshed hash from the first user’s signing is passed to the next user who signs the refreshed hash to produce a further hash, with the order enforced by requiring signing to originate from the most recent hash [the initial signature result is passed to the signing client, which signs it in turn to produce the target signature result]); and
The motivation is the same as that recited in claim above.
receiving the target signature result transmitted by the signing client, and generating the joint signature result based on the target signature result (Tang: pars. 0063 and 0068; once all required signatories have signed the multi-party transaction, the signatures are combined/finalized [i.e. receiving the signing client’s results and generating the joint signature result]; Hung: pars. 0107-0108; players compute the final
s
; accept if
(
r
,
s
)
is valid [combining contributions into the final joint signature]).
The motivation is the same as that recited in claim above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD HERNANDEZ whose telephone number is (571) 270-0662. The examiner can normally be reached Monday Friday, 9 a.m. 5 p.m. ET..
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, Luu T. Pham can be reached at (571) 270-5002. 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.
/R.H./Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights