DETAILED ACTION
The present application, filed on 2/14/2024 is being examined under the AIA first inventor to file provisions.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/29/2025 has been entered.
The following is a non-final Office Action on the Merits in response to Applicant’s submission.
a. Claims 1-2, 16-18, 20 are amended
b. Claims 5, 19 are cancelled
Overall, Claims 1-4, 6-18, 20 are pending and have been considered below.
Claim Rejections - 35 USC § 103
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 difference 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 the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) are summarized as follows:
i. Determining the scope and contents of the prior art.
ii. Ascertaining the differences between the prior art and the claims at issue.
iii. Resolving the level of ordinary skill in the pertinent art.
iv. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rosenberg (US 2023/0385967), in view of Osborn et al (US 2024/0007284), in further view of Singh et al (US 11,770,263).
Regarding Claims 1, 2, 16: Rosenberg discloses: A method for modifying automated responses of self-executing programs stored on one or more network blocks containing one or more cryptographic hashes of previous blocks, wherein the self-executing programs comprise variable metadata properties linked to designated off-chain resources for use in secure encrypted communications across disparate computer networks, the method comprising: {see at least [0054] metadata, changes}
modifying an off-chain characteristic of an off-chain user profile; {see at least [0061] … items that modify the attributes of other items (e.g., upgrading a bow and arrow to shoot fire arrows), or combinations thereof.}
receiving, from a user-specific digital storage resource application on a user device, a user request to update the one or more variable metadata properties of the self-executing program associated with the off-chain characteristic of the off-chain user profile; {see at least fig3, rc305, rc320, rc330, [0052] change Merkle root, has for the bock, payload (reads on updating)}
retrieving, in response to the user request, the off-chain user profile; {see at least [0033] One or more user profiles may also be stored in the data structures 140. Each user profile may include information about the user (e.g., user progress in an activity and/or media content title, user id, user game characters, etc.) and may be associated to media.}
determining, based on the off-chain user profile, a first on-chain rule configuration of the self-executing program; {see at least fig4, rc405, r435, rc440, [0065] pointing data to asset 405 or pointers to off-chain metadata 440; [0066]-[0072] storing attributes of data asset 405; [0061] digital asset 405 can be an instance of a video game asset, an in-game character; “In some examples, the off-chain metadata may be mutable.”}
wherein the first on-chain rule configuration comprises a first current state of the variable metadata properties of the self-executing program {see at least fig11A, [0097] particular rules, smart contract; [0094] setting rules, with first user}
causing to be generated, based on the first encoded instruction, a second on-chain rule configuration for the self-executing program. {see at least fig4, rc430, [0070] changing the on-chain mutable metadata (reads on on-chain rule)}
wherein the second on-chain rule configuration comprises a second current state of the variable metadata properties that reflects a modified off-chain characteristic of the off-chain user profile. {see at least fig11A, [0097] particular rules, smart contract; [0094] setting rules, second user}
Rosenberg does not disclose, however, Osborn discloses:
retrieving, in response to the user request, the off-chain user profile corresponding to the user-specific digital storage resource application; {see at least [0008] retrieve a user profile; [0076]-[0077] user profile, user characteristics}
Iy would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Rosenberg to include the elements of Osborn. One would have been motivated to do so, in order to customize the self-executing program based on the user profile. In the instant case, Rosenberg evidently discloses self-executing programs with variable metadata properties. Osborn is merely relied upon to illustrate the functionality of user profile in the same or similar context. Since both self-executing programs with variable metadata properties, as well as user profile are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Rosenberg, as well as Osborn would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Rosenberg / Osborn.
Rosenberg, Osborn does not disclose, however, Singh discloses:
publishing a self-executing program to the one or more network blocks containing the one or more cryptographic hashes of the previous blocks, the self-executing program comprising one or more variable metadata properties; {see at least fig1A, rc102, rc104, r106, (13)/[5:6-22] self-executing program with variables; fig2, rc210, rc214, rc216, (34)/[8:60-9:13] each block may contain a cryptographic hash of the previous block.}
executing a first encoded instruction based on the first on-chain rule configuration for the self-executing program, {see at least fig6, rc614, (117)/[25:55-26:10] generate instruction (reads on executing instruction). Singh fails to explicitly disclose “based on the first on-chain rule configuration for the self-executing program”; however, it is reasonable to assume that one of ordinary skills in the art will realize that the instruction to be executed will be in conformity with the rules – see MPEP 2123 and MPEP 2144.01}
wherein the first encoded instruction causes a first automatic response to a first type of blockchain function of a plurality of types of blockchain functions based on the first on-chain rule configuration, {see at least (78)/[17/56-63] the system may determine that the response satisfies the predetermined processing characteristic (reads on on-chain rule configuration); fig4, rc408, (95)/[20:54-64] processing the first request, in response to determining that the characteristic corresponds to a predetermined characteristic}
wherein the first automatic response comprises an update to the variable metadata properties of the first on-chain rule configuration; and {see at least (93)/[20/32-42] dynamically updating at given intervals}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Rosenberg, Osborn to include the elements of Singh. One would have been motivated to do so, in order to perform the program in conformity with the predetermined rule configurations. In the instant case, Rosenberg, Osborn evidently discloses a variable self-executing program. Singh is merely relied upon to illustrate the functionality of a self-executing program that executes instructions based on predetermined conditions in the same or similar context. Since both a variable self-executing program, as well as self-executing program that executes instructions based on predetermined conditions are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Rosenberg, Osborn, as well as Singh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Rosenberg, Osborn / Singh.
Regarding Claim 3, 17: Rosenberg, Osborn, Singh discloses the limitations of Claims 2, 16. Rosenberg further discloses: wherein receiving the user request to update the one or more variable metadata properties of the self-executing program further comprises:
receiving a request at an off-chain resource managing the off-chain user profile to modify a property of the off-chain user profile; and {see at least [0054] changes of ownership (reads on modifying a property)}
determining, by the off-chain resource, that the property is based on the first on-chain rule configuration. {see at least fig4, rc445, [0065] token initial owner (reads on first on-chain rule)}
Regarding Claim 4, 18: Rosenberg, Osborn, Singh discloses the limitations of Claims 2, 16. Rosenberg further discloses: wherein determining, based on the off-chain user profile, the first on-chain rule configuration of the self-executing program further comprises:
determining a current property of the off-chain user profile; and {see at least fig4, rc400, rc405, rc420, [0068] identify token ownership (based on BRI (MPEP 2111), reads on current property)}
selecting the first on-chain rule configuration from a plurality of on-chain rule configurations based on the current property. {see at least [0065] ownership conditions (reads on rule configuration of current property)}
Regarding Claim 6, 20: Rosenberg, Osborn, Singh discloses the limitations of Claims 2, 16. Rosenberg further discloses: further comprising:
executing a second encoded instruction based on the first on-chain rule configuration, wherein the second encoded instruction causes a second automatic response to the first type of blockchain function based on the first on-chain rule configuration, wherein the second automatic response comprises querying a non-transferable network address for the second on-chain rule configuration; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on second encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the second encoded instruction based on the second on-chain rule configuration, wherein the second encoded instruction causes a different second automatic response to the first type of blockchain function based on the second on-chain rule configuration, wherein the different second automatic response comprises querying a different non-transferable network address for a third on-chain rule configuration. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on second encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 7: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a third encoded instruction based on the first on-chain rule configuration, wherein the third encoded instruction comprises a restriction on transferability of the self-executing program, wherein the third encoded instruction causes a third automatic response to a second type of blockchain function of the plurality of types of blockchain functions based on the first on-chain rule configuration, and wherein the third automatic response comprises a termination of any blockchain functions of the second type; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on third encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the third encoded instruction based on the second on-chain rule configuration, wherein the third encoded instruction causes a different third automatic response to the second type of blockchain function based on the second on-chain rule configuration, and wherein the different third automatic response comprises an approval of any blockchain functions of the second type. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on third encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 8: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a fourth encoded instruction based on the first on-chain rule configuration, wherein executing the fourth encoded instruction based on the first on-chain rule configuration generates a list of network addresses approved to interact with the self-executing program; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on fourht encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the fourth encoded instruction based on the second on-chain rule configuration, wherein executing the fourth encoded instruction based on the second on-chain rule configuration generates a different list of network addresses approved to interact with the self-executing program. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on fourht encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 9: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a fifth encoded instruction based on the first on-chain rule configuration, wherein executing the fifth encoded instruction based on the first on-chain rule configuration indicates a first processing characteristic for the self-executing program; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on fifth encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the fifth encoded instruction based on the second on-chain rule configuration, wherein executing the fifth encoded instruction based on the second on-chain rule configuration indicates a second processing characteristic for the self-executing program. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on fifth encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 10: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a sixth encoded instruction based on the first on-chain rule configuration, wherein executing the sixth encoded instruction based on the first on-chain rule configuration indicates a first expiration date for the self-executing program; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on sixth encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the sixth encoded instruction based on the second on-chain rule configuration, wherein executing the sixth encoded instruction based on the second on-chain rule configuration indicates a second expiration date for the self-executing program. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on sixth encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 11: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a sixth encoded instruction based on the first on-chain rule configuration, wherein executing the sixth encoded instruction based on the first on-chain rule configuration indicates a first initiation date for the self-executing program; and executing the sixth encoded instruction based on the second on-chain rule configuration, wherein executing the sixth encoded instruction based on the second on-chain rule configuration indicates a second initiation date for the self-executing program. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on sixth encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 12: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: further comprising:
executing a seventh encoded instruction based on the first on-chain rule configuration, wherein executing the seventh encoded instruction based on the first on-chain rule configuration generates a list of blockchain functions approved for the self-executing program; and {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on seventh encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
executing the seventh encoded instruction based on the second on-chain rule configuration, wherein executing the seventh encoded instruction based on the second on-chain rule configuration generates a different list of blockchain functions approved for the self-executing program. {see at least [0054] one or more smart contracts (based on BRI (MPEP 2111), “contracts” in plural form, reads on seventh encoded instruction); [0055] sufficient quantity of an asset (reads on on-chain rules) to execute the contract (reads on encoded instruction); no syntax errors; terms of the contract (reads on on-chain rule configuration); [0082] system can change content (reads on updating the rules)}
Regarding Claim 13: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Rosenberg further discloses: wherein retrieving the off-chain user profile corresponding to the user-specific digital storage resource application further comprises:
determining, in response to receiving the user request to update the self-executing program with variable metadata properties, an identity of a user corresponding to the user-specific digital storage resource application on the user device; and {see at least [0033] user profile (based on BRI (MPEP 2111), reads on user identity}
selecting the off-chain user profile from a plurality of off-chain user profiles based on the identity. {see at least [0044] player’s profile (reads on user profile)}
Regarding Claim 14: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Osborn further discloses:
wherein the variable metadata properties are determined based on on-chain rule configurations selected by an off-chain resource, wherein updates to the on-chain rule configurations are provided via an oracle controlled by the off-chain resource. {see at least [0004] off-chain data from oracle}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Rosenberg, Osborn to include additional elements of Osborn. One would have been motivated to do so, in order to utilize a proven technology for updating the metadata of a self-executing program. In the instant case, Rosenberg, Osborn evidently discloses self-executing programs with variable metadata properties. Osborn is merely relied upon to illustrate the additional functionality of utilizing an oracle for providing updates in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 15: Rosenberg, Osborn, Singh discloses the limitations of Claim 2. Osborn further discloses: further comprising:
generating a public key for the self-executing program, wherein the public key corresponds to the user-specific digital storage resource application on the user device; and {see at least fig2, rc200, [0055] generating the key pairs (reads on generating a public key)}
transmitting a confirmation of a creation of the self-executing program to an off-chain resource, wherein the off-chain resource controls an oracle for providing updates to on-chain rule configurations to the self-executing program. {see at least fig1, rc128, rc130, [0030]-[0031] system uses oracle to represent data (reads on providing updates)}
It would have been obvious to one of ordinary skill in the art, at the time of filing, to modify Rosenberg, Osborn to include additional elements of Osborn. One would have been motivated to do so, in order to utilize a proven technology for updating the metadata of a self-executing program. In the instant case, Rosenberg, Osborn evidently discloses self-executing programs with variable metadata properties. Osborn is merely relied upon to illustrate the additional functionality of utilizing an oracle for providing updates in the same or similar context. Since the subject matter is merely a combination of old elements, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20240005309 A1 OSBORN; Kevin et al. SYSTEMS AND METHODS FOR GENERATING VARIABLE NON-FUNGIBLE TOKENS LINKED TO DESIGNATED OFF-CHAIN COMPUTER RESOURCES FOR USE IN SECURE ENCRYPTED, COMMUNICATIONS ACROSS DISPARATE COMPUTER NETWORK - Systems and methods related to a variable non-fungible token. A variable non-fungible token comprises a non-fungible token that is minted with an indication of a non-transferable ownership wallet (e.g., a digital wallet for which the non-fungible token is minted for), a non-transferable smart contract address that has permissions for updating metadata for the variable non-fungible token, and a metadata property threshold based on a specific user corresponding to the digital wallet.
US 20240202721 A1 Hu; George Shiping METHOD AND PLATFORM FOR CREATING NON-FUNGIBLE TOKENS WITH BUILT-IN TERMS - A method performed by an NFT platform includes generating NFT secondary file information relating to a digital file and the NFT, wherein the NFT secondary file information comprises a content ID of the digital file stored in a data storage, wherein the data storage is a permanent and immutable data storage. The method may also include the NFT platform generating an NFT metadata file comprising the content ID of the digital file stored in the data storage, storing the NFT metadata file and the NFT secondary file information in the data storage, generating a smart contract of the NFT comprising a link to a content ID of the NFT metadata file stored in the data storage, and deploying the smart contact to a distributed ledger system.
US 20230004627 A1 HOLLAND; Wesley James et al. SYSTEMS AND METHODS FOR MANAGEMENT OF NON-FUNGIBLE TOKENS AND CORRESPONDING DIGITAL ASSETS - Systems and techniques are described for token device transfer management. A system identifies, in a payload of at least one block of a distributed ledger, a token corresponding to media content. A parameter of the token in the distributed ledger indicates that the token is associated with a first user. The system identifies a device that is associated with the token and the media content. The device is also associated with the first user. The system identifies that the device has been relocated to an area associated with a second user. In response to identifying that the device has been relocated to the area, the system causes the parameter of the token in the distributed ledger to be modified from indicating that the token is associated with the first user to indicating that the token is associated with the second user.
US 20220393873 A1 HOLLAND; Wesley James et al. SYSTEMS AND METHODS FOR MANAGEMENT OF NON-FUNGIBLE TOKENS AND CORRESPONDING DIGITAL ASSETS - Systems and techniques are described for situational token-associated media output. A system receives sensor data captured by at least one sensor of a media device. The system identifies, based on the sensor data, a relationship between the media device and an anchor element that is associated with a token. The system identifies the token in a payload of at least one block of a distributed ledger. The token corresponds to media content according to the distributed ledger. The system generates a representation of the media content corresponding to the token. In response to identifying the relationship between the media device and the anchor element, the system outputs the representation of the media content.
US 20240129143 A1 ZHU; Gengliang DIVIDING DATA STORAGE AND SERVICE OPERATIONS AMONG PLURAL BLOCKCHAINS - A multi-blockchain processing method includes receiving a first service request from a first service node, and invoking a first cross-chain reading contract on a first chain to read first service associated information from a target chain. The method further includes invoking, by a first consensus node, a first service processing contract to perform the first service and obtain service data as a first service execution result, and writing the first service execution result to the first chain. The method further includes reading, by the first consensus node, the service data from the first chain based on a second service indicated in a cross-chain reading request, and returning the service data to a second consensus node configured to write a second service execution result generated by the second service to the second chain after performing the second service based on the service data generated by the first service.
US 20240177145 A1 Miele; Andrea et al. COMPUTER IMPLEMENTED TECHNIQUES FOR FACILITATING PROMOTIONAL CAMPAIGNS, MARKET-MAKING, AND REGULATORY COMPLIANCE ACTIVITIES RELATING TO BLOCKCHAIN-BASED DIGITAL ASSETS - Various aspects described herein for implementing computer implemented techniques for facilitating promotional campaigns, market-making, and regulatory compliance activities relating to blockchain-based digital assets. At least one aspect of the present disclosure is directed to techniques for managing and facilitating transactions in digital assets and physical collectibles using blockchain technology, including minting, revealing, and offering automated buyback functionalities for Non-Fungible Tokens (NFTs) and Physical Collectibles (RWAs).
US 20220358450 A1 Stephens; Mischa et al. Tracking Unique In-Game Digital Assets Using Tokens on a Distributed Ledger - A system and method for tracking digital assets associated with video games. The digital assets may be in-game digital assets, such as in-game items or characters. The digital assets may be video game digital media assets representing moments of gameplay of a video game, such as video clips or images. The digital asset is created, and a distributed ledger tracking a history of the digital asset is created and stored across devices. A unique token for the digital asset can include a unique identifier and metadata identifying properties of the digital asset. Changes to properties of the digital asset, such as ownership, visual appearance, or metadata, can be identified in a request to update the history. A new block can be generated for, and appended to, the distributed ledger identifying the changes to the history of the digital asset. The new block can include hashes of previous blocks.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a).
Applicant’s arguments are persuasive. The rejection is withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
Applicant submits that the prior artof record does not disclose the emended claim limitation.
Examiner agrees. However, Singh discloses:
publishing a self-executing program to the one or more network blocks containing the one or more cryptographic hashes of the previous blocks, the self-executing program comprising one or more variable metadata properties; {see at least fig1A, rc102, rc104, r106, (13)/[5:6-22] self-executing program with variables; fig2, rc210, rc214, rc216, (34)/[8:60-9:13] each block may contain a cryptographic hash of the previous block.}
executing a first encoded instruction based on the first on-chain rule configuration for the self-executing program, {see at least fig6, rc614, (117)/[25:55-26:10] generate instruction (reads on executing instruction). Singh fails to explicitly disclose “based on the first on-chain rule configuration for the self-executing program”; however, it is reasonable to assume that one of ordinary skills in the art will realize that the instruction to be executed will be in conformity with the rules – see MPEP 2123 and MPEP 2144.01}
wherein the first encoded instruction causes a first automatic response to a first type of blockchain function of a plurality of types of blockchain functions based on the first on-chain rule configuration, {see at least (78)/[17/56-63] the system may determine that the response satisfies the predetermined processing characteristic (reads on on-chain rule configuration); fig4, rc408, (95)/[20:54-64] processing the first request, in response to determining that the characteristic corresponds to a predetermined characteristic}
wherein the first automatic response comprises an update to the variable metadata properties of the first on-chain rule configuration; and {see at least (93)/[20/32-42] dynamically updating at given intervals}
Thus, the rejection is proper and has been maintained.
The other arguments presented by Applicant continually point back to the above arguments as being the basis for the arguments against the other 103 rejections, as the other arguments are presented only because those claims depend from the independent claims, and the main argument above is presented against the independent claims. Therefore, it is believed that all arguments put forth have been addressed by the points above.
Examiner has reviewed and considered all of Applicant’s remarks. The changes of the grounds for rejection, if any, have been necessitated by Applicant’s extensive amendments to the claims. Therefore, the rejection is maintained, necessitated by the fact that the rejection of the claims under 35 USC § 103 has not been overcome.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Hayes can be reached at 571.272.6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3698
Prosecution Insights