DETAILED ACTION
Statement of claims
The present amended application include :
Claim 17 is canceled. Claims 1, 8 and 15 were amended. Claim 21 is added.
Claims 1-16 and 18-21 remain pending in the application. Claims 1-16 and 18-21 are being considered on the merits.
Response to Arguments
Rejections of Claims under 35 U.S.C. $ 103
Applicant argues that:
As to point 1: “Applicant respectfully submits that no combination of Lai and Liao teaches or suggests analyzing the context of the UE by the distributed application to authorize the UE to access the plurality of API smart contract components based on rights associated with the UE in the ledger data store, or wherein the context-specific template smart contract further comprises API build instructions for retrieving and assembling the plurality of API smart contract components into the API on the UE, as recited in Applicant's amended independent claim 1. ".
In response, Examiner respectfully disagree and submit that: Applicant’s arguments with respect to the newly added limitations have been considered but are moot because the arguments do not apply to the newly cited reference MATEVŽ PUSTIŠEK, “Secure Modular Smart Contract Platform for Multi-Tenant 5G Applications” being used in the current rejection and is added only as directly corresponding evidence to support the prior common knowledge finding as stated above.
As to point 2 : A. Liao Is Not Analogous Art , Prior art is analogous only if it is (1) from the same field of endeavor as the claimed invention, or (2) reasonably pertinent to the particular problem with which the inventor was concerned. See MPEP 2141.01(A)(I).
In response the examiner respectfully disagrees and submits (1) the reference is from the same field of endeavor as the claimed invention (even if it addresses a different problem); or (2) the reference is reasonably pertinent to the problem faced by the inventor (even if it is not in the same field of endeavor as the claimed invention). See Bigio, 381 F.3d at 1325, 72 USPQ2d at 1212.
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 .
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-16 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Lai et al. (US 2020/0344233, Lai hereinafter) in view of Chun-Feng Liao et al. “A Blockchain-driven Elastic Firmware Deployment Platform for TR-069 Compatible Appliances”, 2022, Liao hereinafter) and MATEVŽ PUSTIŠEK, “Secure Modular Smart Contract Platform for Multi-Tenant 5G Applications”, 2020, MATEVŽ hereinafter).
As to claim 1, Lai teaches a method of provisioning an application programming interface (API) to a user equipment (UE) (e.g., see FIG. 1A, para 47, “API requests, “ the user client devices 106A-C” and “ to provide blockchain services”, “offered to customers and subscribers” in para 52, for “Blockchain for Customer APIs”, “analyze, manage, and monitor APIs and integrations in para 149, 167, see FIG. 6E and F). Thus, the “user client devices” include the user equipment (UE) for the Customer APIs, therefore provisioning an application programming interface (API) to a user equipment (UE) would have been inherent), comprising:
receiving a request from the UE for the API by a distributed application executing on a computer system (e.g., FIG. 1, “110”) , wherein the request identifies a context of the UE and an application service provided by an application server separate from the distributed application (e.g., para 47, “receiving input and other requests 115”; “API requests” and “a distributed system which execute smart contracts” , “distributed ledger on behalf of customers” , “each of the customers operate as a participating node on the distributed ledger”, “ The API gateway is a platform that provides API integration on behalf of the and between customers of the host organization” in para 172, 194);
analyzing (e.g., para 360, “data analytics”, “ to changes to the defined metadata persisted to the blockchain”) the context of the UE by the distributed application to identify a template smart contract stored in ledger data store (e.g., see FIG. 6E, para 167, “ build APIs”, “ a library for API providers to share APIs, templates” for “a distributed system which execute smart contracts”, “ wherein the smart contract is stored on a distributed ledger “ in para 172 and 213 ; and “analyze, manage, and monitor APIs and integrations”, “each of the customers operate as a participating node on the distributed ledger”, in para 167, 197, see FIG. 6E and F and FIG. 7).
Thus, the “templates” coupled with the “the smart contracts are themselves stored” include the template smart contract ) , wherein the ledger data store comprises a plurality of blocks, wherein each block of the ledger data store except the first block comprises a hash value of a preceding block, a data content of the block, a nonce value of the block, and a hash value of the block determined over the hash of the preceding block, the data content of the block, and the nonce value of the block (e.g., see FIG. 1C, “HASH”, “NONCE”, PAYLOAD HAS”, TIMESRAMP” , para 67 and 68, “ hash for those respective blocks”, “blocks, chaining them together “ and wherein the template smart contract defines a manifestthe deployment of smart contracts onto an AccessChain” for “ Customer APIs 641”, and “metadata defining the structure of the API and what entities and field definitions are permissibly utilized via the API may be documented and persisted onto the blockchain” and metadata defining the structure of the API and what entities and field definitions are permissibly utilized via the API may be documented and persisted onto the blockchain” in para 180.
Thus, the “metadata defining the structure of the API” include the manifest, the “smart contracts” for “Customer APIs 641” include a plurality of API smart contract components);
sending the template smart contract by the distributed application to the UE (see FIG. 6E and 6F and “the customers as per the smart contract comprises logic for receiving at the API gateway a request from a first one of the customers “ in para 210, see FIG. 8));
receiving a request by the distributed application from the UE for the plurality of API smart contract components (e.g., para 210, wherein “obtaining at the API gateway from the smart contract on the distributed ledger” in para 180. Thus, receiving a request by the distributed application from the UE for the plurality of API smart contract components ) ; and
sending the plurality of API smart contract components by the distributed application, to the UE (e.g., para 211-213, wherein “to conduct the transaction between the customers via the API gateway, responsive to the request “, “for conducting the transaction between the customers as per the smart contract”, “the API gateway provides for managing the contract between the customers, including managing a smart contract that manages the APIs between the customers, wherein the smart contract is stored on a distributed ledger accessible to the API gateway. Thus, sending the plurality of API smart contract components by the distributed application, to the UE) .
However, Lai does not teach to authorize the UE to access the plurality of API smart contract components based on rights associated with the UE in the ledger data store, and to identify a context- specific template smart contract stored in ledger data store, a context-specific template smart contract, wherein the context-specific template smart contract defines the manifest, sending the context specific template smart contract by the distributed application to the UE; whereby the UE is enabled to build a context-specific version of the API on the UE from the plurality of API smart contract components and to access the application service provided by the application server, and further comprises API build instructions for retrieving and assembling the plurality of API smart contract components into the API on the UE.
Liao teaches a context-specific template smart contract (e.g., “Fig. 2: The structure of Deployment Project Contract” for “CPE: Customer-Premises Equipment” , “TVs, refrigerators, or air conditioners “ in FIG. 1 , page 1 and 2 . “each deployment project to a contract instance.” ) , wherein the context-specific template smart contract defines a manifest (see FIG. 2, cpes: mapping<id,CPE> - acs : mapping<id,ACS>- update DU Event : event- updateDUResultEvent: event- ownerld address:”) mapping” and “the contract instance according to the metadata.” in page 4) , sending the context specific template smart contract by the distributed application to the UE (e.g., see page 3, “deployment task (called a deployment project in the sequel) consists of several ACSs and CPEs, and we associate each deployment project to a contract instance. The activities of each tenants’ deployment tasks are verified and audited by the blockchain. These contract instances direct the behaviors of ACS servers running in the cloud. When performing the firmware deployment task, the platform dynamically assigns ACSs to be directed by the contract instances. In this way, the ACS servers can be safely shared and are elastic.) , whereby the UE is enabled to build a context-specific version of the API on the UE from the plurality of API smart contract components and to access the application service provided by the application server (e.g., see page 5 , “Fig. 4: The interactions among components when performing a firmware deployment task” and “latest firmware version “, “a new version .”, see page 2 and “the contract instances are created for individual deployment project and the contract is only accessible by the owner (the DU deployer)” and “An instance of Deployment Project Contract is then generated according to the registered information and is deployed to the blockchain”, “the contract instance according to the metadata”, “the CPEs according to directives made by the smart contracts” , “contract instances and are stored in the blockchain. Also, as the contract instances are created for individual deployment project and the contract is only accessible by the owner (the DU deployer)” , “new version of DU to the CPEs” and; Page 3, “An instance of Deployment Project Contract is then generated according to the registered information and is deployed to the blockchain “ and “contract instances”, “creates a contract instance and assign it to a tenant” in in page 4.) .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai by adopting the teachings of Liao to have analyzing the context of the UE by the distributed application to identify a context-specific template smart contract stored in ledger data store, wherein the ledger data store comprises a plurality of blocks, wherein each block of the ledger data store except the first block comprises a hash value of a preceding block, a data content of the block, a nonce value of the block, and a hash value of the block determined over the hash of the preceding block, the data content of the block, and the nonce value of the block and wherein the context-specific template smart contract defines a manifest for fetching a plurality of API smart contract components from the ledger data store; sending the context specific template smart contract by the distributed application to the UE; receiving a request by the distributed application from the UE for the plurality of API smart contract components; and sending the plurality of API smart contract components by the distributed application, to the UE, whereby the UE is enabled to build a context-specific version of the API on the UE from the plurality of API smart contract components and to access the application service provided by the application server in order to provide “automatic deployment task as a smart contract instance whose transactions are recorded in the append-only distributed ledger and verified by the peers” (see Liao, Abstract).
MATEVŽ teaches to authorize the UE to access the plurality of API smart contract components based on rights associated with the UE in the ledger data store (e.g., see page 11 and page 14 “A. STAKEHOLDERS AND THEIR RIGHTS AND RESPONSIBILITIES “, “An SC owner has the right to appoint new SC admins, and the right to initiate migration procedures from a previous to a new version of an SC” “devices. For participation in DL communication in the platform, each of them is identified by their DL account/address.”, “The permissions in the platform are managed on per smart contract basis “ , “Service-specific smart contract methods are accessed by registered users” ) , and to identify a context- specific template smart contract stored in ledger data store, (e.g., see pages 9 and 10, “D. APPROACHES TO SMART CONTRACT SECURITY ASSURANCE”, the access rights only to those attached by these Smart Contract Tunnels (SCTs).” for “security templates that connect legal agreements to the executable code, and can then generate standardized SCcode.” , “to upgrade an already implemented SC” ) and API build instructions for retrieving and assembling the plurality of API smart contract components into the API on the UE (e.g., see page 10, “security templates that connect legal agreements to the executable code, and can then generates standardized SCcode.
Thus, the “generate standardized SCcode” include the API build instructions ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai and Liao by adopting the teachings of MATEVŽ to “facilitates more efficient mechanisms to upgrade an already implemented SC in a controlled manner.” (see MATEVŽ, page 9) .
As to claim 2, Lai teaches wherein the context of the UE comprises a model of the UE (e.g. para 43, “ plurality of user client devices 106A-C (e.g., such as mobile devices, smart phones, tablets, PCs, etc.)”) .
As to claim 3, Lai teaches wherein the context of the UE comprises an identity that links to a subscription communication service account associated with the UE (e.g., para 142 “ the user's account”) .
As to claim 4, Lai teaches wherein the context of the UE comprises a service plan associated with the subscription communication service account associated with the UE (e.g., see page 1, “SLAs (Service Level Agreements)” and “the DU deployers to simply apply for an account and register the managed devices
on the shared platform” in page 2. Thus, the “SLAs (Service Level Agreements” must include a service plan associated with the subscription communication service account associated with the UE ) .
As to claim 5, Lai does not teach wherein the context of the UE comprises a firmware version or a software version installed in the UE. However, Liao teaches wherein the context of the UE comprises a firmware version or a software version installed in the UE (e.g., page 2, “upload the new version of Dus”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai by adopting the teachings of Liao to provide “automatic deployment task as a smart contract instance whose transactions are recorded in the append-only distributed ledger and verified by the peers” (see Liao, Abstract).
As to claim 6, Lai teaches wherein the UE is one of a smart phone, a headset computer, a wearable computer, a laptop computer, a tablet computer (e.g., para 43, smart phones, tablets”), a notebook computer, a desktop computer, or an Internet of things (IoT) device.
As to claim 7, Lai teaches wherein the API is associated with an application executing on a computer, the API provides access to services provided by the application executing on the computer, and the application is one of a personal banking application, a personal healthcare application (e.g. para 99, “the blockchain services interface 190, specifically, the healthcare blockchain 245 “) , a retirement account application, an investment account application, a premium content streaming application, or an educational institution account application.
AS to claim 8, see rejection of claim 1 above . Lai teaches further managing an application programming interface (API) installed on user equipment (UE) (e.g., see page 184, “new smart contract upgrades” ), sending a request from the UE for an API to a distributed application executing on a computer system (e.g., see FIG. 1A); receiving a template smart contract by the UE from the distributed application ( e.g., para 167, “a library for API providers to share APIs, templates”) ; retrieving a first plurality of API smart contract components identified by the manifest by the UE from the ledger data store (e.g., see FIG 6E, 6D and 6F, one of “Blockchain for Customer APIs “, “Walmart API” , “CocaCola API” in para 149 and 150, rejection of claim1 above) , retrieving a second plurality of API smart contract components identified by the manifest by the UE from the ledger data store, executing at least some of the second plurality of API smart contract components by the UE, whereby the UE accesses the application service associated with the API (e.g., see FIG 6D and 6F, (e.g., see in para 149 and 150, FIG 6E, 6D and 6F, wherein another one of “Blockchain for Customer APIs “, “Walmart API” , “CocaCola API” for “blockchain smart contract execution” in abstract, include the second plurality of API smart contract components, rejection of claim1 above). However, Lai does not teach wherein the first plurality of API smart contract components are a first version of the API smart contract components; executing at least some of the first plurality of API smart contract components by the UE, whereby a first version of the API is built by the UE; executing the first version of the API by the UE,; after executing the first version of the API by the UE, whereby a second version of the API is built by the UE; wherein the second plurality of API smart contract components are a second version of the API smart contract components identified by the manifest , and executing the second version of the API by the UE, whereby the UE accesses the application service associated with an updated version of the API.
Liao teaches wherein the first plurality of API smart contract components are a first version of the API smart contract components; executing at least some of the first plurality of API smart contract components by the UE, whereby a first version of the API is built by the UE; executing the first version of the API by the UE, whereby the UE accesses the application service associated with the API; after executing the first version of the API by the UE, whereby a second version of the API is built by the UE; and executing the second version of the API by the UE, whereby the UE accesses the application service associated with an updated version of the API (e.g., see page 2, “latest firmware version” , “latest version, a new version will be requested and updated in the distributed network”, “upload the new version of Dus” and “smart contracts are used to ensure the integrity of firmware” , “Once deployed to the blockchain network, the transactions (the modification of states and the creation of contract instances) of contract instance “ on page 3, “Fig. 4: The interactions among components when performing a firmware deployment task” in page 5Thus , wherein the first plurality of API smart contract components are a first version of the API smart contract components; executing at least some of the first plurality of API smart contract components by the UE, whereby a first version of the API is built by the UE; executing the first version of the API by the UE, whereby the UE accesses the application service associated with the API; after executing the first version of the API by the UE, whereby a second version of the API is built by the UE; and executing the second version of the API by the UE, whereby the UE accesses the application service associated with an updated version of the API).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai by adopting the teachings of Liao to provide “automatic deployment task as a smart contract instance whose transactions are recorded in the append-only distributed ledger and verified by the peers” (see Liao, Abstract).
MATEVŽ teaches API build instructions for building the API by retrieving the plurality of API smart contract components identified by the manifest from the ledger data store, executing the API build instructions (see rejection of claim 1 above).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai and Liao by adopting the teachings of MATEVŽ to allow “facilitates more efficient mechanisms to upgrade an already implemented SC in a controlled manner.” (see MATEVŽ, page 9) .
As to claim 9, Lai does not teach wherein the first plurality of API smart contract components is associated with a first version of software installed on the UE and where the second plurality of API smart contract components is associated with a second version of software installed on the UE. However, Liao teaches wherein the first plurality of API smart contract components is associated with a first version of software installed on the UE and where the second plurality of API smart contract components is associated with a second version of software installed on the UE ( ., see page 2, “latest firmware version” , “latest version, a new versionwill be requested and updated in the distributed network”, “upload the new version of Dus” and “smart contracts are used to ensure the integrity of firmware” , “Once deployed to the blockchain network, the transactions (the modification of states and the creation of contract instances) of contract instance “ on page 3) .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai by adopting the teachings of Liao to provide “automatic deployment task as a smart contract instance whose transactions are recorded in the append-only distributed ledger and verified by the peers” (see Liao, Abstract).
As to claim 10, Lai teaches further wherein the API is associated with an application executing on a computer (e.g., see rejection of claim 8 above) . However, Lai does not teach and wherein the second plurality of API smart contract components is associated with an updated version of the application executing on the computer. Liao teaches wherein the second plurality of API smart contract components is associated with an updated version of the application executing on the computer ( see rejection of claim 9 above).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai by adopting the teachings of Liao to provide “automatic deployment task as a smart contract instance whose transactions are recorded in the append-only distributed ledger and verified by the peers” (see Liao, Abstract).
As to claim 11, see rejection of claim 7 above.
As to claim 12, see rejection of claim 10 above . Lai teaches further wherein executing the first version of the API comprises sending a request from the UE to the application executing on the computer for a service (See FIG. 3).
As to claim 13, see rejection of claim 6 above .
As to claim 14, Lai teaches wherein the UE is an Internet of things (IoT) device (e.g., para 112, “user systems 412 can be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices” ) .
As to claim 15, see rejection of claims 1 and 8 above . Lai teaches further installing an application programming interface (API) in a user equipment (UE) (see FIG. 1, , para 52, wherein “ blockchain services interface 190 “, “to provide blockchain services to other participating nodes 133 for any number of blockchain protocols supported by, and offered to customers and subscribers by the host organization 110” , “ for any changes to the defined metadata for the new application at the blockchain” in para 359 . Thus, installing an application programming interface (API) in a user equipment (UE) would have been inherent).
As to claim 16, 18-20, see rejection of claims 2-3, 5 and 14 above.
As to claim 21, Lai and Liao do not teach wherein, in response to the request for the plurality of API smart contract components, the distributed application searches the last block of the ledger data store for each requested API smart contract component and, if a requested API smart contract component is not found in the last block, searches each preceding block in order until the API smart contract component is found. However, MATEVŽ teaches in response to the request for the plurality of API smart contract components, the distributed application searches the last block of the ledger data store for each requested API smart contract component and, if a requested API smart contract component is not found in the last block, searches each preceding block in order until the API smart contract component is found (e.g., see pages 9 and 10, wherein “mechanisms to upgrade an already implemented SC in a controlled manner”, “to include mechanisms to pause, freeze or delay smart contract actions if relevant flaws are found after deployment as well as mechanisms to migrate and transfer data and funds to the updated version of the SC”, “all the SCsareatanequivalentlevel and there is no invocation between smart contracts. Factory enables the simple creation of new child contracts, which are deployed by a (parent) factory contract. An approach to upgradeable modular contracts” . Thus, n response to the request for the plurality of API smart contract components, the distributed application searches the last block of the ledger data store for each requested API smart contract component and, if a requested API smart contract component is not found in the last block, searches each preceding block in order until the API smart contract component is found would have been inherent).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the method of Lai and Liao by adopting the teachings of MATEVŽ to allow “facilitates more efficient mechanisms to upgrade an already implemented SC in a controlled manner.” (see MATEVŽ, page 9) .
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 ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights