DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This action is in response to applicant’s arguments and amendments filed 6/29/2026, which are in response to USPTO Office Action mailed 3/27/2026. Applicant’s arguments have been considered with the results that follow: THIS ACTION IS MADE FINAL.
Status of Claims
Claims 1-20 are pending in the present Application.
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.
Claim(s) 1-5, 8-12, 15-16, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu et al. (US PGPUB 20210157823 A1; Pub. Date: May 27, 2021) in view of FAN et al. (US PGPUB No. 2023/0325389; Pub. Date: Oct. 12, 2023) and Singh et al. (US Patent No. 11,874,822; Date of Patent: Jan. 16, 2024).
Regarding independent claim 1,
Liu discloses a method to compose arbitrary queries for smart contract data stored across nodes of a blockchain, the method comprising: providing a dynamic and composable query interface to one or more devices with blockchain nodes, See Abstract, (Disclosing a transaction method and node design in a blockchain system where a client initiates a transaction using SQL write commands including transaction data or queries transaction data using SQL query commands.) See FIG. 1 & Paragraph [0045], (FIG.1 illustrates the architecture of a blockchain system including an application layer comprising multiple user devices interacting with the blockchain system via an application client. Note [0038] wherein a user may initiate transactions via the client deployed on a terminal, i.e. a method to compose arbitrary queries for smart contract data stored across nodes of a blockchain, the method comprising: providing a dynamic and composable query interface to one or more devices with blockchain nodes (e.g. users may initiate transactions via the application client of FIG. 1. Transactions include executing SQL commands over a blockchain system).)
each blockchain node storing smart contract code and a blockchain database, See FIG. 1 & Paragraphs [0041] & [0049], (The blockchain network comprises a plurality of network nodes such that all data in a database is updated in real-time and stored in all network nodes that participate in recording. FIG. 1 illustrates the system comprising an extension layer implementing a smart contract to be executed by a node, i.e. each blockchain node storing smart contract code and a blockchain database.)
wherein the smart contract code comprises metadata, a query library, and library functions; See Paragraph [0051], (The smart contract is used for conversion and generation of an SQL command such that the application layer can initiate a transaction using SQL commands and store block data and transaction records in a relational database (RDB).) See Paragraphs [0065]-[0066], (The smart contract may implement a conversion function for converting the SQL command into a KV which includes determining a K value corresponding to an entry in the write command and determining a V value corresponding to the K value. A K value includes a table name, a primary key value, and a column name that are to be written. A V value includes values of a column corresponding to the primary key value to be written.) See FIG. 2 & Paragraph [0052] & [0124], (FIG. 2 illustrates a blockchain node 20 as comprising parsing unit 203 configured to parse a received transaction instruction. A chaincode engine may perform an SQL parsing method as part of the process of executing a transaction, i.e. wherein the smart contract code comprises metadata (e.g. Note [0107] wherein a smart contract may implement a chaincode including a default chaincode and a user-defined chaincode), a query library (e.g. parsing unit 203 is used by a chaincode engine to parse a query is a component of node 20. Note [0107] wherein the smart contract may be implemented as a chaincode), and library functions (e.g. the conversion function) ;)
composing a query language statement for a query using input received at the query interface; See Paragraph [0051], (The smart contract is used for conversion and generation of an SQL command such that the application layer can initiate a transaction using SQL commands and store block data and transaction records in a RDB, i.e. composing a query language statement for a query using input received at the query interface (e.g. the smart contract is used for generation of an SQL command ).)
generating the smart contract code stored on the blockchain nodes by a compiler based on macros defined in smart contract source code, See Paragraph [0051], (The smart contract is used for conversion and generation of an SQL command such that the application layer can initiate a transaction using SQL commands and store block data and transaction records in a RDB.) See Paragraph [0058], (The client may generate transaction instructions such as SQL commands based on a transaction to be performed, i.e. generating the smart contract code stored on the blockchain nodes by a compiler (e.g. the smart contract is implemented using computer code triggered by transaction behavior) based on macros defined in smart contract source code (e.g. Note [0043] wherein the smart contract is implemented as a chaincode compiled into an independent application program run in an isolated docker container. The smart contract may generate SQL commands from transaction information identifying a type of transaction and associated target tables, etc.),)
parsing the query language statement for the query into elements of query syntax using the query library stored within the smart contract code, See FIG. 4 & Paragraphs [0123]-[0125], (FIG. 4 illustrates a process of initiating a transaction comprising step S4002 wherein an endorser receives a transaction instruction sent by a client device and triggers an SQL parsing method in a chaincode engine. At step S4003, the chaincode engine parses the SQL and sends a query instruction to the database based on transaction information in the transaction instruction and content of the chaincodes to query endorsement information. At Step S4004, the chaincode engine converts the SQL into KV data to generate the KV pair, i.e. parsing the query language statement for the query into elements of query syntax using the query library stored within the smart contract code (e.g. Note [0107] wherein the smart contract may be implemented as a chaincode used to parse an input and generate SQL commands).)
translating, by the smart contract code using the metadata, the elements of the query syntax by calling the library functions of the smart contract code to execute operations on the blockchain nodes to retrieve blockchain data from the blockchain database; See FIG. 4 & Paragraphs [0123]-[0125], (FIG. 4 illustrates a process of initiating a transaction comprising step S4003 wherein the chaincode engine parses the SQL and sends a query instruction to the database based on transaction information in the transaction instruction and content of the chaincodes to query endorsement information, i.e. translating, by the smart contract code using the metadata (e.g. the chaincode including a default chaincode and a user-defined chaincode as in [0107]), the elements of the query syntax by calling the library functions of the smart contract code (e.g. the smart contract may generate SQL commands such as query commands to retrieve endorsement information) to execute operations on the blockchain nodes to retrieve blockchain data from the blockchain database (e.g. Note [0071] wherein endorsement information may be external information elating to a transaction condition or transaction data required for executing said transaction that is obtained by the smart contract);)
and providing output of the query by the smart contract code by converting the retrieved blockchain data into a query language response format. See Paragraphs [0076]-[0077], (A node may directly invoke a deployed RDB to execute a query command to obtain a query result.) See Paragraph [0100], (A node may generate a new SQL command based on an SQL command submitted by a client and instructs the RDB to execute the commands to obtain a query result, i.e. and providing output of the query by the smart contract code (e.g. Note [0051] wherein the smart contract is used for conversion and generation of SQL commands ) by converting the retrieved blockchain data into a query language response format (e.g. the node uses the RBD associated with the blockchain to return results).)
Liu does not disclose the step wherein the compiler expanding the macros to generate code for processing the query,
wherein the query library decomposes the query language statement into syntax elements and stores parsed elements in memory as an abstract syntax tree;
FAN discloses the step wherein the compiler expanding the macros to generate code for processing the query, See Paragraph [0172], (Disclosing a system for executing a federated data query using first and second electronic devices. The process of executing a join query SQL statement includes compiling an SQL statement using a syntax parser or secure joint computing compiler for transforming the SQL statement into an abstract syntax tree (AST) as illustrated in FIG. 7, i.e. the compiler expanding the macros to generate code for processing the query,)
wherein the query library decomposes the query language statement into syntax elements and stores parsed elements in memory as an abstract syntax tree; See Paragraph [0104], (The first electronic device uses recognized character units as nodes and establishes an abstract syntax tree layer by layer in a recursive manner to serve as the relation structure for representing an SQL statement in the form of a tree. Note [0111] wherein the AST is traversed by electronic devices as part of the process of executing a federated data query, i.e. wherein the query library decomposes the query language statement into syntax elements and stores parsed elements in memory as an abstract syntax tree;)
Liu and FAN are analogous art because they are in the same field of endeavor, distributed query processing. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu to include the method of generating abstract syntax trees for executing SQL queries in a distributed system as disclosed by FAN. Paragraph [0014] of FAN discloses that the system may execute joint queries by performing secure ciphertext transmission and computing by executing a decentralized distributed computing process capable of protecting the data privacy of all participants.
Liu-FAN does not disclose the step wherein the generated code during execution registers table and index information into an in-memory metadata table and a reference to a generated query handling function for the metadata table;
Singh discloses the step wherein the generated code during execution registers table and index information into an in-memory metadata table and a reference to a generated query handling function for the metadata table; See Col. 14, lines 37-47, (Disclosing a multi-stream transactional event processing system operating in a distributed log-based append-only datastore. The transaction metadata dictionary may include an in-memory map backed by a journal shard wherein a transaction coordinator may run a transaction id allocator and map the transaction id to transaction metadata stored in a transaction log. Transaction metadata may include values including: transaction status, list of streams and/or shards that the transaction is modifying, the last time when the transaction status was updated, etc., i.e. wherein the generated code during execution registers table and index information into an in-memory metadata table (e.g. the in-memory map may store transaction metadata relating to target locations to which the transaction is directed) and a reference to a generated query handling function for the metadata table (e.g. the transaction metadata includes a transaction identifier, i.e. a reference to a query handling function);)
Liu, FAN and Singh are analogous art because they are in the same field of endeavor, distributed query processing. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu-FAN to include the method of recording transaction metadata in an in-memory data structure as disclosed by Singh. Col. 4, lines 31-41 of Singh discloses that the on-demand code execution service may enable users of a provider network 100 to execute cone on cloud resources without having to select or manage underlying hardware resources used to execute the code.
Regarding dependent claim 2,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the smart contract data is stored on the blockchain database in a key value format, wherein a key value is serialized and stored for later retrieval. See Paragraph [0005], (A blockchain system may employ a key-value (KV) database used for storage wherein data is organized, indexed and stored as KV pairs. The KV database stores information relating to blockchain metadata, ledger status and historical records obtained after the smart contract executes transactions) See Paragraph [0058], (A node in the conventional blockchain system uses a KV database, i.e. wherein the smart contract data is stored on the blockchain database in a key value format, wherein a key value is serialized and stored for later retrieval.)
Regarding dependent claim 3,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the metadata comprises a metadata table or reference table, wherein the metadata table or reference table registers data table information regarding at least one of: table structure, columns, and indices. See Paragraph [0094], (The RDB of a node is configured with tables including a table for block metadata, i.e. wherein the metadata comprises a metadata table.) See Paragraph [0112], (The system implements an interface for declaration of block storage including managing storage for storing block_header, the block_data, and the block_metadata, and write the data structures to the block_header, block_data, and block_metadata tables in the RDB, i.e. wherein the metadata table or reference table registers data table information regarding at least one of: columns (e.g. the block_metadata column of a database table).)
Regarding dependent claim 4,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the query library accommodates query language in the form of one or more of Structured Query Language (SQL), Graph Query Language (GraphQL), and jq. See Paragraph [0051], (The smart contract is used for conversion and generation of an SQL command such that the application layer can initiate a transaction using SQL commands and store block data and transaction records in a relational database (RDB), i.e. wherein the query library accommodates query language in the form of one or more of Structured Query Language (SQL).)
Regarding dependent claim 5,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein translating further comprises calling predefined functions for extended functionalities to execute additional operations on the blockchain nodes to retrieve the blockchain data from the blockchain database. See FIG. 4 & Paragraphs [0121]-[0134], (FIG. 4 illustrates components associated with the method of executing a query over blockchain data including an endorser, chaincode engine, orderer, commiter, ledger, etc. Note FIG. 2 which illustrates a blockchain node 20 comprising endorsement unit 201, smart contract unit 202, parsing unit 203, ordering unit 204, etc. which are utilized in the method of FIG. 4, i.e. wherein translating further comprises calling predefined functions for extended functionalities to execute additional operations (e.g. the process of executing a query over blockchain data includes a plurality of components performing separate tasks such as S4003 of parsing an SQL command or S4004 of converting an SQL command into KV data) on the blockchain nodes to retrieve the blockchain data from the blockchain database (e.g. the RDBMS is associated with nodes of a blockchain network).)
Regarding independent claim 8,
The claim is analogous to the subject matter of independent claim 1 directed to a computer system and is rejected under similar rationale.
Regarding dependent claim 9,
As discussed above with claim 8, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the system further comprising the one or more devices with the blockchain nodes providing the blockchain database, See FIG. 1 & Paragraphs [0041] & [0049], (The blockchain network comprises a plurality of network nodes such that all data in a database is updated in real-time and stored in all network nodes that participate in recording. FIG. 1 illustrates the system comprising an extension layer implementing a smart contract to be executed by a node, i.e. the system comprising the one or more devices with the blockchain nodes providing the blockchain database.)
wherein the smart contract data is stored on the blockchain database in a key value format, wherein a key value is serialized and stored for later retrieval. See Paragraph [0005], (A blockchain system may employ a key-value (KV) database used for storage wherein data is organized, indexed and stored as KV pairs. The KV database stores information relating to blockchain metadata, ledger status and historical records obtained after the smart contract executes transactions) See Paragraph [0058], (A node in the conventional blockchain system uses a KV database, i.e. wherein a key value is serialized and stored for later retrieval.)
Regarding dependent claim 10,
As discussed above with claim 8, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the metadata comprises a metadata table or reference table, wherein the metadata table or reference table registers data table information regarding at least one of: table structure, columns, and indices. See Paragraph [0094], (The RDB of a node is configured with tables including a table for block metadata, i.e. wherein the metadata comprises a metadata table.) See Paragraph [0112], (The system implements an interface for declaration of block storage including managing storage for storing block_header, the block_data, and the block_metadata, and write the data structures to the block_header, block_data, and block_metadata tables in the RDB, i.e. wherein the metadata table or reference table registers data table information regarding at least one of: columns (e.g. the block_metadata column of a database table).)
Regarding dependent claim 11,
The claim is analogous to the subject matter of dependent claim 4 directed to a computer system and is rejected under similar rationale.
Regarding dependent claim 12,
The claim is analogous to the subject matter of dependent claim 5 directed to a computer system and is rejected under similar rationale.
Regarding dependent claim 15,
As discussed above with claim 9, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the query interface executes the query language statement by parsing query syntax and mapping the query syntax to the key value format. See Paragraphs [0156] & [0162], (The system may convert an SQL write command into a KV using a conversion module implemented using a smart contract deployed in a node. Note [0124] wherein a received transaction instruction may be parsed using an SQL parsing method in a chaincode engine, i.e. wherein the query interface executes the query language statement by parsing query syntax and mapping the query syntax to the key value format (e.g. a query received from a client system may be parsed and converted into KV data).)
Regarding dependent claim 16,
As discussed above with claim 8, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the query library has an in memory metadata table data structure to be initialized during run time for tracking the database storing the smart contract data. See Paragraph [0137], (During initialization of a ledger, a ledger object is created in the fabric system which may process received block data using a blkstorage module which decomposes data into a plurality of structures including a metadata structure corresponding to a block_metadata storage unit in the database. Note [0094] wherein block metadata may be set to a table, i.e. wherein the query library has an in memory metadata table data structure to be initialized during run time for tracking the database storing the smart contract data (e.g. node 20 as in FIG. 2 is an element of the fabric system which includes the provider module upon which the initialization of the ledger is based).)
Regarding dependent claim 18,
As discussed above with claim 8, Liu-FAN-Singh discloses all of the limitations.
Liu further discloses the step wherein the smart contract code specifies an action to call the query library function to evaluate the query, wherein the query library function parses the query, See FIG. 4 & Paragraphs [0123]-[0125], (FIG. 4 illustrates a process of initiating a transaction comprising step S4002 wherein an endorser receives a transaction instruction sent by a client device and triggers an SQL parsing method in a chaincode engine, i.e. wherein the smart contract code specifies an action to call the query library function to evaluate the query, wherein the query library function parses the query, (e.g. the chaincode engine triggers an SQL parsing method).)
wherein a compiler compiles the smart contract code, See Paragraph p0043], (A chaincode may be compiled into an independent application program run in an isolated docker container, i.e. wherein a compiler compiles the smart contract code)
and wherein the query interface calls the action to perform the query. See FIG. 4 & Paragraphs [0126]-[0128], (At step S4003, the chaincode engine parses the SQL and sends a query instruction to the database based on transaction information in the transaction instruction and content of the chaincodes to query endorsement information. At Step S4004, the chaincode engine converts the SQL into KV data to generate the KV pair. At Step S4005, an endorser checks a KV based on KV data and performs a simulated transaction to generate a query result which is provided to the chaincode engine at step S4006, i.e. wherein the query interface calls the action to perform the query.)
Regarding dependent claim 20,
The claim is analogous to the subject matter of independent claim 1 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Claim(s) 6 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of FAN and Singh, as applied to claim 1 above, and further in view of Palaniappan et al. (US Patent No.: 11,954,102; Date of Patent: Apr. 9, 2024).
Regarding dependent claim 6,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu-FAN-Singh does not disclose the step wherein composing further comprises generating, using a large language model trained to generate query language queries based on natural language input.
Palaniappan discloses the step wherein composing further comprises generating, using a large language model trained to generate query language queries based on natural language input. See Col. 4, lines 57-67, (Disclosing a system for executing structured query language queries having an associated schema against an API interface using natural language. Language model 175 is trained using training module 174 which trains a large language model to output a GraphQL query using natural language input and based on an input schema using data collected by a training data collector 172, i.e. generating, using a large language model trained to generate query language queries based on natural language input.
Liu, FAN, Singh and Pal are analogous art because they are in the same field of endeavor, search systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu-FAN-Singh to include the method of generating structured queries from natural language inputs as disclosed by Pal. Col. 3, lines 42-57 of Pal discloses that the system may allow a generative AI model to be used for generation and execution of structured query language queries, client source code generation and client SDK creation using natural language even when the generative AI language model has input, token and/or output limits incompatible with a size of a schema for a structured query language.
Regarding dependent claim 13,
The claim is analogous to the subject matter of dependent claim 6 directed to a computer system and is rejected under similar rationale.
Claim(s) 7, 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of FAN and Singh, as applied to claim 1 above, and further in view of Palaniappan et al. (US Patent No.: 11,954,102; Date of Patent: Apr. 9, 2024).
Regarding dependent claim 7,
As discussed above with claim 1, Liu-FAN-Singh discloses all of the limitations.
Liu-FAN-Singh does not disclose the step of translating output of the query into a format of a requesting application.
Lai discloses the step of translating output of the query into a format of a requesting application. See Paragraph [0351], (Disclosing a system for implementing a role-based access control and authorization validator via blockchain smart contract execution . The system may process SQL queries at a receive interface requesting data associated with an application. The system may translate the SQL query into native blockchain executable code to retrieve the requested data, which is then returned to the requesting entity, i.e. translating output of the query into a format of a requesting application (e.g. blockchain data is not stored in a human-readable format however the Apex code interface may be used to translate SQL queries into a native blockchain protocol allowing for query execution against the block chain to generate a result set).)
Liu, FAN, Singh and Lai are analogous art because they are in the same field of endeavor, distributed search systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu-FAN-Singh to include the method of transforming blockchain data for output at a client device as disclosed by Lai. Paragraph [0408] of Lai discloses that the system may simplify queries originating from any of a plurality of cloud platforms 156 without having to identify the blockchain or construct more complex blockchain transactions to retrieve data.
Regarding dependent claim 14,
The claim is analogous to the subject matter of dependent claim 7 directed to a computer system and is rejected under similar rationale.
Regarding dependent claim 19,
As discussed above with claim 14, Liu-FAN-Singh-Lai discloses all of the limitations.
Liu further discloses the step wherein the smart contract code calls the query library to parse the query and converts data from the database into the output results. See FIG. 4 & Paragraphs [0126]-[0128], (At step S4003, the chaincode engine parses the SQL and sends a query instruction to the database based on transaction information in the transaction instruction and content of the chaincodes to query endorsement information. At Step S4004, the chaincode engine converts the SQL into KV data to generate the KV pair. At Step S4005, an endorser checks a KV based on KV data and performs a simulated transaction to generate a query result which is provided to the chaincode engine at step S4006, i.e. wherein the smart contract code calls the query library to parse the query (e.g. the chaincode engine parses the SQL into KV data) and converts data from the database into the output results (e.g. KV data is used to generate results from a simulated transaction).)
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of FAN and Singh, as applied to claim 9 above, and further in view of Pederson (US Patent No. 7,263,536; Date of Patent: Aug. 28, 2007) and Sreenivasan et al. (US PGPUB No. 2023/0018975; Pub. Date: Jan. 19, 2023).
Regarding dependent claim 17,
As discussed above with claim 9, Liu-FAN-Singh-Lai discloses all of the limitations.
Liu further discloses the step wherein a compiler generates expanded code for processing the query, See Paragraph [0124], (FIG. 4 illustrates the method comprising step S4002 wherein the endorser receives a transaction instruction of a client and invokes an invoke() method in a chaincode to trigger an SQP parsing method, i.e. wherein a compiler generates expanded code for processing the query (e.g. the chaincode engine is compiled as an independent application. Endorser may invoke functions that control or trigger the functioning of the chaincode engine).)
Liu-FAN-Singh does not disclose the step wherein the expanded code during execution registers the database and index information into a metadata table,
Pederson discloses the step wherein the expanded code during execution registers the database and index information into a metadata table, See Col. 1, lines 39-42, (Disclosing a method for updating an index in a database including storing a plurality of changes to be made to a database index in a change table. Each change is associated with an identifier, i.e. wherein the expanded code during execution (e.g. Note Col. 4, lines 4-9 wherein changes may be identified as a result of a request being executed) registers the database and index information into a metadata table (e.g. change table includes changes made to an index and an identifier).)
Liu, FAN, Singh and Pederson are analogous art because they are in the same field of endeavor, search systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu-FAN-Singh to include the method of maintaining a change index associated with database changes as disclosed by Pederson. Col. 5, lines 4-13 of Pederson discloses that the system may process updates based on index subtables associated with base tables in as few operations as possible such that fewer operations are needed to update an index, which results in updating indices more quickly.
Liu-FAN-Singh-Pederson does not disclose the step wherein the expanded code during execution registers a reference to a generated query handling function for the metadata table.
Sreenivasan discloses a metadata table including a reference to a generated query handling function for the metadata table. See Paragraph [0088], (Disclosing a method for obtaining domain data sources on a monolith database operating in a subject domain. The system includes maintaining a metadata table 370 which may comprise a category value indicating a query/command operation of the monolith database, i.e. a reference to a generated query handling function for the metadata table.)
Liu, FAN, Singh, Pederson and Sreenivasan are analogous art because they are in the same field of endeavor, search systems. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Liu-FAN-Singh-Pederson to include the method of recording query commands in a metadata table as disclosed by Sreenivasan. Paragraph [0114] of Sreenivasan discloses that the use of a metadata table to represent entities of a distributed system allows the system to perform silhouette clustering on long operations and frequency to determine if data elements recorded in the metadata table should be separated into a new table/node in order to improve performance, scalability and availability of the distributed database over the monolith database.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8 and 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The limitations modify the scope of the claimed invention and required further search and/or consideration.
Regarding independent claim 1,
Claim 1 recites the following amended limitation(s):
generating the smart contract code stored on the blockchain nodes by a compiler based on macros defined in smart contract source code,
As discussed in the rejection above, Liu is still considered to disclose the above limitation as Paragraph [0043] of Liu discloses that the smart contract is implemented as an independent application program for generating SQL commands from transaction information. Therefore, Liu’s smart contract includes code for identifying transaction data and generating a corresponding SQL command.
However, Liu does not disclose other amended limitation(s) including:
the compiler expanding the macros to generate code for processing the query,
wherein the generated code during execution registers table and index information into an in-memory metadata table and a reference to a generated query handling function for the metadata table;
wherein the query library decomposes the query language statement into syntax elements and stores parsed elements in memory as an abstract syntax tree;
Which are disclosed by the combination of Liu in view of FAN et al. (US PGPUB No. 2023/0325389; Pub. Date: Oct. 12, 2023) and Singh et al. (US Patent No. 11,874,822; Date of Patent: Jan. 16, 2024) discussed in the rejection above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fernando M Mari whose telephone number is (571)272-2498. The examiner can normally be reached Monday-Friday 7am-4pm.
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, Ann J. Lo can be reached at (571) 272-9767. 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.
/FMMV/Examiner, Art Unit 2159 /ALBERT M PHILLIPS, III/Primary Examiner, Art Unit 2159
Prosecution Insights