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 .
Interview Summary
On September 22, 2025, the Examiner initiated a call with Applicant's representative, Alex J. Johnson to discuss claim amendments to move prosecution forward, however, Applicant's representative requested to issue an Office Action.
Status of Claims
This is a first office action on the merits, in response to the claims filed on December 20, 2023.
Claims 1-24 are pending.
Claims 1-24 have been examined.
Claim Objections
Claims 1-24 objected to because of the following informalities:
Claim 1 recites “on condition that (i) a management server has transmitted a user wallet address, a voting contract address and a first user nonce value to a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, (ii) the user terminal has transmitted voting message signing request information, including the voting contract address, the user wallet address, a specific agenda ID, a specific sector index corresponding to a specific agenda, a voted quantity of the secondary stakable tokens and the first user nonce value, to the management server, wherein the specific sector index is an index value corresponding to a specific sector, among a 1-st sector to an n-th sector, on which a user of the user terminal intends to vote, and then (iii) the management server has transmitted a first user signature value, generated by signing the voting message signing request information with a user private key, to the user terminal”.
This is conditional language limitation. The following limitations only gets performed:
receiving, by a content providing server, voting request information, including the voting contract address, the user wallet address, the specific agenda ID, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value and the first user signature value, from the user terminal;
(b) (i) verifying, by the content providing server, the first user signature value included in the voting request information acquired from the user terminal, (ii) acquiring, by the content providing server, a hashed first user signature value by hashing the first user signature value upon completion of the process of verifying the first user signature value, and (iii) acquiring, by the content providing server, a first validator signature value by signing the hashed first user signature value with a validator private key; and
( c) transmitting, by the content providing server, voting transaction information, including the specific agenda ID, the user wallet address, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value, the first user signature value and the first validator signature value, to the management server, and then receiving, by the content providing server, a voting result corresponding to the voting transaction information from the management server, to thereby transmit the voting result to the user terminal.
When the “on condition that (i) a management server has transmitted a user wallet address…” but is not performed otherwise.
The Examiner recommends, amending the claims to positively capture (e.g., positively recite) all of the limitations (i.e., conditional recited steps), including the dependents claims. Accordingly, once the positively recited steps are satisfied, the method as a whole is satisfied -- regardless of whether or not other steps are conditionally performed under certain other hypothetical scenarios. See MPEP § 2103 IC.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-12 are directed to a method, and claims 13-24 are directed to a system comprising at least one memory that stores instructions and at least one processor configured to execute the instructions. Therefore, these claims fall within the four statutory categories of invention.
The claims recite an abstract idea of receiving and transmitting data (e.g., voting information data). Specifically, the claims recite “(a) on condition that (i) a management server has transmitted a user wallet address, a voting contract address and a first user nonce value to a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, (ii) the user terminal has transmitted voting message signing request information, including the voting contract address, the user wallet address, a specific agenda ID, a specific sector index corresponding to a specific agenda, a voted quantity of the secondary stakable tokens and the first user nonce value, to the management server, wherein the specific sector index is an index value corresponding to a specific sector, among a 1-st sector to an n-th sector, on which a user of the user terminal intends to vote, and then (iii) the management server has transmitted a first user signature value, generated by signing the voting message signing request information with a user private key, to the user terminal, receiving, by a content providing server, voting request information, including the voting contract address, the user wallet address, the specific agenda ID, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value and the first user signature value, from the user terminal; (b) (i) verifying, by the content providing server, the first user signature value included in the voting request information acquired from the user terminal, (ii) acquiring, by the content providing server, a hashed first user signature value by hashing the first user signature value upon completion of the process of verifying the first user signature value, and (iii) acquiring, by the content providing server, a first validator signature value by signing the hashed first user signature value with a validator private key; and ( c) transmitting, by the content providing server, voting transaction information, including the specific agenda ID, the user wallet address, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value, the first user signature value and the first validator signature value, to the management server, and then receiving, by the content providing server, a voting result corresponding to the voting transaction information from the management server, to thereby transmit the voting result to the user terminal.”, which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106.04(a)) because it describes a process for carrying out a commercial interaction between parties that involves communicating data needed to complete a transaction to the parties. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(a or d)), the additional element(s) of the claim(s) such as at least one memory and at least one processor merely use(s) a computer as a tool to perform an abstract idea. Specifically, the at least one memory and at least one processor perform(s) the steps or functions of “(a) on condition that (i) a management server has transmitted a user wallet address, a voting contract address and a first user nonce value to a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, (ii) the user terminal has transmitted voting message signing request information, including the voting contract address, the user wallet address, a specific agenda ID, a specific sector index corresponding to a specific agenda, a voted quantity of the secondary stakable tokens and the first user nonce value, to the management server, wherein the specific sector index is an index value corresponding to a specific sector, among a 1-st sector to an n-th sector, on which a user of the user terminal intends to vote, and then (iii) the management server has transmitted a first user signature value, generated by signing the voting message signing request information with a user private key, to the user terminal, receiving, by a content providing server, voting request information, including the voting contract address, the user wallet address, the specific agenda ID, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value and the first user signature value, from the user terminal; (b) (i) verifying, by the content providing server, the first user signature value included in the voting request information acquired from the user terminal, (ii) acquiring, by the content providing server, a hashed first user signature value by hashing the first user signature value upon completion of the process of verifying the first user signature value, and (iii) acquiring, by the content providing server, a first validator signature value by signing the hashed first user signature value with a validator private key; and ( c) transmitting, by the content providing server, voting transaction information, including the specific agenda ID, the user wallet address, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value, the first user signature value and the first validator signature value, to the management server, and then receiving, by the content providing server, a voting result corresponding to the voting transaction information from the management server, to thereby transmit the voting result to the user terminal.” The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (See MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (See MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (See MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional element(s) of using at least one memory and at least one processor to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of receiving and transmitting data (e.g., voting information data). As discussed above, taking the claim elements separately, the at least one memory and at least one processor perform(s) the steps or functions of “(a) on condition that (i) a management server has transmitted a user wallet address, a voting contract address and a first user nonce value to a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, (ii) the user terminal has transmitted voting message signing request information, including the voting contract address, the user wallet address, a specific agenda ID, a specific sector index corresponding to a specific agenda, a voted quantity of the secondary stakable tokens and the first user nonce value, to the management server, wherein the specific sector index is an index value corresponding to a specific sector, among a 1-st sector to an n-th sector, on which a user of the user terminal intends to vote, and then (iii) the management server has transmitted a first user signature value, generated by signing the voting message signing request information with a user private key, to the user terminal, receiving, by a content providing server, voting request information, including the voting contract address, the user wallet address, the specific agenda ID, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value and the first user signature value, from the user terminal; (b) (i) verifying, by the content providing server, the first user signature value included in the voting request information acquired from the user terminal, (ii) acquiring, by the content providing server, a hashed first user signature value by hashing the first user signature value upon completion of the process of verifying the first user signature value, and (iii) acquiring, by the content providing server, a first validator signature value by signing the hashed first user signature value with a validator private key; and ( c) transmitting, by the content providing server, voting transaction information, including the specific agenda ID, the user wallet address, the specific sector index, the voted quantity of the secondary stakable tokens, the first user nonce value, the first user signature value and the first validator signature value, to the management server, and then receiving, by the content providing server, a voting result corresponding to the voting transaction information from the management server, to thereby transmit the voting result to the user terminal.” These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving and transmitting data (e.g., voting information data). Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Examiner’s Note: with respect to independent claim 13, claim 13 recites, “a management server has transmitted a user wallet address, a voting contract address and a first user nonce value to a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, (ii) the user terminal has transmitted voting message signing request information, including the voting contract address, the user wallet address, a specific agenda ID, a specific sector index corresponding to a specific agenda, a voted quantity of the secondary stakable tokens and the first user nonce value, to the management server, wherein the specific sector index is an index value corresponding to a specific sector, among a 1- st sector to an n-th sector, on which a user of the user terminal intends to vote, and then (iii) the management server has transmitted a first user signature value, generated by signing the voting message signing request information with a user private key, to the user terminal”. These limitations do not limit the functionality of the claimed content providing server because these limitations are outside the scope of the claimed content providing server. Furthermore, these limitations falls outside the scope of the claimed invention because it recites operation not performed by the claimed content providing server. Therefore, these limitations have limited patentable weight since step of “management server has transmitted…and the voting request having been generated through the user terminal…” is not positively tied with any structure element of the claimed content providing server. And with respect to the method claim 1, this limitation is not positively recited functional step and hence receive limited patentable weight.
Regarding dependent claims
Claims 2 and 14 recite: (aO) (i) on condition that (1) the management server has transmitted the user wallet address to the user terminal in response to a staking request for the primary stakable tokens from the user terminal, (2) the content providing server has transmitted first use permission request transaction information to be used for requesting permission to use the primary stakable tokens to the management server and then the management server has transmitted first hashed use permission request transaction information, generated by hashing the first use permission request transaction information, to the content providing server, (3) the content providing server has transmitted first staking request transaction information to the management server and then the management server has transmitted first hashed staking request transaction information, generated by hashing the first staking request transaction information, to the content providing server, and (4) the content providing server has transmitted the first hashed use permission request transaction information and the first hashed staking request transaction information to the user terminal, instructing, by the content providing server, the management server to (i-1) receive a signing request on the first hashed use permission request transaction information and the first hashed staking request transaction information, (i-2) generate a first specific user signature value by signing the first hashed use permission request transaction information and the first hashed staking request transaction information with a specific user key, and (i-3) transmit the first specific user signature value to the user terminal; (ii) on condition that (1) the user terminal has transmitted the first hashed use permission request transaction information, the first hashed staking request transaction information and the first specific user signature value to the content providing server, and (2) the content providing server has transmitted second use permission request transaction information, including the first hashed use permission request transaction information and the first specific user signature value, to the management server, instructing, by the content providing server, the management server to invoke a token management contract and execute a token use permission request function whose parameters include a token staking contract address and a staking quantity of the primary stakable tokens, to thereby receive primary stakable token use permission request processing information and transmit the primary stakable token use permission request processing information to the content providing server; (iii) on condition that the content providing server has transmitted second staking request transaction information, including the first hashed staking request transaction information and the first specific user signature value, to the management server, instructing, by the content providing server, the management server to invoke a token staking contract and execute a token staking function whose parameters include the staking quantity of the primary stakable tokens, to thereby receive primary stakable token staking processing information and transmit the primary stakable token staking processing information to the content providing server; and (iv) (iv-I) determining, by the content providing server, a quantity of the secondary stakable tokens to be distributed to the user terminal by referring to the primary stakable token staking processing information and (iv-2) granting, by the content providing server, a voting right for the specific event to be performed on the content to the user terminal by referring to a staking quantity of the secondary stakable tokens.
Claims 3 and 15 recite: (al) (i) on condition that (1) the management server has transmitted the user wallet address to the user terminal in response to a staking request for at least one of the primary stakable tokens among the a-th primary stakable tokens and the b-th primary stakable tokens from the user terminal, (2) the content providing server has transmitted first use permission request transaction information to be used for requesting permission to use the primary stakable tokens to the management server and then the management server has transmitted first hashed use permission request transaction information, generated by hashing the first use permission request transaction information, to the content providing server, (3) the content providing server has transmitted first staking request transaction information to the management server and then the management server has transmitted first hashed staking request transaction information, generated by hashing the first staking request transaction information, to the content providing server, and (4) the content providing server has transmitted the first hashed use permission request transaction information and the first hashed staking request transaction information to the user terminal, instructing, by the content providing server, the management server to (i-1) receive a signing request on the first hashed use permission request transaction information and the first hashed staking request transaction information from the user terminal, (i-2) generate a first specific user signature value by signing the first hashed use permission request transaction information and the first hashed staking request transaction information with a specific user key, and (i-3) transmit the first specific user signature value to the user terminal; (ii) on condition that (1) the user terminal has transmitted the first hashed use permission request transaction information, the first hashed staking request transaction information and the first specific user signature value to the content providing server, and (2) the content providing server has transmitted second use permission request transaction information, including the first hashed use permission request transaction information and the first specific user signature value, to the management server, instructing, by the content providing server, the management server to invoke a token management contract and execute a token use permission request function whose parameters include a token staking contract address and a staking quantity of the primary stakable token, to thereby receive primary stakable token use permission request processing information and transmit the primary stakable token use permission request processing information to the content providing server; (iii) on condition that the content providing server has transmitted second staking request transaction information, including the first hashed staking request transaction information and the first specific user signature value, to the management server, instructing, by the content providing server, the management server to invoke a token staking contract and execute a token staking function whose parameters include the staking quantity of the primary stakable token, to thereby receive primary stakable token staking processing information and transmit the primary stakable token staking processing information to the content providing server; and (iv) (iv-I) determining, by the content providing server, a quantity of the secondary stakable tokens to be distributed to the user terminal by referring to the primary stakable token staking processing information and (iv-2) granting, by the content providing server, a voting right for the specific event to be performed on the content to the user terminal by referring to a staking quantity of the secondary stakable tokens.
Claims 4 and 16 recite: (a2) on condition that the management server has transmitted the user wallet address, linked to the user terminal, to the user terminal in response to receiving the voting request from the user terminal, (i) receiving, by the content providing server, request information for the voting contract address from the user terminal, (ii) transmitting, by the content providing server, the request information for the voting contract address to the management server and receiving, by the content providing server, the voting contract address corresponding to the request information from the management server to transmit the voting contract address to the user terminal, and (iii) on condition that the first user nonce value corresponding to the voting contract has been transmitted to the user terminal in response to a request for the first user nonce value from the user terminal, instructing, by the content providing server, the user terminal to generate the voting message signing request information, including the voting contract address, the user wallet address, the specific agenda ID, the specific sector index corresponding to the specific agenda, the voted quantity of the secondary stakable tokens and the first user nonce value.
Claims 5 and 17 recite: (aOI) the content providing server (i) (i-I) receiving a specific agenda generation contract address from the management server by requesting information on the specific agenda generation contract address, corresponding to the specific agenda, to the management server and (i-2) receiving a previous agenda ID, which is most recently generated by requesting the previous agenda ID from the management server, (ii) (ii-I) generating specific agenda generation request message information, including the specific agenda generation contract address, the previous agenda ID, specific agenda generation purpose information corresponding to the specific agenda, a minimum voting quantity of the secondary stakable tokens, cool time information corresponding to the specific agenda and cancel lock information corresponding to the specific agenda, and (ii- 2) acquiring hashed specific agenda generation request message information from the management server by requesting hashing of the specific agenda generation request message information to the management server, and (iii) (iii-I) acquiring a second validator signature value by signing the hashed specific agenda generation request message information with the validator private key and (iii-2) transmitting specific agenda generation transaction information, including the specific agenda generation purpose information, the minimum voting quantity of the secondary stakable tokens, the cool time information, the cancel lock information and the second validator signature value, to the management server to thereby receive a specific agenda generation result corresponding to the specific agenda generation transaction information from the management server.
Claims 6 and 18 recite: (a02) the content providing server (i) (i-I) receiving a specific sector generation contract address from the management server by requesting information on the specific sector generation contract address, corresponding to the specific sector index, to the management server and (i-2) receiving a first validator nonce value and the specific agenda ID by requesting the first validator nonce value and the specific agenda ID from the management server, (ii) (ii-I) generating specific sector generation request message information, including the specific sector generation contract address, the specific agenda ID, the first validator nonce value, specific sector generation purpose information and a specific sector account address, and (ii-2) acquiring hashed specific sector generation request message information from the management server by requesting hashing of the specific sector generation request message information to the management server, and (iii) (iii-I) acquiring a third validator signature value by signing the hashed specific sector generation request message information with the validator private key and (iii-2) transmitting specific sector generation transaction information, including the specific agenda ID, the first validator nonce value, the specific sector generation purpose information, the specific sector account address and the third validator signature value, to the management server to thereby receive a specific sector generation result corresponding to the specific sector generation transaction information from the management server.
Claims 7 and 19 recite: the content providing server (i) (i-I) receiving a sector change contract address from the management server by requesting information on the sector change contract address to the management server and (i-2) receiving a second validator nonce value and the specific agenda ID by requesting the second validator nonce value and the specific agenda ID from the management server, (ii) (ii-I) generating sector change request message information, including the sector change contract address, the specific agenda ID, the second validator nonce value, another sector index corresponding to the another sector, sector change purpose information and another sector account address corresponding to the another sector, and (ii-2) acquiring hashed sector change request message information from the management server by requesting hashing of the sector change request message information to the management server and (iii) (iii-I) acquiring a fourth validator signature value by signing the hashed sector change request message information with the validator private key and (iii-2) transmitting sector change transaction information, including the specific agenda ID, the second validator nonce value, the sector change purpose information, the another sector index, the another sector account address and the fourth validator signature value, to the management server to thereby receive a sector change result corresponding to the sector change transaction information from the management server.
Claims 8 and 20 recite: (d) in order to deactivate the specific sector, the content providing server (i) (i-1) requesting information on a specific sector deactivation contract address corresponding to the specific sector index to the management server to thereby receive the specific sector deactivation contract address and (i-2) receiving a third validator nonce value and the specific agenda ID by requesting the third validator nonce value and the specific agenda ID from the management server, (ii) (ii-I) generating specific sector deactivation request message information, including the specific sector deactivation contract address, the specific agenda ID, the specific sector index and the third validator nonce value, and (ii-2) acquiring hashed specific sector deactivation request message information from the management server by requesting hashing of the specific sector deactivation request message information to the management server, and (iii) (iii-I) acquiring a fifth validator signature value by signing the hashed specific sector deactivation request message information with the validator private key and (iii-2) transmitting specific sector deactivation transaction information, including the specific agenda ID, the specific sector index, the third validator nonce value and the fifth validator signature value, to the management server to thereby receive a specific sector deactivation result corresponding to the specific sector deactivation transaction information from the management server.
Claims 9 and 21 recite: (e) in response to the specific sector or the voting result for the specific sector being determined to meet one or more predetermined conditions, the content providing server (i) (i-1) receiving a specific agenda cancellation contract address from the management server by requesting information on the specific agenda cancellation contract address corresponding to the specific agenda to the management server, (i-2) generating specific agenda cancellation request message information, including the specific agenda cancellation contract address and the specific agenda ID, and (i-3) acquiring hashed specific agenda cancellation request message information from the management server by requesting hashing of the specific agenda cancellation request message information to the management server, and (ii) (ii-I) acquiring a sixth validator signature value by signing the hashed specific agenda cancellation request message information with the validator private key and (ii-2) transmitting specific agenda cancellation transaction information, including the specific agenda ID and the sixth validator signature value, to the management server to thereby receive a specific agenda cancellation result corresponding to the specific agenda cancellation transaction information from the management server.
Claims 10 and 22 recite: (f) the content providing server (i) (i-1) determining the specific sector at which the specific agenda is to be executed, (i-2) receiving a specific agenda execution contract address from the management server by requesting information on the specific agenda execution contract address to the management server and (i-3) receiving a fourth validator nonce value and the specific agenda ID by requesting the fourth validator nonce value and the specific agenda ID from the management server, (ii) (ii-I) generating specific agenda execution request message information, including the specific agenda execution contract address, the specific agenda ID, the specific sector index and the fourth validator nonce value, and (ii-2) acquiring hashed specific agenda execution request message information from the management server by requesting hashing of the specific agenda execution request message information to the management server, and (iii) (iii-I) acquiring a seventh validator signature value by signing the hashed specific agenda execution request message information with the validator private key and (iii-2) transmitting specific agenda execution transaction information, including the specific agenda ID, the specific sector index, the fourth validator nonce value and the seventh validator signature value, to the management server to thereby receive a specific agenda execution result corresponding to the specific agenda execution transaction information from the management server.
Claims 11 and 23 recite: wherein, at the step of (b), the content providing server transmits the voting request information to the management server and then instructs the management server to (i) acquire the voting message signing request information by decrypting the first user signature value included in the voting request information with a user public key and (ii) transmit the user wallet address included in the voting message signing request information to the content providing server, and wherein the content providing server confirms whether the user wallet address, which is included in the voting message signing request information and transmitted from the management server, and the user wallet address, which is included in the voting request information and transmitted from the user terminal, match with each other, to thereby verify the first user signature value and the user wallet address.
Claims 12 and 24 recite: (g) on condition that (1) the management server has transmitted the user wallet address, a voting token withdrawal contract address and a second user nonce value to the user terminal in response to a voting token withdrawal request received from the user terminal, (2) the user terminal has transmitted voting token withdrawal message signature request information, including the voting token withdrawal contract address, the user wallet address, the specific agenda ID, the specific sector index, a voting token withdrawal quantity and the second user nonce value, to the management server, and then (3) the management server has transmitted a second user signature value, generated by signing the voting token withdrawal message signature request information with the user private key, to the user terminal, (i) receiving, by the content providing server, voting token withdrawal request information, including the voting token withdrawal contract address, the user wallet address, the specific agenda ID, the specific sector index, the voting token withdrawal quantity, the second user nonce value and the second user signature value, transmitted from the user terminal, (ii) (ii-I) performing, by the content providing server, a process of verifying the second user signature value included in the voting token withdrawal request information acquired from the user terminal, (ii-2) acquiring, by the content providing server, a hashed second user signature value by hashing the second user signature value upon completion of the process of verifying the second user signature value, and (ii-3) acquiring, by the content providing server, an eighth validator signature value by signing the hashed second user signature value with the validator private key, and (iii) transmitting, by the content providing server, voting token withdrawal transaction information, including the specific agenda ID, the user wallet address, the specific sector index, the voting token withdrawal quantity, the second user nonce value, the second user signature value and the eighth validator signature value, to the management server, and then receiving, by the content providing server, a voting token withdrawal result corresponding to the voting token withdrawal transaction information from the management server to thereby transmit the voting token withdrawal result to the user terminal.
Dependent claims further describe the abstract idea of receiving and transmitting data (e.g., voting information data). The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a management server has transmitted a user wallet address, in claims 1 and 13 and in the dependent claims.
a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, in claims 1 and 13 and in the dependent claims.
As noted above, the claim limitations invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because they use generic placeholders such as “management server”, “user terminal” coupled with functional language “transmitted”, “generated” without reciting sufficient structure to achieve the function. Furthermore, the generic placeholder is not further modified by sufficient structure or material for performing the claimed function. The generic placeholders mentioned above are considered generic because the functions can be performed by either software or hardware or the combination of hardware and software, and equivalents thereof and the words themselves do not imply obvious structure. For example, the “management server”, “user terminal”, originally-filed specification discloses [0066]: the management server 200 may include an authentication server 201, a resource server 202, and a blockchain intermediary server 203. In this case, each of the authentication server 201, resource server 202, and blockchain intermediary server 203 included in the management server 200 may be implemented as a physical server or a software server.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 13-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
For example, claim 13 recites, “a management server has transmitted a user wallet address; “a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens”. The originally-filed specification does not provide an adequate structure to perform the claimed functions listed above. The originally-filed specification does not demonstrate that the applicant has made an invention that achieves the claimed functions because the invention is not described in sufficient details such that one of ordinary skill in the art can reasonably conclude that the inventor has possession of the claimed invention. The dependent claims are rejected because they depend on the rejected claim 13.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The following claim limitations:
a management server has transmitted a user wallet address, in claims 1 and 13 and in the dependent claims.
a user terminal in response to a voting request received from the user terminal, the voting request having been generated through the user terminal by staking the secondary stakable tokens, in claims 1 and 13 and in the dependent claims.
Invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure that performs the function in the claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any