DETAILED ACTION
Response to Amendment
Claims 1-22 are pending.
Response to Arguments
Applicants’ arguments filed 07/01/2026 have been fully considered.
The rejection of claim 19 under 35 U.S.C. § 112 has been withdrawn in view of the amendment.
The rejection of claim 1-14 under 35 U.S.C. § 112 has been withdrawn in view of the amendment.
Regarding the rejection of claim 1 under 35 U.S.C. 102(a)(2) as being anticipated by Beaty et al. (US20220414622A1): Firstly, the Examiner notes that Applicants do not argue the claim language. Secondly, Applicant's amendments have necessitated new grounds of rejection, rendering at least some of the arguments moot.
Claim 1 now is rejected under 35 U.S.C. 103 as being unpatentable over Beaty in view of Yantis et al. (US20210326855A1). Although some or all of these new grounds of rejection rely on previously-cited references, the references have been applied in new and different combinations. To the extent that the arguments remain relevant to the new grounds of rejection, they have been considered but are not persuasive. The Examiner will address those arguments that remain relevant to the new grounds of rejection below.
Applicants argue on page 15 that there is no disclosure of a separate external system that independently evaluates registration/deletion rights and returns a grant or denial response to a token register in Beaty.
It seems that the Applicants argue about the “external token registration/deletion check system” in the claims. Since the claims do not explicitly define the “token registration/deletion check system” is “external” with respect to what claim element, therefore under BRI the “external token registration/deletion check system” is properly mapped to the API server 210 in para [0032] of Beaty that respond to the request by first verifying that the requested token distribution complies with the distribution (e.g., deletion) rules.
Applicants argue on page 16 that the distribution rules described in Beaty are not equivalent to the claimed registration/deletion right data records. These data records constitute authorization criteria that are evaluated independently by the external token registration/deletion check system before any modification of the token register occurs, while the distribution rules in Beaty merely govern organizational distribution or withdrawal of already-created organizational tokens and are evaluated internally by API server 210.
Applicants’ arguments are not persuasive. Since the claims do not explicitly require “right data records” constitute authorization criteria that are evaluated independently by the external token registration/deletion check system before any modification of the token register occurs, the “registration/deletion right data record” in the claims is properly mapped to the distribution rules in para [0024] of Beaty that shows which employees or teams can distribute the tokens, how many tokens these employees or teams can distribute, when the tokens can be distributed, which employees or teams can receive the tokens, how many tokens the employees or teams can receive, etc.), withdrawal rules (e.g., when tokens can be withdrawn).
As to any argument not specifically addressed, they are the same as those discussed above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 15 rejected under 35 U.S.C. 103 as being unpatentable over Beaty et al. (US20220414622A1) in view of Yantis et al. (US20210326855A1).
Regarding claim 1, Beaty discloses a token register [entry in token data structures 302] of an electronic token transaction system, comprising: ([Abstract] shows a system allows tokens to be assigned an underlying value in a cryptocurrency and to be associated with distribution rules and withdrawal rules (e.g., transactions); para [0005] shows an API server can receive a request to create a batch of tokens for an organization; para [0033] shows the API server 210 can create an entry in token issuer data structures 303 that defines the batchID, a total number of tokens in the batch that the token issuer has issued, etc. Accordingly, token data structures 302 may include an entry for any token that has been issued):
a communication interface (para [0039] shows API server 210 can interface with storage 300 to create/define the withdrawal of the token);
a token register memory configured to register/delete [melt, withdraw] at least one token of the electronic token transaction system by storing/deleting at least one token reference of the at least one token (para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.; para [0041] shows API server 210 may interface with wallet API server 400 to cause the value of the withdrawal ($10) to be withdrawn form wallet 401 and deposited into wallet 402, which is assumed to be Employee 2's cryptocurrency wallet that he or she has registered with system),
wherein the at least one token is generated by at least one user of the electronic token transaction system (para [0026] shows any user that the admin identifies as being authorized to issue tokens can create an entry in token issuer data structures 303), and
one or more processors coupled to the communication interface and the token register memory, the one or more processors configured to (para [0044]):
receive, via the communication interface, at least one token registration/deletion [distribution] request from the at least one user or from at least one external token registration/deletion check system (para [0031] shows employee 1 may select an option to distribute the selected token; para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules);
provide, via the communication interface, at least one token registration/deletion check request to at least one external token registration/deletion check system (para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules),
the token registration/deletion check request requesting a check of whether the token registration/deletion request fulfills at least one registration/deletion right data record (para [0022] shows storage 300 may also maintain distribution rules 310 which define rules governing the distribution of tokens within system 10 and withdrawal rules 311 which define rules governing the withdrawal of tokens within system 10; para [0024] shows distribution rules (e.g., which employees or teams can distribute the tokens, how many tokens these employees or teams can distribute, when the tokens can be distributed, which employees or teams can receive the tokens, how many tokens the employees or teams can receive, etc.), withdrawal rules (e.g., when tokens can be withdrawn)); and
receive, via the communication interface, at least one token registration/deletion check response from the at least one external token registration/deletion check system indicating whether registration/deletion of the at least one token is granted or denied (para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed); and
register/delete, using the token register memory, the at least one token based on the token registration/deletion check response indicating that the registration/deletion is granted (para [0039] shows API server 210 may update token data structure 302 to include the withdrawal ID and define the withdrawal status.)
Beaty fails to teach the token reference does not comprise a private part of the token-individual cryptographic key pair.
However, Yantis discloses the token reference does not comprise a private part of the token-individual cryptographic key pair (para [0846] shows the distributed ledger may further store account information; a party may only sell, purchase, gift, receive, or otherwise transfer a token if the party has a known account; the address of an account (e.g., token reference) may be based on the public key of the account (e.g., the address may be a hash value of the public key). These addresses may be stored in the distributed ledger, such that addresses involved in a transaction may be verified as corresponding to valid accounts using the distributed ledger.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of Beaty with the teaching of Yantis in order to verify the address that may be a hash value of the public key as corresponding to valid accounts using the distributed ledger (Yantis; para [0846]).
Regarding claim 2, Beaty-Yantis as applied to claim 1 discloses the one or more processors are further configured to check an integrity and/or a cryptographic element of the at least one user or the at least one external token registration/deletion check system (Beaty; para [0029] shows Employee 1 could log in with his or her credentials within system 10. API server 210 can identify any tokens that Employee 1 is authorized to distribute.)
Regarding claim 3, Beaty-Yantis as applied to claim 1 discloses the one or more processors are further configured to provide at least one registration/deletion response to the at least one user (Beaty; [Abstract] shows when the organization approves an employee's withdrawal of a token's underlying value, the system can manage the distribution of the token's underlying value to the employee's cryptocurrency wallet and can provide functionality for tracking, reporting and auditing such transactions.)
Regarding claim 4, Beaty-Yantis as applied to claim 1 discloses the token registration/deletion request comprises a CREATE command, a DELETE command, a token reference, a monetary value of the token and/or a registration/deletion reference (Beaty; para [0005] shows an API server can receive a request to create a batch of tokens for an organization. The request can identify a value of the tokens in the batch; para [0033] shows API server 210 can interface with storage 300 to create/define an entry that includes/defines a tokenID to uniquely represent the token in system 10, a date the token was issued, whether the token has been melted, a date the token was melted, etc.),
wherein the CREATE command comprises a value, a public key of a token-individual cryptographic key pair, and a signature of a token issuer (Beaty; para [0026] shows API server 210 can create an entry in token issuer data structures 303 that defines the batchID, an issuerID (e.g., the user ID of the user within system 10); para [0005] shows an API server can receive a request to create a batch of tokens for an organization. The request can identify a value of the tokens in the batch. Yantis; para [0884] shows the token generation system 302 may digitally sign the value using a private key/public key pair), and
wherein the DELETE command comprises the value, the public key, a signature of a private key that corresponds to the public key, and a signature of the token issuer (Beaty; para [0033] shows API server 210 to create/define an entry that includes/defines a tokenID to uniquely represent the token in system 10, a date the token was issued, whether the token has been melted, a date the token was melted; para [0026] shows API server 210 can create an entry in token issuer data structures 303 that defines the batchID, an issuerID (e.g., the user ID of the user within system 10). Yantis; para [0884] shows the token generation system 302 may digitally sign the value using a private key/public key pair.)
Regarding claim 15, Beaty-Yantis as applied to claim 1 discloses an electronic token transaction system comprising (Beaty; [Abstract] shows a system allows tokens to be assigned an underlying value in a cryptocurrency and to be associated with distribution rules and withdrawal rules (e.g., transactions)):
at least one user (Beaty; para [0031] shows employee 1);
a token register according to claim 1 (Beaty; para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.);
a token registration/deletion [melt, withdraw] check system comprising (Beaty; para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.; para [0041] shows API server 210 may interface with wallet API server 400 to cause the value of the withdrawal ($10) to be withdrawn form wallet 401 and deposited into wallet 402, which is assumed to be Employee 2's cryptocurrency wallet that he or she has registered with system):
a communication interface (Beaty; para [0039] shows API server 210 can interface with storage 300 to create/define the withdrawal of the token);
a memory storing at least one registration/deletion right data record for granting or denying a token registration/deletion (Beaty; para [0022] shows storage 300 may also maintain distribution rules 310 which define rules governing the distribution of tokens within system 10 and withdrawal rules 311 which define rules governing the withdrawal of tokens within system 10; para [0024] shows distribution rules (e.g., which employees or teams can distribute the tokens, how many tokens these employees or teams can distribute, when the tokens can be distributed, which employees or teams can receive the tokens, how many tokens the employees or teams can receive, etc.), withdrawal rules (e.g., when tokens can be withdrawn)); and
one or more processors coupled to the communication interface and the memory, the one or more processors configured to (para [0044]):
receive, via the communication interface, at least one token registration/deletion check request from at least one token register being external to the token registration/deletion check system (Beaty; para [0031] shows employee 1 may select an option to distribute the selected token; para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules);
determine whether the received token registration/deletion check request fulfills the at least one registration/deletion right data record by comparing data of the received token registration/deletion check request with data of the at least one registration/deletion right data record (Beaty; para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed); and
a token registration/deletion grant or denial unit for granting or denying grant or deny the token registration/deletion as requested by the received at least one token registration/deletion check request based on the determination (Beaty; para [0037] shows API server 210 determined that the requested withdrawal is allowed.)
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 5-14 and 16-22 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Beaty.
Regarding claim 5, Beaty discloses a token registration/deletion [distribution and withdrawal] check system of an electronic token transaction system, comprising ([Abstract] shows a system allows tokens to be assigned an underlying value in a cryptocurrency and to be associated with distribution rules and withdrawal rules (e.g., transactions); para [0033] shows API server 210 can create an entry in token issuer data structures 303 that defines the batchID, an issuerID, a total number of tokens in the batch that the token issuer has issued, etc. Accordingly, token data structures 302 may include an entry for any token that has been issued);
a communication interface (para [0018] shows client devices 100 can interface with system 10);
a memory storing at least one registration/deletion right data record for granting or denying a token registration/deletion (para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.); and
one or more processors coupled to the communication interface and the memory, the one or more processors configured to (para [0044]):
receive, via the communication interface, at least one token registration/deletion check request from at least one token register being external to the token registration/deletion check system (para [0031] shows employee 1 may select an option to distribute the selected token; para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules);
determine whether the received token registration/deletion check request fulfills the at least one registration/deletion right data record by comparing data of the received token registration/deletion check request with data of the at least one registration/deletion right data record (para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed); and
grant or deny the token registration/deletion as requested by the received at least one token registration/deletion check request based on the determination (para [0037] shows API server 210 determined that the requested withdrawal is allowed.)
Regarding claim 6, Beaty as applied to claim 5 discloses the one or more processors are further configured to transmit a token registration/deletion check response to the at least one token register, wherein the token registration/deletion check response is based on a result of granting or denying the token registration/deletion (Beaty; para [0031] shows employee 1 may select an option to distribute the selected token; para [0033] shows if API server 210 determines that the requested token distribution complies with the defined distribution rules, API server 210 can interface with storage 300 to create an entry that includes/defines a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.))
Regarding claim 7, Beaty as applied to claim 5 discloses the one or more processors are further configured to receive a registration/deletion query from the at least one user and provide unit for providing a token registration/deletion query to the at least one token register (Beaty; para [0031] shows employee 1 may select an option to distribute the selected token; para [0024] shows API server 210 may query storage 300 to compare the value of any existing minted batches and the batch to be minted to the balance in wallet 401; para [0029] shows API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively).
Regarding claim 8, Beaty as applied to claim 5 discloses the one or more processors are further configured to provide at least one registration/deletion query response to the at least one user (Beaty; para [0031] shows employee 1 may select an option to distribute the selected token; para [0024] shows API server 210 may query storage 300 to identify any batches that the organization has already minted and then compare the value of any existing minted batches and the batch to be minted to the balance in wallet 401; para [0029] shows API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively; para [0037] shows API server 210 determined that the requested withdrawal is allowed).
Regarding claim 9, Beaty as applied to claim 5 discloses the memory stores at least one registration/deletion right data record for granting a limited right to register authorizing registration of a token to/delete a token from the token register, the registration/deletion right data record comprising at least one of a budget, contingent, quota, limited time, workflow approval, majority voting result, or transaction stored in a distributed ledger system (Beaty; para [0027] shows a withdrawal rule for the batch may be selected from a plurality of available withdrawal rules such as: withdrawal after a specified date, withdrawal after a specified duration of time after a token is issued, withdrawal during a specified range of time, withdrawal before a specified date, etc.; para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.)
Regarding claim 10, Beaty as applied to claim 9 discloses the registration/deletion right data record is published and granted by an external registration/deletion right providing unit provider (Beaty; para [0026] shows the distribution rules the admin specified in the batch creation input; para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed.)
Regarding claim 11, Beaty as applied to claim 10 discloses the registration/deletion right data record is a published and granted in a distributed ledger system (Beaty; [Abstract] shows a system allows tokens to be assigned an underlying value in a cryptocurrency and to be associated with distribution rules and withdrawal rules; para [0026] shows the distribution rules the admin specified in the batch creation input; para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed; para [0039] shows API server 210 may update token data structure 302 to include the withdrawal ID and define the withdrawal status; para [0048] shows a distributed system environment.)
Regarding claim 12, Beaty as applied to claim 9 discloses the registration/deletion right data record indicates an existence of a registration/deletion transaction in a distributed ledger system, wherein the registration/deletion transaction is created by at least two other users (Beaty; para [0029] shows employee 1 can select one of the distributable tokens; para [0030] shows Employee 2 selects an option to receive a token; para [0039] shows API server 210 may update token data structure 302 to include the withdrawal ID and define the withdrawal status; para [0048] shows a distributed system environment.)
Regarding claim 13, Beaty as applied to claim 9 discloses the registration/deletion right data record indicates an existence of an amount to be created in the electronic token transaction system (TS) being deleted in another electronic token transaction system (ATS) and vice versa (Beaty; para [0029] shows API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively. Employee 1 can select one of the distributable tokens (e.g., from Employee 1's wallet); para [0030] shows a wallet address could be formed by combining the OrgID and Userld; Employee 2 selects an option to receive a token in Employee 2's wallet).
Regarding claim 14, Beaty as applied to claim 9 discloses the one or more processors are further configured to receive at least one registration/deletion right data record from the external registration/deletion right provider (Beaty; para [0029] shows employee 1 can select one of the distributable tokens (e.g., from Employee 1's wallet); para [0030] shows a wallet address could be formed by combining the OrgID and Userld; Employee 2 selects an option to receive a token in Employee 2's wallet).
Regarding claim 16, Beaty discloses a method for registering/deleting [distribution, withdrawal] a token of an electronic token transaction system, comprising ([Abstract] shows a system allows tokens to be assigned an underlying value in a cryptocurrency and to be associated with distribution rules and withdrawal rules (e.g., transactions)):
generating at least one token of the electronic token transaction system by at least one user (para [0024] shows API server 210 may query storage 300 to identify any batches that the organization has already minted and then compare the value of any existing minted batches and the batch to be minted to the balance in wallet 401);
receiving by a token register a token registration/deletion request from at least one user or from at least one external token registration/deletion check system, the token registration/deletion request comprising at least one token reference of the generated at least one token (para [0031] shows employee 1 may select an option to distribute the selected token; para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules);
providing a token registration/deletion check request from the token register to at least one external token registration/deletion check system (para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules);
checking by the at least one external token registration/deletion check system if the token registration/deletion request fulfills at least one registration/deletion right data record (para [0022] shows storage 300 may also maintain distribution rules 310 which define rules governing the distribution of tokens within system 10 and withdrawal rules 311 which define rules governing the withdrawal of tokens within system 10; para [0024] shows distribution rules (e.g., which employees or teams can distribute the tokens, how many tokens these employees or teams can distribute, when the tokens can be distributed, which employees or teams can receive the tokens, how many tokens the employees or teams can receive, etc.), withdrawal rules (e.g., when tokens can be withdrawn));
providing a token registration/deletion check response indicating a result of the checking to the token register (para [0036] shows API server 210 may access withdrawal rules 311 to determine if the requested withdrawal is allowed); and
registering or deleting at least one token of the electronic token transaction system in the token register based on the result of the checking ([Abstract] shows when the organization approves an employee's withdrawal of a token's underlying value, the system can manage the distribution of the token's underlying value to the employee's cryptocurrency wallet and can provide functionality for tracking, reporting and auditing such transactions),
wherein the registering or deleting of the at least one token comprises storing/deleting at least one token reference of the generated at least one token (para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.; para [0041] shows API server 210 may interface with wallet API server 400 to cause the value of the withdrawal ($10) to be withdrawn form wallet 401 and deposited into wallet 402, which is assumed to be Employee 2's cryptocurrency wallet that he or she has registered with system).
Regarding claim 17, Beaty as applied to claim 16 discloses:
checking an integrity and/or a cryptographic element of the at least one user or of the at least one external token registration/deletion check system by the token register before providing a token registration/deletion check request from the token register to at least one external token registration/deletion check system (para [0029] shows API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively; para [0031] shows employee 1 may select an option to distribute the selected token; para [0032] shows API server 210 can respond to the request by first verifying that the requested token distribution complies with the distribution rules; para [0033] shows API server 210 can interface with storage 300 to create an entry that includes/defines whether the token has been melted, a date the token was melted, a withdrawal identification (e.g., a unique identifier created when the token is withdrawn), a withdrawal status, etc.; para [0040] shows system 10 enables an organization to quickly audit cryptocurrency; para [0041] shows API server 210 to determine whether 25 tokens are available to be melted.)
Regarding claim 18, Beaty as applied to claim 16 discloses:
receiving by the at least one external token registration/deletion check system at least one registration/deletion right data record from an external registration/deletion right provider (para [0029] shows a API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively. In step 1 c, API server 210 can cause the owned and distributable tokens (or only the distributable tokens) to be presented to Employee 1 such as within the token website. Then, in step 1 d, Employee 1 can select one of the distributable tokens; para [0022] shows storage 300 may also maintain distribution rules 310 which define rules governing the distribution of tokens within system 10 and withdrawal rules 311 which define rules governing the withdrawal of tokens within system 10; para [0024] shows distribution rules (e.g., which employees or teams can distribute the tokens, how many tokens these employees or teams can distribute, when the tokens can be distributed, which employees or teams can receive the tokens, how many tokens the employees or teams can receive, etc.), withdrawal rules (e.g., when tokens can be withdrawn).)
Regarding claim 19, Beaty as applied to claim 16 discloses:
receiving from the at least one user a registration/deletion query by the token registration/deletion check system (para [0031] shows employee 1 may select an option to distribute the selected token), and providing by the token registration/deletion check system a token registration/deletion query to the at least one token register (para [0029] shows a API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively. In step 1 c, API server 210 can cause the owned and distributable tokens (or only the distributable tokens) to be presented to Employee 1 such as within the token website. Then, in step 1 d, Employee 1 can select one of the distributable tokens.)
Regarding claim 20, Beaty as applied to claim 16 discloses:
providing by the token registration/deletion check system at least one registration/deletion query response from the token registration/deletion check system to the at least one user (para [0029] shows a API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively. In step 1 c, API server 210 can cause the owned and distributable tokens (or only the distributable tokens) to be presented to Employee 1 such as within the token website. Then, in step 1 d, Employee 1 can select one of the distributable tokens; para [0037] shows API server 210 determined that the requested withdrawal is allowed.)
Regarding claim 21, Beaty as applied to claim 16 discloses providing by the token register at least one registration/deletion response from the token register to the at least one user (para [0029] shows a API server 210 could identify Employee 1's owned and distributable tokens by querying token data structures 302 and token issuer data structures 303 respectively. In step 1 c, API server 210 can cause the owned and distributable tokens (or only the distributable tokens) to be presented to Employee 1 such as within the token website. Then, in step 1 d, Employee 1 can select one of the distributable tokens; para [0037] shows API server 210 determined that the requested withdrawal is allowed.)
Regarding claim 22, Beaty as applied to claim 16 discloses issuing or destroying by the at least one user at least one token registered in the token register (para [0025] shows a batchID to uniquely identify the OrgID of the requesting organization, number of tokens minted/created, the number of tokens melted, etc.)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAN DOAN whose telephone number is (571)270-0162. The examiner can normally be reached Monday - Friday 8am - 5pm 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, Oscar Louie, can be reached at (571) 270-1684. 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.
/TAN DOAN/Primary Examiner, Art Unit 2445
Prosecution Insights