DETAILED ACTION
This action is in response to the initial filing filed on November 6, 2024 Claims 1-22 have been examined in this application.
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 .
Information Disclosure Statement
The Information Disclosure Statement (IDS) filed on 11/6/2024, has been acknowledged.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1: Claims 1-11 are drawn to a method and claims 12-22 are drawn to a device (i.e., a manufacture). As such, claims 1-22 are drawn to one of the statutory categories of invention (Step 1: YES).
Under Step 2A Prong 1, the claims are analyzed to determine whether the claims recite any judicial exceptions including certain groupings of abstract ideas (i.e., mathematical concepts, certain methods of organizing human activity such as a fundamental economic practice, or mental processes).
Claims 1, 11, 12, and 20-22 recite a method, performed by a game providing apparatus, of managing game data, the method comprising: obtaining first event data related to a first event having occurred in a game service; obtaining a first event hash by applying the first event data to a hash function; obtaining second event data related to a second event having occurred in the game service after the first event; and obtaining a second event hash by applying a combination of the second event data and the first event hash to the hash function. If claim limitations, under their broadest reasonable interpretation, include a mental process and/or certain methods of organizing human activity, the limitations fall under the abstract ideas judicial exception and therefore recite ineligible subject matter. Accordingly, claims 1, 12, and 20-22 recite abstract ideas.
Representative Claim 1: A method, performed by a game providing apparatus, of managing game data, the method comprising: obtaining first event data related to a first event having occurred in a game service; obtaining a first event hash by applying the first event data to a hash function; obtaining second event data related to a second event having occurred in the game service after the first event; and obtaining a second event hash by applying a combination of the second event data and the first event hash to the hash function.
Representative Claim 11: A method, performed by a game providing apparatus, of managing game data, the method comprising: obtaining first event data related to a first event having occurred in a game service, and first state data related to a first state that is a result according to the occurrence of the first event; obtaining a first event hash by applying the first event data to a hash function; and obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function.
Representative Claim 12: A game providing apparatus comprising: a memory storing instructions; and at least one processor functionally connected to the memory and configured to execute the instructions to: obtain first event data related to a first event having occurred in a game service; obtain a first event hash by applying the first event data to a hash function; obtain second event data related to a second event having occurred in the game service after the first event; and obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function.
Representative Claim 20: A server comprising: a memory storing instructions; and at least one processor functionally connected to the memory and configured to execute the instructions to: obtain first event data related to a first event having occurred in a game service; obtain a first event hash by applying the first event data to a hash function; obtain second event data related to a second event having occurred in the game service after the first event; and obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function
Representative Claim 21: A user terminal for providing a game service, the user terminal comprising: a user input unit configured to receive a user input; a memory storing instructions; and at least one processor functionally connected to the user input unit and the memory, and configured to execute the instructions to: obtain first event data related to a first event having occurred in the game service; obtain a first event hash by applying the first event data to a hash function; obtain second event data related to a second event having occurred in the game service after the first event; and obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function.
Representative Claim 22: A computer-readable recording medium having recorded thereon a program for executing, on a computer, a method of managing game data, the method comprising: obtaining first event data related to a first event having occurred in a game service; obtaining a first event hash by applying the first event data to a hash function; obtaining second event data related to a second event having occurred in the game service after the first event; and obtaining a second event hash by applying a combination of the second event data and the first event hash to the hash function.
(Examiner notes: The underlined claim terms above are interpreted as additional elements beyond the abstract idea and are further analyzed under Step 2A - Prong Two)
The additional elements are instructions for applying the judicial exceptions with a generic computing device as, under their broadest reasonable interpretation, the additional elements of a user terminal, a processor, a computer-readable recording medium, and a computer are generic computer components for performing the above method, per MPEP 2106.05(f). Under their broadest reasonable interpretation, the additional elements are generic components of a computing device used to apply the abstract idea.
Under their broadest reasonable interpretation, the recited steps of obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function (i.e., one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions), then it also falls within the “Mental Processes” subject matter grouping of abstract ideas. The recited steps are a simulation that applies an abstract idea, specifically mental processes (observation (obtaining first event data, obtaining second event data), and/or evaluation (obtaining a first event hash by using a hash function, obtaining a second event hash by using a combination of the first and second event data in the hash function)). If claim limitations, under their broadest reasonable interpretation, include a mental process and/or certain methods of organizing human activity (CMOHA), the limitations fall under the abstract ideas judicial exception and therefore recite ineligible subject matter. Accordingly, claims 1, 11, 12, and 20-22 recite abstract ideas.
Dependent Claims 2-10, and 13-19 further narrow the abstract ideas of obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function (i.e., one or more concepts performed in the human mind, such as one or more observations, evaluations, judgments, opinions), then it also falls within the “Mental Processes” and is an abstract idea and then it also falls within the “Organizing Human Processes” subject matter grouping of abstract ideas and then also falls within the “Organizing Human Processes” subject matter grouping of abstract ideas.
Independent claim(s) 1, 11, 12, and 20-22 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis.
As such, the Examiner concludes that claims 1, 11, 12, and 20-22 recite an abstract idea (Step 2A – Prong One: YES).
Under Step 2A Prong 2 the claims are analyzed to determine whether the claims recite additional elements that integrate the judicial exception into a practical application.
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
The requirement to execute the claimed steps/functions using “obtaining first event data”, “obtaining a first event hash by using a hash function”, “obtaining second event data”, and “obtaining a second event hash by using a combination of the first and second event data in the hash function” etc. (Claims 1, 11, 12, and 20-22) are equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer.
Similarly, the limitations of applying “obtaining first event data”, “obtaining a first event hash by using a hash function”, “obtaining second event data”, and “obtaining a second event hash by using a combination of the first and second event data in the hash function” etc. Independent Claim(s) 1, 11, 12, and 20-22, and dependent claims 2-10, and 13-19 are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components in a vehicle. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)).
Further, the additional limitations beyond the abstract idea identified above, serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computerized environments (e.g., obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function etc.). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)).
The recited additional element(s) of obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function (Claim(s) 1, 11, 12, and 20-22), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. (See MPEP 2106.05(g)).
Dependent claims 2-10, and 13-19 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim).
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself.
As discussed above in “Step 2A – Prong 2”, the identified additional elements in independent claim(s) 1, 11, 12, and 20-22, and dependent claims 2-10, and 13-19 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself.
The recited additional element(s) of obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function (Claim(s) 1, 11, 12, and 20-22), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea) i.e. selecting users (i.e. using a user interface) is similar to “Receiving or transmitting data over a network, e.g., using the Internet to gather data”, is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) (See MPEP 2106.05(d) (II)).
This conclusion is based on a factual determination. Applicant’s own disclosure at paragraphs [0051], [0280], and [0281] acknowledges that “ In the disclosure below, a server controlling a user terminal may indicate that the server communicates with the user terminal to provide an output (any output device in the user terminal, such as screen display, sound output, vibration output, and lamp illumination) of the user terminal and provide data for the user terminal to perform a certain operation”, “For example, the apparatus and component described in embodiments may be realized by using one or more general-purpose computers or special purpose computers, such as a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a micro-computer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a micro-processor, or any other device capable of executing and responding to an instruction”, and “The software and/or data may be embodied, permanently or temporarily, by any type of machine, component, physical device, virtual equipment, computer storage medium or device, or transmitted signal wave, such as to be analyzed by the processing device or provided to the processing device” (i.e. conventional nature of using a computer and/or computer program). This additional element therefore does not ensure the claim amounts to significantly more than the abstract idea.
Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer or/and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, and/or simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception.
The dependent claims 2-10, and 13-19 are dependent from claims 1, and 12 and include all the limitations of the independent claims, but fail to include any additional elements. In other words, each of the limitations/elements recited in respective independent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). Therefore, the dependent claims recite the same abstract idea. The limitations of the dependent claims fail to amount to significantly more than the judicial exception. For example:
The limitations of claims 3, 4, 5, 6, 13, 14, and 15 recite clarifications of the type of information associated with each event, determining the combination of the second event data and first event hash is through sequential input, obtaining a first state data and first state hash and applying them to a hash function, obtaining a second state data and a second state hash and applying the combination to a hash function, and applying a combination of a first event hash and second event hash to a hash function. Such clarifications, under their broadest reasonable interpretation, are merely defining/selecting a type of data to be manipulated which, per MPEP 2106.05(g), is insignificant extra-solution activity. Therefore, the limitations fail to provide any teaching that integrates the judicial exceptions into a practical application or amount to significantly more than the judicial exception. For this reason, the analysis performed on the independent claims is also applicable on these claims.
The limitations of claim 2, 7, 8, 9, 10, 16, 17, 18, and 19 recite clarifications of obtaining hash values (first, second, third, fourth, etc.) from memory, obtaining event data (first, second, etc.) from memory, reobtaining hash values from memory, reobtaining event data from memory, comparing hash values, verifying sequentiality of hash values, and updating the memory based on the reobtained hash values. The limitations are further instructions for applying the judicial exceptions with a generic computing device/interface acting as an intermediary for performing the abstract ideas of obtaining first event data, obtaining a first event hash by using a hash function, obtaining second event data, and obtaining a second event hash by using a combination of the first and second event data in the hash function, see MPEP 2106.05(f). Therefore, the limitations fail to provide any teaching that integrates the judicial exceptions into a practical application or amount to significantly more than the judicial exception. For this reason, the analysis performed on the independent claims is also applicable on these claims.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-22 are not eligible subject matter under 35 USC 101.
Claim Rejections – 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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 1-4, 7, 12, 13, 16, and 20-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Malan (US 2019/0232172 A1).
Regarding Claim 1, Malan discloses a method, performed by a game providing apparatus, of managing game data ([0011] Aspects of the disclosure address the above-mentioned and other challenges by creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform (managing game data)), the method comprising:
obtaining first event data related to a first event having occurred in a game service ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform, [0063] The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account);
obtaining a first event hash by applying the first event data to a hash function ([0012] The transaction data (first event data) may be used as input to a hashing function to generate a hash value for the particular entry);
obtaining second event data related to a second event having occurred in the game service after the first event ([0051] Transaction B associated with entry 202B may be the second transaction of virtual game item 2013 and occur after transaction A); and
obtaining a second event hash by applying a combination of the second event data and the first event hash to the hash function ([0013] For example , the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries . The transaction data of the new entry that depends on the hash value of all preceding entries may be used as an input to the same hashing function to generate a hash value for the new entry, [0055] Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B).
Regarding Claim 2, Malan discloses wherein the obtaining of the first event data comprises:
storing, in a memory, the first event data generated according to an occurrence of the first event ([0019] In one implementation , the data store 106 may be a memory (e.g., random access memory), a cache, a drive (e.g., a hard drive), a flash drive, a database system, or another type of component or device capable of storing data, [0047] In implementations, ledger 200 may be part of collaboration platform 120 and stored on data store 106); and
obtaining the stored first event data from the memory ([0069] the ledger 200 for the particular virtual game item 201A . For example , to validate entry 202B (i.e., transaction B) of ledger 200 , a message may be created that includes the transaction data 204B (e.g., hash value 206A in hash value field 220A, timestamp 208B, transferor ID 210B, transferee ID 212B, and game item ID 214A) of entry 202B, [0070] In some implementations, processing logic executing the account restore operation retrieves the virtual game item from another user account identified as a last entry in the ledger and restores the virtual game item to the first user account, [0078] The data storage device 416 may include a non-transitory computer-readable storage medium 424 on which is stored the sets of instructions of the system architecture… The sets of instructions may further be transmitted or received over the network 418 via the network interface device 422).
Regarding Claim 3, Malan discloses wherein the first event data and the second event data each comprise information about at least one of a change, a name, a type, an identifier, an owner, and an event occurrence date of an object in the game service, the object being affected by an event occurrence ([0053] For example, transaction data 204A includes the fields of timestamp 208A, transferor identifier 210A, transferee identifier 212A, and virtual game identifier 214A. The field timestamp 208 may be indicative of the time and date of a transaction of virtual game item 201A. Timestamp 208A has a value of Dec. 21, 2017 at 3:15:02 P. M. The field transferor identifier 210 may be indicative of the party (e.g., user account) that initiated the transfer of the virtual game item 201A).
Regarding Claim 4, Malan discloses wherein the combination of the second event data and the first event hash is determined by a sequential input of the second event data and the first event hash ([0013] In a subsequent transaction of the virtual game item, a new entry in the ledger may be created that is linked with the immediately preceding entry (sequential input). For example, the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries, [0069] For example, the combination of transaction data 204B may include concatenating the transaction data 204B in a binary form. In another example , the combination of transaction data 204B may include converting the transaction data 204B into hexadecimal strings and concatenating the hexadecimal strings).
Regarding Claim 7, Malan discloses obtaining, from a memory, a first hash value corresponding to the second event hash ([0069] the computed hash value is compared to the stored hash value (e.g., hash value 206B) for the entry 202B . If the computed hash value matches the stored hash value 206B);
obtaining, from the memory, the second event data and the first event hash ([0069] The hash function may be the same hash function used to compute the original hash value (e.g., hash value 206B) of the entry 202B. In implementations, the computed hash value is compared (obtain) to the stored (memory) hash value (e.g., hash value 206B) for the entry 202B);
calculating a second hash value corresponding to the second event hash by applying the combination of the second event data and the first event hash to the hash function ([0055] The entries 202 are linked to one another in a chain-like fashion by using the hash value 206 of the preceding entry in the calculation of the of the hash value 206 of the current entry 202. For example, transaction data 204B of entry 202B includes an additional field, hash value 220A. The value of the field hash value 220A is the hash value 206A ("fe2bb01”) of the preceding entry 202A . Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B);
comparing the first hash value with the second hash value ([0069] the computed hash value is compared to the stored hash value (e.g., hash value 206B) for the entry 202B); and
verifying the sequentiality of the first event hash and the second event hash, based on a result of the comparing ([0069] If the computed hash value matches the stored hash value 206B , entry 202B is valid. In some implementations, the validation operation to validate entries 202 may be applied from the genesis entry (e.g., entry 202A) (or from the disputed transaction) and work forwards (e.g., transaction B, followed by transaction C, etc.) to ensure that all the entries (e.g., entry 202B, 202C) are valid).
Regarding Claim 12, Malan discloses a game providing apparatus comprising:
a memory storing instructions ([0075] The computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Ram bus DRAM (RDRAM), etc.) , a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 416, which communicate with each other via a bus 408); and
at least one processor functionally connected to the memory and configured to execute the instructions to ([0076] The processing device 402 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like):
obtain first event data related to a first event having occurred in a game service ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform, [0063] The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account);
obtain a first event hash by applying the first event data to a hash function ([0012] The transaction data may be used as input to a hashing function to generate a hash value for the particular entry);
obtain second event data related to a second event having occurred in the game service after the first event ([0051] Transaction B associated with entry 202B may be the second transaction of virtual game item 2013 and occur after transaction A); and
obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function ([0013] For example , the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries . The transaction data of the new entry that depends on the hash value of all preceding entries may be used as an input to the same hashing function to generate a hash value for the new entry, [0055] Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B).
Regarding Claim 13, Malan discloses wherein the first event data and the second event data each comprise information about at least one of a change, a name, a type, an identifier, an owner, and an event occurrence date of an object in the game service, the object being affected by an event occurrence ([0053] For example, transaction data 204A includes the fields of timestamp 208A, transferor identifier 210A, transferee identifier 212A, and virtual game identifier 214A. The field timestamp 208 may be indicative of the time and date of a transaction of virtual game item 201A. Timestamp 208A has a value of Dec. 21, 2017 at 3:15:02 P. M. The field transferor identifier 210 may be indicative of the party (e.g., user account) that initiated the transfer of the virtual game item 201A).
Regarding Claim 16, Malan discloses wherein the at least one processor is further configured to execute the instructions to:
obtain, from the memory, a first hash value corresponding to the second event hash ([0069] the computed hash value is compared to the stored hash value (e.g., hash value 206B) for the entry 202B . If the computed hash value matches the stored hash value 206B);
obtain, from the memory, the second event data and the first event hash ([0069] The hash function may be the same hash function used to compute the original hash value (e.g., hash value 206B) of the entry 202B. In implementations, the computed hash value is compared (obtain) to the stored (memory) hash value (e.g., hash value 206B) for the entry 202B);
calculate a second hash value corresponding to the second event hash by applying the combination of the second event data and the first event hash to the hash function ([0055] The entries 202 are linked to one another in a chain-like fashion by using the hash value 206 of the preceding entry in the calculation of the of the hash value 206 of the current entry 202. For example, transaction data 204B of entry 202B includes an additional field, hash value 220A. The value of the field hash value 220A is the hash value 206A ("fe2bb01”) of the preceding entry 202A . Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B);
compare the first hash value with the second hash value ([0069] the computed hash value is compared to the stored hash value (e.g., hash value 206B) for the entry 202B); and
verify the sequentiality of the first event hash and the second event hash, based on a result of the comparison ([0069] If the computed hash value matches the stored hash value 206B , entry 202B is valid. In some implementations, the validation operation to validate entries 202 may be applied from the genesis entry (e.g., entry 202A) (or from the disputed transaction) and work forwards (e.g., transaction B, followed by transaction C, etc.) to ensure that all the entries (e.g., entry 202B, 202C) are valid).
Regarding Claim 20, Malan discloses a server comprising ([0017] a network 105, a data store 106, a collaboration platform 120, and a server 130):
a memory storing instructions ([0075] The computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Ram bus DRAM (RDRAM), etc.), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.); and
at least one processor functionally connected to the memory and configured to execute the instructions to ([0076] More particularly, the processing device 402 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor):
obtain first event data related to a first event having occurred in a game service ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform, [0063] The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account);
obtain a first event hash by applying the first event data to a hash function ([0012] The transaction data may be used as input to a hashing function to generate a hash value for the particular entry);
obtain second event data related to a second event having occurred in the game service after the first event ([0051] Transaction B associated with entry 202B may be the second transaction of virtual game item 2013 and occur after transaction A); and
obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function ([0013] For example , the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries . The transaction data of the new entry that depends on the hash value of all preceding entries may be used as an input to the same hashing function to generate a hash value for the new entry, [0055] Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B).
Regarding Claim 21, Malan discloses a user terminal for providing a game service, the user terminal comprising ([0095] A non-transitory processing circuit-readable, machine-readable or computer-readable medium includes, by way of example, a magnetic storage device (e.g., solid state drive, hard disk, floppy disk, magnetic strip), an optical disk (e.g., digital versatile disc (DVD), Blu-Ray disc), a smart card, a flash memory device (e.g., a card, a stick, or a key drive), RAM, ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, a hard disk, a CD-ROM and any other suitable medium for storing software and/or instructions that may be accessed and read by a machine or computer (user terminal)):
a user input unit configured to receive a user input ([0024] In some implementations, a game engine 124 (either local to the client device 110 or at collaboration platform 120) receives user input and generates commands (e.g., rendering commands, graphics library commands, etc.) based on the user input);
a memory storing instructions ([0075] The computer system 400 includes a processing device 402, a main memory 404 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Ram bus DRAM (RDRAM), etc.), a static memory 406 (e.g., flash memory, static random access memory (SRAM), etc.); and
at least one processor functionally connected to the user input unit and the memory, and configured to execute the instructions to ([0076] More particularly, the processing device 402 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor):
obtain first event data related to a first event having occurred in the game service ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform, [0063] The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account);
obtain a first event hash by applying the first event data to a hash function ([0012] The transaction data may be used as input to a hashing function to generate a hash value for the particular entry);
obtain second event data related to a second event having occurred in the game service after the first event ([0051] Transaction B associated with entry 202B may be the second transaction of virtual game item 2013 and occur after transaction A); and
obtain a second event hash by applying a combination of the second event data and the first event hash to the hash function ([0013] For example , the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries . The transaction data of the new entry that depends on the hash value of all preceding entries may be used as an input to the same hashing function to generate a hash value for the new entry, [0055] Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B).
Regarding Claim 22, Malan discloses a computer-readable recording medium having recorded thereon a program for executing, on a computer, a method of managing game data, the method comprising ([0095] The software (a program) may reside on machine-readable medium 906. The machine-readable medium 906 may be a non-transitory machine-readable medium. A non-transitory processing circuit-readable, machine-readable or computer readable medium includes, by way of example, a magnetic storage device (e.g., solid state drive, hard disk, floppy disk, magnetic strip), [0096] The machine-readable medium 906 may be embodied in a computer program product. By way of example, a computer program product may include a machine-readable medium in packaging materials):
obtaining first event data related to a first event having occurred in a game service ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions of the virtual game item between user accounts in the gaming platform, [0063] The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account);
obtaining a first event hash by applying the first event data to a hash function ([0012] The transaction data may be used as input to a hashing function to generate a hash value for the particular entry);
obtaining second event data related to a second event having occurred in the game service after the first event ([0051] Transaction B associated with entry 202B may be the second transaction of virtual game item 2013 and occur after transaction A); and
obtaining a second event hash by applying a combination of the second event data and the first event hash to the hash function ([0013] For example , the transaction data of the new entry may include a hash value that depends on the hash values of all preceding entries . The transaction data of the new entry that depends on the hash value of all preceding entries may be used as an input to the same hashing function to generate a hash value for the new entry, [0055] Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (e.g., “fe2bb01”) and one or more additional values of transaction data 204B).
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 5, 6, 8-11, 14, 15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Malan (US 2019/0232172 A1) in view of Roberts et al. (US 2018/0157700 A1).
Regarding Claim 5, Malan discloses obtaining first state data related to a first state that is a result according to an occurrence of the first event ([0063] Processing logic may generate a first entry (first state data) (e.g., entry 202A) of the entries in the ledger 200 that records the first transaction (first event) of the virtual game item (e.g., virtual game item 201A). The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account and a first hash value (e.g., hash value 206A) of the first transaction data).
However, Malan is not relied upon disclosing obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function.
Roberts teaches obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function ([0020] It is sent to the hash generator 4, which generates a hash value (first event hash) for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated and stored (first state data). The previously generated hash value for the event log, as generated when the event log was initially generated and stored, is retrieved from the local copy of the blockchain 6a (step 43), in which it is stored as a blockchain transaction with the details of the event log).
Malan and Roberts are both considered to be analogous to the claimed invention, because they are in the same field of utilizing ledgers to store and track transactions. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the applicant’s invention for modifying a method, performed by a game providing apparatus, of managing game data, as disclosed by Malan, further including obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function, as taught by Roberts for the purpose of ensuring that when event logs are retrieved, the retrieved event logs are verified as being accurate and unmodified (Roberts, [0020]).
Regarding Claim 6, Malan discloses obtaining second state data related to a second state that is a result according to an occurrence of the second event ([0064] Processing logic may generate a second entry (second state data) (e.g., entry 202B) of the entries in the ledger 200 that records the second transaction (second event) (e.g., transaction B) of the virtual game item. The second entry may include second transaction data (e.g., transaction data 204B) indicative of the second transaction of the virtual game item from the second user account to the third user account, the first hash value (e.g., value of the field hash value 220B) of the first transaction data, and a second hash value (e.g., hash value 206B) of the second transaction data and the first hash value); and
wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function ([0055] The entries 202 are linked to one another in a chain-like fashion by using the hash value 206 of the preceding entry in the calculation of the of the hash value 206 of the current entry 202 (combination of first event and second event). For example, transaction data 204B of entry 202B includes an additional field, hash value 220A. The value of the field hash value 220A is the hash value 206A (“fe2bb01”) of the preceding entry 202A. Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (first event hash) (e.g., “fe2bb01”) and one or more additional values of transaction data 204B (second event hash)).
However, Malan is not relied upon disclosing obtaining a second state hash by applying a combination of the second state data and the second event hash to the hash function, wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function.
Roberts teaches obtaining a second state hash by applying a combination of the second state data and the second event hash to the hash function, wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function ([0019] The event log generator 2 sends details of the event log to the blockchain manager 5, including the name and path in the file store 3 with which it is stored and a timestamp indicating when the event log was generated, and the hash generator (hash function) 4 sends the hash value it has generated for the event log to the blockchain manager 5 (obtain a second state hash, can be done for any event or event number). The blockchain manager 5 then creates a blockchain transaction recording those details, including the hash value, and adds the trans action to the distributed blockchain system by adding it to the local copy of the blockchain 6a (step 34), [0021] however, events may be hashed as groups of events are accumulated (combination of at least two event hashes, first and second)).
Regarding Claim 8, Malan discloses according to the first hash value and the second hash value not corresponding to each other, based on the result of the comparing:
updating the memory based on the reobtained first event hash and the reobtained second event hash ([0072] updating the ledger (memory) 200 includes generating one or more additional entries in the ledger based on the one or more account restore operations… To account for the account restore operations, the ledger is updated to add additional entries that show the additional transactions of the virtual game item, rather than altering or erasing existing entries).
However, Malan is not relied upon disclosing reobtaining the first event data from the memory; reobtaining the first event hash by applying the first event data to the hash function; reobtaining the second event data from the memory; and reobtaining the second event hash by applying a combination of the reobtained second event data and the reobtained first event hash to the hash function.
Roberts teaches reobtaining the first event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated (first event data) and stored (in memory), [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered));
reobtaining the first event hash by applying the first event data to the hash function ([0020] The newly generated hash value (first event data) for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0022] This is because only identical files will give the same hash values);
reobtaining the second event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log (second event data – can be applied to any event or event number), even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered)); and
reobtaining the second event hash by applying a combination of the reobtained second event data and the reobtained first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated (combination of first event hash and second event data)).
Regarding Claim 9, Malan discloses obtaining, from the memory, the first state data and the first event hash ([0063] The first entry may include first transaction data (first state data) (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account and a first hash value (first event hash) (e.g., hash value 206A) of the first transaction data);
comparing the third hash value with the fourth hash value ([0069] the computed hash value (third hash value – same principle can be applied to any number of hash values) is compared to the stored hash value (fourth hash value – same principle can be applied to any number of hash values) (e.g., hash value 206B) for the entry 202B); and
verifying the causality of the first event hash and the first state hash, based on a result of the comparing ([0056] Tampering (a form of causality) may be determined by comparing the original hash value (first event hash) 206 with the hash values of a tampered ledger (first state hash) 200).
However, Malan is not relied upon disclosing obtaining, from a memory, a third hash value corresponding to the first state hash; and obtaining a fourth hash value corresponding to the first event hash by applying the combination of the first state data and the first event hash to the hash function.
Roberts teaches obtaining, from a memory, a third hash value corresponding to the first state hash ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered));
obtaining a fourth hash value corresponding to the first event hash by applying the combination of the first state data and the first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated).
Regarding Claim 10, Malan discloses when the third hash value and the fourth hash value do not match each other, based on the result of the comparing:
updating the memory based on the reobtained first state hash ([0072] updating the ledger (memory) 200 includes generating one or more additional entries in the ledger based on the one or more account restore operations… To account for the account restore operations, the ledger is updated to add additional entries that show the additional transactions of the virtual game item, rather than altering or erasing existing entries).
However, Malan is not relied upon disclosing reobtaining the first event data from the memory; reobtaining the first event hash by applying the first event data to the hash function; reobtaining the first state data from the memory; and reobtaining the first event hash by applying a combination of the reobtained first event data and the reobtained first event hash to the hash function.
Roberts teaches reobtaining the first event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated (first event data) and stored (in memory), [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered));
reobtaining the first event hash by applying the first event data to the hash function ([0020] The newly generated hash value (first event data) for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0022] This is because only identical files will give the same hash values);
reobtaining the first state data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log (first state data), even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered)); and
reobtaining the first event hash by applying a combination of the reobtained first event data and the reobtained first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated (combination of first event hash and first event data)).
Regarding Claim 11, Malan discloses a method, performed by a game providing apparatus, of managing game data, the method comprising:
obtaining first event data related to a first event having occurred in a game service, and first state data related to a first state that is a result according to the occurrence of the first event ([0011] creating a secure chain of custody of a virtual game item in a gaming platform by generating entries in secure ledger that records the transactions (event data) of the virtual game item between user accounts in the gaming platform, [0063] Processing logic may generate a first entry (first state data) (e.g., entry 202A) of the entries in the ledger 200 that records the first transaction (first event) of the virtual game item (e.g., virtual game item 201A). The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account and a first hash value (e.g., hash value 206A) of the first transaction data); and
obtaining a first event hash by applying the first event data to a hash function ([0012] The transaction data may be used as input to a hashing function to generate a hash value for the particular entry).
However, Malan is not relied upon disclosing obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function.
Roberts teaches obtaining a first state hash by applying a combination of the first state data and the first event hash to the hash function ([0020] It is sent to the hash generator 4, which generates a hash value (first event hash) for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated and stored (first state data). The previously generated hash value for the event log, as generated when the event log was initially generated and stored, is retrieved from the local copy of the blockchain 6a (step 43), in which it is stored as a blockchain transaction with the details of the event log).
Regarding Claim 14, Malan discloses wherein the at least one processor is further configured to execute the instructions to:
obtain first state data related to a first state that is a result according to an occurrence of the first event ([0063] Processing logic may generate a first entry (first state data) (e.g., entry 202A) of the entries in the ledger 200 that records the first transaction (first event) of the virtual game item (e.g., virtual game item 201A). The first entry may include first transaction data (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account and a first hash value (e.g., hash value 206A) of the first transaction data).
However, Malan is not relied upon disclosing obtain a first state hash by applying a combination of the first state data and the first event hash to the hash function.
Roberts teaches obtain a first state hash by applying a combination of the first state data and the first event hash to the hash function ([0020] It is sent to the hash generator 4, which generates a hash value (first event hash) for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated and stored (first state data). The previously generated hash value for the event log, as generated when the event log was initially generated and stored, is retrieved from the local copy of the blockchain 6a (step 43), in which it is stored as a blockchain transaction with the details of the event log).
Regarding Claim 15, Malan discloses wherein the at least one processor is further configured to execute the instructions to:
obtain second state data related to a second state that is a result according to an occurrence of the second event ([0064] Processing logic may generate a second entry (second state data) (e.g., entry 202B) of the entries in the ledger 200 that records the second transaction (second event) (e.g., transaction B) of the virtual game item. The second entry may include second transaction data (e.g., transaction data 204B) indicative of the second transaction of the virtual game item from the second user account to the third user account, the first hash value (e.g., value of the field hash value 220B) of the first transaction data, and a second hash value (e.g., hash value 206B) of the second transaction data and the first hash value); and
wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function ([0055] The entries 202 are linked to one another in a chain-like fashion by using the hash value 206 of the preceding entry in the calculation of the of the hash value 206 of the current entry 202 (combination of first event and second event). For example, transaction data 204B of entry 202B includes an additional field, hash value 220A. The value of the field hash value 220A is the hash value 206A (“fe2bb01”) of the preceding entry 202A. Hash value 206B of entry 202B may be calculated using the hash value of the preceding entry 202A (first event hash) (e.g., “fe2bb01”) and one or more additional values of transaction data 204B (second event hash)).
However, Malan is not relied upon disclosing obtain a second state hash by applying a combination of the second state data and the second event hash to the hash function, wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function.
Roberts teaches obtain a second state hash by applying a combination of the second state data and the second event hash to the hash function, wherein the second event hash is obtained by applying a combination of the second event data and the first event hash to the hash function ([0019] The event log generator 2 sends details of the event log to the blockchain manager 5, including the name and path in the file store 3 with which it is stored and a timestamp indicating when the event log was generated, and the hash generator (hash function) 4 sends the hash value it has generated for the event log to the blockchain manager 5 (obtain a second state hash, can be done for any event or event number). The blockchain manager 5 then creates a blockchain transaction recording those details, including the hash value, and adds the trans action to the distributed blockchain system by adding it to the local copy of the blockchain 6a (step 34), [0021] however, events may be hashed as groups of events are accumulated (combination of at least two event hashes, first and second)).
Regarding Claim 17, Malan discloses wherein, according to the first hash value and the second hash value not corresponding to each other, based on the result of the comparison, the at least one processor is further configured to execute the instructions to:
update the memory based on the reobtained first event hash and the reobtained second event hash ([0072] updating the ledger (memory) 200 includes generating one or more additional entries in the ledger based on the one or more account restore operations… To account for the account restore operations, the ledger is updated to add additional entries that show the additional transactions of the virtual game item, rather than altering or erasing existing entries).
However, Malan is not relied upon disclosing reobtain the first event data from the memory; reobtain the first event hash by applying the first event data to the hash function; reobtain the second event data from the memory; and reobtain the second event hash by applying a combination of the reobtained second event data and the reobtained first event hash to the hash function.
Roberts teaches reobtain the first event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated (first event data) and stored (in memory), [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered));
reobtain the first event hash by applying the first event data to the hash function ([0020] The newly generated hash value (first event data) for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0022] This is because only identical files will give the same hash values);
reobtain the second event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log (second event data – can be applied to any event or event number), even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered)); and
reobtain the second event hash by applying a combination of the reobtained second event data and the reobtained first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated (combination of first event hash and second event data)).
Regarding Claim 18, Malan discloses wherein the at least one processor is further configured to execute the instructions to:
obtain, from the memory, the first state data and the first event hash ([0063] The first entry may include first transaction data (first state data) (e.g., transaction data 204A) indicative of the first transaction of the virtual game item from the first user account to the second user account and a first hash value (first event hash) (e.g., hash value 206A) of the first transaction data);
compare the third hash value with the fourth hash value ([0069] the computed hash value (third hash value – same principle can be applied to any number of hash values) is compared to the stored hash value (fourth hash value – same principle can be applied to any number of hash values) (e.g., hash value 206B) for the entry 202B); and
verify the causality of the first event hash and the first state hash, based on a result of the comparison ([0056] Tampering (a form of causality) may be determined by comparing the original hash value (first event hash) 206 with the hash values of a tampered ledger (first state hash) 200).
However, Malan is not relied upon disclosing obtain, from the memory, a third hash value corresponding to the first state hash; and obtain a fourth hash value corresponding to the first event hash by applying the combination of the first state data and the first event hash to the hash function.
Roberts teaches obtain, from the memory, a third hash value corresponding to the first state hash ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered)); and
obtain a fourth hash value corresponding to the first event hash by applying the combination of the first state data and the first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated).
Regarding Claim 19, Malan discloses wherein, when the third hash value and the fourth hash value do not match each other, based on the result of the comparison, the at least one processor is further configured to execute the instructions to:
update the memory based on the reobtained first state hash ([0072] updating the ledger (memory) 200 includes generating one or more additional entries in the ledger based on the one or more account restore operations… To account for the account restore operations, the ledger is updated to add additional entries that show the additional transactions of the virtual game item, rather than altering or erasing existing entries).
However, Malan is not relied upon disclosing reobtain the first event data from the memory; reobtain the first event hash by applying the first event data to the hash function; reobtain the first state data from the memory; and reobtain the first event hash by applying a combination of the reobtained first event data and the reobtained first event hash to the hash function.
Roberts teaches reobtain the first event data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log, even though a hash value will have been generated previously when the event log was initially generated (first event data) and stored (in memory), [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered));
reobtain the first event hash by applying the first event data to the hash function ([0020] The newly generated hash value (first event data) for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0022] This is because only identical files will give the same hash values);
reobtain the first state data from the memory ([0020] The event log which is to be verified is retrieved from the file store 3 (step 41). It is sent to the hash generator 4, which generates a hash value for the retrieved event log (step 42). The hash value is newly generated from the retrieved event log (first state data – the same principle can be applied to any event or event number), even though a hash value will have been generated previously when the event log was initially generated and stored, [0022] In one example, a retrieved event log (reobtain from memory) is verified when it is identical to the event log as originally generated and stored in the blockchain (i.e., unaltered)); and
reobtain the first event hash by applying a combination of the reobtained first event data and the reobtained first event hash to the hash function ([0020] The newly generated hash value for the retrieved event log is then compared to the hash value for the event log stored in the distributed blockchain system (step 44), and if the hash values are the same than the retrieved event log is verified as being accurate and unmodified, [0021] events may be hashed as groups of events are accumulated (combination of first event hash and first event data)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhang et al. (CN 111444192 A) discloses a method and device for generating hash of global state in blockchain ledger (Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMID TARIQ HAFIZ whose telephone number is (571) 272-4629. The examiner can normally be reached 7:30 AM - 5:00 PM, Monday through Thursday.
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, Kang Hu can be reached at 571-270-1344. 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.
/HAMID TARIQ HAFIZ/
Examiner, Art Unit 3715
/ROBERT J UTAMA/Primary Examiner, Art Unit 3715
Prosecution Insights