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 .
Status of Claims
This office action on the merits in response to the application filed on 12/08/2025.
Claims 1-4,6-11 and 14-22 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 12/08/2025 with respect to the rejection of claim(s) 1-4,6-11 and 14-22 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
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.
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 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
4. Claims 1-4, 6-8, 10-12, and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Beck et al. (US 20190158275 A1) in view of Boston et al. (US 10528890 B1), in view of Johnston et al. (US 20200219150 A1), in view of Doney et al. (WO 2019067603 A1), and further in view of Gunning et al. (US 11398911 B1).
5. Regarding Claim 1, Beck discloses a data structure for capturing, indexing, and storing attestation data corresponding to an attestation, wherein an attestation is a claim about an item or a linkage between items made by at least one authorized and accountable attesting user in a data context, (Para. 0005, The first digital attestation container can include a digital cryptocurrency unit of exchange, a metadata, an associated cryptocurrency address, a keys, a structured data, and/or an unstructured data. The first access policy can include data characterizing an authorization criteria for access to the first digital attestation container. The authorization criteria can include a user context, an execution context, an application context, a data context, a passcode, a claim id, a geo-fenced location of attempted access, and/or a geo-grided location of attempted access. The attestation clearing service can include a decentralized clearing environment, and can include a plurality of clearing machines that can be configured to determine access to the first digital attestation container. The determining can include a coordinated consensus between the plurality of clearing machines. The attestation can include bearing witness, confirming, authenticating, validating, verifying, and/or documenting; and Para.0037, With respect to Digital Attestation Container (DAC), the DAC has the structure articulated above. It can be referred to by one or more of the following: a unique name, a unique generated identifier, a DAC Issuer (or DAC Generation Services), and, alternatively, in a non-anonymous distribution scenario, the DAC Sender. The generated identifier, which can be non-sequential, can be used for the purpose of cataloging, management, control and/or audit by the Current subject matter). Examiner interprets the term indexing is analogous for the term cataloging in the cited prior art.
creating and managing at least one source in a source registry smart contract, by an authorized data management user signing a first distributed ledger transaction, the at least one source specifying a control context for the management of data, the data the including the attestation data and at least one property which define the attestation data, the control context defining a governance model to be applied to the corresponding data, (Para.0016-0017, Real-world conditions can include verifications based on real-world parameters. For example, verification can be based on things such as a stock price, a temperature, and/or a party completing a specific task as can be contemplated by a legal agreement. For these things, the smart contracts, which can execute in a decentralized environment, can rely on evidence queried from a defined source, which can be a centralized or decentralized actor with authority to inform the smart contract's execution. These actors can be called “Oracles.” Oracles can be recognized by the author of the smart contract at the time the smart contract is authored. They can be the authoritative sources against which the smart contract can seek to verify the success criteria for the performance of a ledger operation to complete as anticipated by the parties for whom the smart contract can be relevant; and Para. 0074, Packaged DACs can have unique identifiers that allow them the potential to be tracked, logged, and/or audited. In one implementation, the DAC Generation Service can verify the known status of attestations presented for inclusion in the DAC and/or can ensure authoritative ownership of the DA Sender. The Sender of a DAC can establish an agreement with the current subject matter whereby the current subject matter can act on behalf of the Sender in retrieving and packaging the data associated with the DAC in a single atomic operation. For example, in the case of the Sender as a smart contract seeking attestation to the result of an Oracle, where instead of the smart contract querying the Oracle directly, the smart contract may use its Trusted Client to send a proxied request for data to the Oracle and, therefore, directly receive the Oracle's response in the form of a DAC. This DAC can be used for subsequent processing by the smart contract, and/or distribution and/or storage, as can be desired by the smart contract's constituents. In this proxy relationship, the current subject matter can have the potential to shroud or otherwise anonymize the inquiry of the smart contract. Proxies can be specialized for communication with specific types of Oracles (e.g. financial Oracles, weather Oracles, etc. . . .) and packaging of content from different classes of content. These proxies can register themselves subsequently for the purpose of developing reputation with the smart contract community, and can potentially charge for their inclusion and use with conventional smart contract authoring techniques; and Para. 0025, As smart contracts execute against their respective ledgers, it can be important to link into traditional layers of business accountability and risk management. Among these layers can be providing evidence of the certified execution state of a smart contract as it relates to the assignment of value or other outcome. In the real world, attestation can provide necessary support for activities governed by insurance to protect against risk. For example, Errors and Omissions insurance policies can be used by businesses to protect them from risk. The executing host of a node on a distributed or centralized network, which can be tasked with performing the outcome of a smart contract, can find the non-reputable recording of smart contract execution state to be a helpful artifact. Artifacts of this type can be written to other ledgers and can be submitted to other distributed ledgers (e.g.: blockchains) for storage or processing. Using the DA format can provide a mechanism whereby the contents of the transaction can be sealed from third-party observers who can otherwise have interest in trading against the success of outcomes.)
whereby the authorized data management user can at least one of define, delegate, and/or decentralize rights to manage the data in the context, the rights being the ability for data consumption users to read or write data assigned to the control context using a distributed ledger public/private key; (Para. 0022, The current subject matter can provide mechanisms for specifying, delegating, and enforcing the assignment of Digital Attestations (“DAs”) as they are generated by Oracles and other Senders and can be used by smart contracts and other potential Recipients and interested parties. For example, in a DA exchange, a Sender can present the DA to the current subject matter and receive, in return, a Digital Attestation Container (“DAC”) that may be freely distributed to a Recipient, who at time of receipt can use the DAC to enable a smart contract-based or physical world activity; and Para. 0092] Sharing a DAC with a smart contract can include writing the DAC to a shared directory or repository that can be accessed by the Recipient or publisher of the DAC, and/or the smart contract, which can be established as the location for the DAC to be accessed at the time of the smart contract's specification. The smart contract can be made to poll the specified location for the DAC until the DAC is available, at which time, the DAC can be opened by the smart contract. The current subject matter can be a provider of these repositories for DAC storage and execution. Alternatively, the DAC can be offered as a response from an Oracle to an inquiry made by a smart contract, in which case, the subsequent storage of the DAC, depending on the need to preserve the DAC for future processing or attestation, cannot be necessary.)
receiving the attestation, from an attestor who is one of the at least one authorized and accountable attesting users, the attestation being made by the attestor submitting the attestation data and signing a third distributed ledger transaction, the attestation data containing an attested value, wherein one or more of the at least one properties is operable to define the attested value, the attestation data pertaining to an item or a linkage between items, wherein the item is keyed by a unique identifier of an object corresponding to the item, the attestation data preserving an identity of the attestor, the attestation data containing a last update date and an expiration date; and allowing consumption of attestation data by a third party smart contract or an authorized consuming user signing a distributed ledger transaction, (Abstract, Data characterizing a first access policy for a first digital attestation including data characterizing an attestation affecting an execution of a smart contract can be received. The first digital attestation can be encrypted and packaged into a first digital attestation container. Data characterizing a first request for access to the first digital attestation container can be received by an attestation clearing service. The first request can include a first recipient, and the first recipient can include a first recipient identifier. Access to the first digital attestation container for the first recipient can be determined by the attestation clearing service. The determining can include comparing the first recipient identifier to first access policy. Access to the first digital attestation container can be provided to the first recipient by the attestation clearing service; and Para. 0042, With respect to Digital Attestation, a Digital Attestation (DA) can be private or public information required to be shared with an intended recipient to affect the execution of a smart contract or attest to the data used in the adjudication of a smart contract that was used in deriving its outcome. This can include, for example, a copy of data outputs and calculations provided by supporting Oracles and smart contracts, timestamps, signatures/certificates/keys associated with the data exchange, and can also include additional trusted metadata or attributes associated with the results from related Oracle or smart contract activity used in the exchange that should only be accessed by the DA recipient; and Para. 0093-0094, During its processing, the smart contract can have the ability to retrieve packaged content from the DAC, including, for example, authenticated characteristics of the packaged data, its provenance, and publisher. These authenticated characteristics are determined as a function of the rights management specification used at the time the DAC is generated. Information extracted from the container can have the ability to facilitate determinations made by the smart contract, in way that connecting to an Oracle can typically inform a smart contract's execution. Features including, for example, time-based locking of data can be used to enforce the temporal availability of DAC data that can be packaged in advance of a smart contract's request. For example, temporal availability can prevent the use of a specific attestation by a smart contract beyond a specific date. Similarly, other rights management state enforcement can be used by Information Owners and Rights Managers, and can control information available to a smart contract); and Para. 0098, In the case of a smart contract working as a Sender of a DAC, the result of Oracle requests can be collected and packaged as a DAC that can represent a receipt to the smart contract's execution. A unique identifier of the resulting DAC can be embedded into the calling blockchain and the DAC can be forwarded through the execution of the smart contract to interested parties in the smart contract's execution. In so doing, the results of the smart contract execution cannot need to be memorialized to the calling blockchain for the interested parties in a smart contract to be certain to the attestation of its outcome).
receiving, by the attestor, the fee paid by data consumers, (Para. 0034, Rights Management Specification can be the specification data used by the DAC Generation Services to build a DAC. The Specification can contain information such that the Recipient Client can know the location of the relevant DAC Clearing Services or supporting network, and can specify the roles and credentials that are eligible for requesting DAs, in addition to fees that can be applicable and required for access. Packaging metadata, including that regarding the DAC Issuer (builder) and general identification number can be overloaded in the payload used for clearing the DAC such that it can be used in determining user specified restrictions over the content that may not embedded in the terms and conditions of a requested holding. Requests for a DAC DACH access can be configurable and logged by the DAC Clearing Services to facilitate account auditing and reporting. Transactions can be anonymized with respect to Sender, Recipient, and/or both. Auditing can reflect the attempts to access the DAC under anonymous transaction conditions, and the final clearing that can permit the access to the DA. Once a DACH's DAC has been accessed, the rights management specification used to structure the DAC can be used conjunction with the DAC Clearing Services and can render the DACH ineligible for subsequent clearing.; and Para. 0039, the DAC can be released to an intended Recipient and the attestation it can offer can be issued contingent to subsequent agreement, activity, and/or other conditions including the execution of a monetary payment or state of a distributed ledger (e.g.: a blockchain).) Examiner interprets the term attestor is analogous for the term DAC Clearing Services in the cited prior art. Examiner interprets the term data consumers is analogous for the term Recipient Client in the cited prior art.
Beck does not explicitly disclose a method executed by at least one computer processor executing instructions on a stored memory for creating a trusted data management model in a decentralized computing environment, the method comprising: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure.
However, Boston teaches a method executed by at least one computer processor executing instructions on a stored memory for creating a trusted data management model in a decentralized computing environment, the method comprising: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure, (Column 10/line 65, The personal computing devices may include various connections such as a cell phone connection, WiFi connection, Bluetooth connection, satellite network connection, and/or near field communication (NFC) connection, for example. The servers and personal computing devices described above may include at least one programmed processor and at least one memory or storage device. The memory may store a set of instructions. The instructions may be either permanently or temporarily stored in the memory or memories of the processor. The set of instructions may include various instructions that perform a particular task or tasks, such as those tasks described above. Such a set of instructions for performing a particular task may be characterized as a program, software program, software application, app, or software. The modules described above may comprise software, firmware, hardware, or a combination of the foregoing. It is appreciated that in order to practice the methods of the embodiments as described above, it is not necessary that the processors and/or the memories be physically located in the same geographical place.; and Figure 2A; Column 5/line 35, As depicted in FIG. 2A, the generated metadata 11 and smart contract 12 can be added to the blockchain 30. In particular, the metadata 11 and smart contract 12 can be stored in a block on the blockchain 30. FIG. 2B depicts an example of a distributed ledger in the blockchain of FIG. 2A. According to an embodiment, the distributed ledger in blockchain 30 is stored on a plurality of nodes 31, with each node being associated with a cryptographically-verified corresponding ledger 32. With the blockchain 30, the annotated and reviewed document 10's origin, chain of possession, and modifications can be tracked, traced, and presented chronologically in the cryptographically-verified ledger 32 to each participant of the blockchain 30; and Column 6/line 14, FIG. 2C depicts an example embodiment of a blockchain ledger associated with the functional interaction in FIG. 2A. According to an embodiment, the blockchain ledger 32 can include information about (i) the particular hash function value associated with the added metadata 11 and the smart contract 12; and Column 5/line 23, the metadata 11 can include a variety of information about the reviewed document 10. For example, the metadata 11 can indicate (i) the ownership of the reviewed document 10, (ii) the location of the reviewed document 10, (iii) whether the reviewed document 10 needs to be retained or purged, and (iv) information about the particular keys required to access the reviewed document. The smart contract 12 can include computer protocols that execute when predefined conditions occur. For example, the smart contract 12 can execute specific protocols when the knowledge worker begins to curate a plurality of reviewed documents; and Column 6/line 31, FIG. 3 depicts an example embodiment of metadata created by the document analysis module 20 of data exchange system in FIG. 1. As depicted in the figure, the metadata 11 can include a variety of information about a particular document 10, e.g., (i) the current name, (ii) the original name, (iii) provenance information, (iv) ownership information, (v) location information, (vi) whether the knowledge worker curator approved the document for use as training data, (vii) whether a data scientist curator approved the document for use as training data, (viii) whether the document is associated with a retention or purge policy, and (ix) the keys to access, open, and read the document, respectively. According to an embodiment, knowledge worker curators review the improvement data to determine whether the data provides a good example of the concept (for example, is “560 Lexington Avenue” a good example of the concept “Property Address” for an appraisal). The data science curator would instead be considering whether this same example is an appropriate example given the overall model itself (e.g., does this example demonstrate a possible flaw in the typology of the system, or demonstrate the need for a new modeling technique). The keys are used to provide permissions to users (both human and machine) to access the database 40. Once a user is allowed to have access, they can be given a key that is used in an access request to the database. The database only allows users with specific permissions (through those keys) to access the appropriate information.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck to the known invention of Boston would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include a method executed by at least one computer processor executing instructions on a stored memory for creating a trusted data management model in a decentralized computing environment, the method comprising: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure result in an improved invention because applying said technique will provide a secure and reliable way to manage data in a decentralized system, thus improving the overall performance of the invention.
Beck as modified does not explicitly paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment.
However, Johnston teaches paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment, (Para. 0009, designing a credibility attestation system wherein entities can vouch for transactional counterparties by staking value on their engagements, incentivizing participants to accurately represent entity credibility and deterring fraudulent behavior to the betterment of all economies involved ; and Fig. 3B; and Para. 0047, Token protocol 114 (CreD) is an enhanced blockchain smart contract-based utility token in one instance, or a digital asset wrapper in another, that is central to the credification program 109 vouching and incentive protocol. The smart contract may register any digitalized asset or security. In some embodiments, the digitalized asset or security may be selected by the parties or the marketplace… More concretely, the token protocol 114 is the currency of staking. In the depicted embodiment, token protocol 114 is a function of the credification program 109. In other embodiments, the token protocol 114 may be a stand-alone program or function located on another server, computing device, or location provided token protocol 114 has access to the other components of the computing environment 100A.; and Para. 0010, In a first embodiment, the present invention is a method of attesting to the credibility of entities engaged in commerce and trade, utilizing a value-staked vouching mechanism wherein backing positive outcomes results in economic rewards for attesters…receiving, by one or more processors, a request from a voucher account to attest to or stake on an entity's credibility, wherein the voucher account has a documented prior economic engagement with the entity; assigning, by one or more processors, the voucher account to attest to or stake on the credibility of the entity, wherein the assignment allocates a portion of at least one tokenized asset associated with the voucher account.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Johnston would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment result in an improved invention because applying said technique will ensure that there is a secure way to reward verifiers with tokens, thus improving the overall performance of the invention.
Beck as modifued does not explicitly disclose wherein the source registry smart contract contains a table with at least one row, and wherein each of the at least one row represents one of the at least one sources.
However, Doney teaches wherein the source registry smart contract contains a table with at least one row, and wherein each of the at least one row represents one of the at least one sources, (Para. 0028, The implementations described herein include a rules engine that maps complex securities laws and transaction controls into verifiable rulesets that can be evaluated in a centralized or decentralized fashion. These rulesets can be saved as "recipes", reusable data structures of a compliance or other governance decision-making, that can be easily shared, edited graphically, and stored on non-transient media in an open standard format such as extensible Access Control Markup Language or other computer interpretable code.; and Para. 0032, FIG. 1 illustrates compliance enhanced architecture 100 that leverages ABAC components and which includes: policy enforcement point (PEP) 10, used to govern transactions of value assets between users, sometimes referred to as "participants", in an enterprise or other domain; rules engine 12 (which includes a policy decision service (PDS)) used to gather the applicable policy and data required to make a decision on access rights; recipe storage 14 (including a policy store) that define the rules required to perform enterprise actions; and attribute sources 16 that provide contextual data related to the users (i.e. the transaction participants), affected tokens (as digital objects), and environment to support a policy decision.; and Para. 0033, In the implementation of FIG. 1 , the ABAC architecture has been enhanced by: 1 ) establishing a linkage between a user's identity and a unique address (represented by wallet 20) on the network(s) (e.g., a distributed ledger) to provide scalable and deterministic decision-making while protecting the user's privacy; 2) extending the concept of governance of access (a single verb) to "token rights" which include verb/object pairs; 3) sharable recipes of rules and context attributes; 4) implementing policy enforcement via ledger controls and smart contracts; and 6) mapping policies to value tokens.) The examiner states under broad reasonable interpretation, wherein the source registry smart contract contains a table with at least one row, and wherein each of the at least one row represents one of the at least one sources is interpreted as recipes that functions as rows in a table in the cited prior art. The recipes represents rulesets in a reusable data structure, they form a registry of decision making rules. The registry in the cited prior art also receives attribute sources, stores them as structured entries with each row representing a source in a table-like structure, and is retrieved by the smart contracts.
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Doney would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate table structures features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the source registry smart contract contains a table with at least one row, and wherein each of the at least one row represents one of the at least one sources result in an improved invention because applying said technique will help monitor and keep track of each data source, thus improving the overall efficiency of the invention.
Beck as modified does not explicitly disclose creating the at least one property, the creation done by an authorized user within the control context signing a second distributed ledger transaction, each of said at least one property including one of the at least one sources, a name, a data type, and structure to thereby define associated attestation data, whereby the at least one property is operable to be linked to one or more classes of blockchain based objects, wherein the one or more classes of blockchain based objects is operable to be created from a plurality of class templates by a class registry smart contract, wherein a class template of the plurality of class templates maps at least one behavior of the one or more classes of blockchain based objects.
However, Gunning teaches creating the at least one property, the creation done by an authorized user within the control context signing a second distributed ledger transaction, each of said at least one property including one of the at least one sources, a name, a data type, and structure to thereby define associated attestation data, whereby the at least one property is operable to be linked to one or more classes of blockchain based objects, wherein the one or more classes of blockchain based objects is operable to be created from a plurality of class templates by a class registry smart contract, wherein a class template of the plurality of class templates maps at least one behavior of the one or more classes of blockchain based objects, (Claim 1. receive a request to generate a class object; generate the class object; record a first transaction onto a blockchain ledger, wherein the first transaction includes computer-executable instructions to recreate the class object, wherein a blockchain associated with the blockchain ledger is Unspent Transaction Output (UTXO)-based; receive instructions to generate an instance of the class object; retrieve the first transaction from a database associated with the blockchain ledger; process the first transaction to generate a first instance of the class object, wherein the first instance comprises an occurrence of the class object, wherein characteristics of the first instance is determined by at least the class object; and record a second transaction onto the blockchain ledger, wherein the second transaction includes computer-executable instructions to recreate the first instance of the class object, wherein the second transaction has at least one input or a reference to the at least one output of the first transaction.; and Column 1/line 59, the class object comprises an object that defines characteristics for instances that are created for the class object…the characteristics include one or more functions for the corresponding instance… the characteristics include one or more properties for the corresponding instance.; and Column 2/line 15, the information needed to reproduce the class comprises source code for the class, properties for the class, and information on other source code that the class references to on the blockchain ledger.; and Column 1/line 48, receive instructions to generate a class object; generate a class object; record the class object or instructions to recreate the class object onto a blockchain ledger; receive instructions to generate an instance of the class object; retrieve the class object from the blockchain ledger; process the class object to generate a first instance of the class object; and record the first instance of the class object or instructions to recreate the first instance of the class object onto the blockchain ledger…the instance comprises an object that includes an occurrence of the class object, wherein characteristics of the instance is determined by the class object.; and Column 2/line 12, recording the class object onto the transaction output based blockchain ledger comprises recording information needed to reproduce the class. In some embodiments, the information needed to reproduce the class comprises source code for the class, properties for the class, and information on other source code that the class references to on the blockchain ledger; and Column 2/line 67, receive instructions to add a characteristic to the class object, wherein the characteristic includes a function to generate, from an instance of the class object, an instance of another class object; generate the function; record the function or instructions to recreate the function onto a blockchain ledger; receive instructions to perform the function onto the first instance of the class object; generate an instance of the other class object; and record the instance of the other class object or instructions to recreate the instance of the other class object onto the blockchain ledger….receive instructions to perform a function on the first instance of the class object; process the function on the first instance to generate an updated state for the first instance; and record the updated state of the first instance or instructions to recreate the updated state of the first instance onto a blockchain ledger.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Gunning would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate table structures features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include creating the at least one property, the creation done by an authorized user within the control context signing a second distributed ledger transaction, each of said at least one property including one of the at least one sources, a name, a data type, and structure to thereby define associated attestation data, whereby the at least one property is operable to be linked to one or more classes of blockchain based objects, wherein the one or more classes of blockchain based objects is operable to be created from a plurality of class templates by a class registry smart contract, wherein a class template of the plurality of class templates maps at least one behavior of the one or more classes of blockchain based objects result in an improved invention because applying said technique will ensure that objects can create and or interact with other blockchain based objects using the pre-defined templates, thus improving the overall efficiency of the invention.
6. Regarding Claims 2 and 10, Beck as modified does not explicitly disclose wherein the governance model includes a wallet address of the third party smart contract or the authorized consuming user, a control type, and a unique identifier (itemID) corresponding to the data to be controlled.
However, Doney teaches wherein the governance model includes a wallet address of the third party smart contract or the authorized consuming user, a control type, and a unique identifier (itemID) corresponding to the data to be controlled, (Para. 0009, Another implementation is a system for governing tokenized financial transactions on a distributed ledger over a computer network, the system comprising at least one computer processor and at least one memory having instructions stored therein which, when executed by the at least one computer processor, cause the at least one computer processor to: obtain data indicative of a verified identity of at least one participant on a transaction; receive participant attribute values for the at least one participant, the participant attributes being mapped to a wallet address indicating, among other things, a category of investor associated with at least one of the at least one participants and a jurisdiction applicable to the at least one participant; receive a request to engage in transaction of a token from a requesting participant that is one of the at least one participants, the token having token attribute values describing an underlying asset, the request including an indication of the token, and the participant attributes of the requesting participant; identify a policy to be enforced for the transaction and at least one rule associated with the policy, the at least one rule including a participant attribute, a comparison operator, and a desired value of the participant attribute and the at least one rule including a token attribute, a comparison operator, and a desired value of the token attribute; and Para. 0043, Tokens are the objects against which rights are assessed. Within a scope, systems are free to create and maintain as many items (in the case of securities tokens these are the usually unique token symbols) as desired. "Actions" are the verbs that can be performed on the items in the system (e.g. trade, transfer, etc). "Attributes" are characteristic of the actors and their environment used in the evaluation of a ruleset; and Para. 0048, Rules can be composed from attributes which contain self-describing models for data collection and caching in support of rule evaluation. An attribute can describe its data type and format, source, the means to access the source, additional filtering and context data, and caching rules to manage the balance between performance and latency for specific attributes. Attribute sources 16 can communicate with rules engine 12 through an appropriate. For example, if a recipe contains a rule that limits the number of token holders, the Rules Engine must obtain the current number of token holders in order to evaluate the legitimacy of the requested transaction. The current number of token holders is obtained by querying the distributed ledger on which the token resides; and Para. 0035, Once participant ID has been verified, participant attributes may be determined in a known manner, such as through known "know your customer" (KYC) processes, and used in decentralized policy enforcement. By separating attribute verification processes (often slow and subjective) from policy enforcement (nearly instant and objective), compliance enforcement can be performed in real time globally on decentralized networks. In implementations, verified attributes are linked to unique addresses, e.g. cryptographic wallets, on the network. On distributed ledgers, each wallet corresponds to an address. Authority to operate the wallet can be assessed using rights derived from the wallet owner's attributes (via the PEP as described below). In implementations, user attribute sets can be directly linked on a one-to-one basis to the entity owning and responsible for actions of the address. All transactions performed via an address (wallet) are attributable to its owner and are associated with its owner's rights. Since the address owner's attributes (and derived rights) may be stored and assessed separate from the address owner's personal identifiable information (PII), the privacy of transaction participants may be protected while ensuring that the transaction is attributable and compliant.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Doney would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate governance model features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the governance model includes a wallet address of the third party smart contract or the authorized consuming user, a control type, and a unique identifier (itemID) corresponding to the data to be controlled result in an improved invention because applying said technique will provide an additional layer of security to the data management process by preventing unauthorized access, thus improving the overall security of the invention.
7. Regarding Claims 3 and 11, Beck as modified does not explicitly wherein each of the one or more of the at least one properties defines an element in the end-user controlled schema, the definition including property name, control context, and data type, whereby the one or more properties can be linked to one or more classes of blockchain based objects.
However, Doney teaches wherein each of the one or more of the at least one properties defines an element in the end-user controlled schema, the definition including property name, control context, and data type, whereby the one or more properties can be linked to one or more classes of blockchain based objects. (Para. 0048, Rules can be composed from attributes which contain self-describing models for data collection and caching in support of rule evaluation. An attribute can describe its data type and format, source, the means to access the source, additional filtering and context data, and caching rules to manage the balance between performance and latency for specific attributes. Attribute sources 16 can communicate with rules engine 12 through an appropriate. For example, if a recipe contains a rule that limits the number of token holders, the Rules Engine must obtain the current number of token holders in order to evaluate the legitimacy of the requested transaction. The current number of token holders is obtained by querying the distributed ledger on which the token resides. The attribute contains instructions used by the Rules Engine to point to the code used to query the ledger. Recipes may consist of many rules containing attributes requiring data from many different sources. New recipes may be developed requiring additional data not previously mapped. Therefore, attribute mapping is performed through a flexible architecture that allows new sources to be injected into the engine efficiently and without affecting any other system operation.
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Doney would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate controlled schema features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein each of the one or more of the at least one properties defines an element in the end-user controlled schema, the definition including property name, control context, and data type, whereby the one or more properties can be linked to one or more classes of blockchain based objects result in an improved invention because applying said technique will ensure that the user can define and control the schema according to their needs, thus improving the overall user convenience of the invention.
8. Regarding Claims 4 and 12, Beck as modified does not explicitly wherein the unit designation specifies a conversion of data between unit measures, the conversion using smart contract code generated by developers and mapped to an original unit and a desired unit.
However, Doney teaches wherein the unit designation specifies a conversion of data between unit measures, the conversion using smart contract code generated by developers and mapped to an original unit and a desired unit, (Para. 0040] As illustrated in FIG. 3, implementations use a key/lock structure that isolates issuer judgment via the mapping of wallet attributes to repeatable and verifiable rule sets associated with the underlying value in a transaction (Lock). Verified attributes of the owner of wallet A, or wallet B, and environment variables such as the size of a transaction or the number of current participants are composed into a Key which are evaluated against the rulesets defined for the token or other object (Lock) to determine if participants in a transaction have the right to conduct the transaction. These rights are evaluated in real time in a decentralized fashion using a smart contract or other ledger controls to permit or block the transaction; and Para. 0041, The implementations provide a flexible, repeatable, and scalable process to codify compliance rules associated with any financial transaction through a Subject Verb Object (SVO) structure where the actor or actors attempting an action are the subject, the action being attempted is the verb, and the item on which the action is to be performed is the object. For example, a user (subject) is attempting to transfer (verb) a specific token (object). Extending ABAC approaches in this way, i.e., by converting access decisions to rights decisions permits a more flexible framework for governing complex transactions on financial networks. FIG. 4 shows user interface 400 for creating and editing recipes. User selection controls are provided for selecting attributes, values and logic for rules in a recipe.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Doney would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate conversion features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include the unit designation specifies a conversion of data between unit measures, the conversion using smart contract code generated by developers and mapped to an original unit and a desired unit result in an improved invention because applying said technique will ensure that data is more accurate with using smart contracts for conversions to prevent error, thus improving the overall performance of the invention.
9. Regarding Claims 6 and 14, Beck discloses further comprising enabling multiple governance models to support a range of data control requirements expected through use including requirements to enable plural control scenarios, wherein a trusted smart contract writes data used by a second smart contract, creator-controlled schema and data, owner controlled schema and data for transferrable objects, (Para. 005-006, To make matters even more critical, various laws and regulations govern many organization processes. Consider, for example, the Equal Credit Opportunity Act (ECOA), a ETnited States law, which makes it unlawful for any creditor to discriminate against any applicant based on various protected characteristics. In such a scenario, it is important to build the models to such specifications that can convincingly demonstrate that the model adheres to any relevant laws and regulations. It becomes critical, for example, that one can diligently track who defined and approved the requirements for such a model, approved of utilized data, designed and approved of derived features, and designed and approved the built model. Further, there must be tracking of the testing and formal model governance function of the model review and model testing. Development of analytic models requires tracking and approvals across the entire model development, testing, governance, and deployment process and such approvals should be immutable such that each atomic design is reviewed as to compliance with the process. This would include any record of approval by the external agency for future reference; and Para. 0033, The model governance network tracks each action taken with respect to a decision model or other related assets, and leverages a shared ledger that is implemented on a blockchain along with smart contracts for defining the logic associated with various actions or transactions. This blockchain is private and permissioned, with access control enabled to ensure only authorized participants can access and impact the decision model and related assets. In addition, the blockchain can contain or reference one or more secure code segments, such that actual code and data associated with a distribution of critical data elements, for example, are maintained to the chain, where in typical model development processes may be ignored or deleted in the course of model development and deployment. Due to this nature, such a blockchain has a simpler consensus mechanism unlike a public blockchain that resorts to expensive proof of work or other consensus mechanism to establish trust. In some implementations, a model governance network as described herein can be implemented on any blockchain system that meets these properties; and Para. 0044, A more fine-grained access to various assets in the governance blockchain is defined using an access control list, or ACL. Assets of various types are discussed in the section titled “Assets”. Using an ACL, permissions of various types of participants can be defined. This includes a definition of which assets various types of participants can access and their level of access. For instance, in one or more implementations, a regulator’s access to the deployables only can be limited, without access to the ATDs, requirements and sprints. Similarly, in another implementation, the external data provider is limited to access only data schema assets. While submitting a transaction to access, view or modify an asset, the transaction must be signed using a certificate corresponding to the participant to say which identity is being used to submit the transaction.)
10. Regarding Claims 7 and 15, Beck as modified does not explicitly wherein at least one source control model is one of a roles-based access control (RBAC) model, an attribute-based access control (ABAC) model, and/or a decentralized autonomous organization (DAO) model,
However, Johnston teaches wherein at least one source control model is one of a roles-based access control (RBAC) model, an attribute-based access control (ABAC) model, and/or a decentralized autonomous organization (DAO) model, (Para. 0033-0043, After that, in some implementations, the model-driven security component enforcement points (170) are installed into the runtime platforms that host the applications (160). The model-driven security workflow (120) can then be executed to automatically generate fine-grained contextual technical security rules (130), taking into account various system and context information, including the application model (140) used to build the running applications (160) using model transformations (150). (2) Security inputs, such as for example: Security policy and privacy models, and metamodels, security tags in (functional) models, hand-coded policy rules (in a policy editor), security attribute information from Policy Information Points (PIPs) etc.; and (3) Other non-functional inputs, for example about Quality of Service (QoS)…MDS model transformations turn the inputs into the outputs. A trivial policy example would be “Interactions in the component deployment model are interpreted as explicit granted access”. Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation…The MDS output is a number of technical security rules (e.g. ABAC rules, RBAC configuration files or IP layer filter lists) and other configuration files (e.g. command lines for application start up) for all parts of the application and security infrastructure that reflect the high-level input security requirements at a low level of abstraction and that can be enforced or implemented within the actual system. The technical security rules are then automatically pushed into the policy enforcement points for enforcement, and policy incidents are monitored.; and Para. 0303, COMPONENT “CMP-OSC” (Other Technology Component Security Configuration): This component may allow the configuration of other security configurations via a model-driven refinement process based on the methods employed by the CMP-MDS component (for security rule generation). The difference is that instead of rules for CMP-PDPs, CMP-OSC can generate specific configurations for “other security components” (OSC), which often require custom configuration files, configuration commands, source code, binary code etc. This CMP-OSC component may closely interact with CMP-MDS, and in many embodiments CMP-MDS feeds directly into CMP-OSC, which further processes the outputs of CMP-MDS and distributes/configures them within the “other technology component”. In other words, in some embodiments, CMP-OSC carries out methods similar to CMP-MDS to generate and distribute configurations, while in other embodiments, CMP-OSC informs CMP-MDS to generate configurations and CMP-OSC distributes those. In yet another embodiment, CMP-MDS autonomously generates the configurations and CMP-OSC distributes them. It is obvious that the described features can be distributed between CMP-MDS and CMP-OSC in various additional ways.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Johnston would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein at least one source control model is one of a roles-based access control (RBAC) model, an attribute-based access control (ABAC) model, and/or a decentralized autonomous organization (DAO) model, result in an improved invention because applying said technique will ensure that only authorized users can access sensitive data, thus improving the overall security of the invention.
11. Regarding Claims 8 and 16, Beck as modified does not explicitly wherein the property data type of each of the at least one properties include objects with a defined pointer type, the pointer type defining pointer properties and methods of the object, enabling nested properties, that is a property whose assigned object has properties.
However, Doney teaches wherein the property data type of each of the at least one properties include objects with a defined pointer type, the pointer type defining pointer properties and methods of the object, enabling nested properties, that is a property whose assigned object has properties, (Para. 0048, Rules can be composed from attributes which contain self-describing models for data collection and caching in support of rule evaluation. An attribute can describe its data type and format, source, the means to access the source, additional filtering and context data, and caching rules to manage the balance between performance and latency for specific attributes. Attribute sources 16 can communicate with rules engine 12 through an appropriate. For example, if a recipe contains a rule that limits the number of token holders, the Rules Engine must obtain the current number of token holders in order to evaluate the legitimacy of the requested transaction. The current number of token holders is obtained by querying the distributed ledger on which the token resides. The attribute contains instructions used by the Rules Engine to point to the code used to query the ledger. Recipes may consist of many rules containing attributes requiring data from many different sources. New recipes may be developed requiring additional data not previously mapped. Therefore, attribute mapping is performed through a flexible architecture that allows new sources to be injected into the engine efficiently and without affecting any other system operation; and Para. 0031-0032, If granted, the user is provided access to the object. FIG. 1 illustrates compliance enhanced architecture 100 that leverages ABAC components and which includes: policy enforcement point (PEP) 10, used to govern transactions of value assets between users, sometimes referred to as "participants", in an enterprise or other domain; rules engine 12 (which includes a policy decision service (PDS)) used to gather the applicable policy and data required to make a decision on access rights; recipe storage 14 (including a policy store) that define the rules required to perform enterprise actions; and attribute sources 16 that provide contextual data related to the users (i.e. the transaction participants), affected tokens (as digital objects), and environment to support a policy decision.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Doney would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include attestation property data types include objects with a defined pointer type, the pointer type defining the properties and methods of the object, enabling nested properties, that is a property whose assigned object has properties result in an improved invention because applying said technique will ensure that the system can access object properties making is easier to navigate through the data structures, thus improving the overall performance of the invention.
12. Claims 9 and 17-22 are rejected under 35 U.S.C. 103 as being unpatentable over Beck et al. (US 20190158275 A1) in view of Boston et al. (US 10528890 B1), in view of Johnston et al. (US 20200219150 A1), further in view of Doney et al. (WO 2019067603 A1), in view of Gunning et al. (US 11398911 B1), and further in view of Lai et al. (US 20200344233 A1).
13. Regarding Claim 9, Beck discloses the infrastructure including a data structure for capturing, indexing, and storing attestation data corresponding to an attestation, wherein an attestation is a claim about an item or a linkage between items made by at least one authorized and accountable attesting user in a data context, (Para. 0005, The first digital attestation container can include a digital cryptocurrency unit of exchange, a metadata, an associated cryptocurrency address, a keys, a structured data, and/or an unstructured data. The first access policy can include data characterizing an authorization criteria for access to the first digital attestation container. The authorization criteria can include a user context, an execution context, an application context, a data context, a passcode, a claim id, a geo-fenced location of attempted access, and/or a geo-grided location of attempted access. The attestation clearing service can include a decentralized clearing environment, and can include a plurality of clearing machines that can be configured to determine access to the first digital attestation container. The determining can include a coordinated consensus between the plurality of clearing machines. The attestation can include bearing witness, confirming, authenticating, validating, verifying, and/or documenting; and Para.0037, With respect to Digital Attestation Container (DAC), the DAC has the structure articulated above. It can be referred to by one or more of the following: a unique name, a unique generated identifier, a DAC Issuer (or DAC Generation Services), and, alternatively, in a non-anonymous distribution scenario, the DAC Sender. The generated identifier, which can be non-sequential, can be used for the purpose of cataloging, management, control and/or audit by the Current subject matter). Examiner interprets the term indexing is analogous for the term cataloging in the cited prior art.
creating and managing at least one source in a source registry smart contract, by an authorized data management user signing a first distributed ledger transaction, the at least one source specifying a control context for the management of data, the data including the attestation data and at least one property (Para.0016-0017, Real-world conditions can include verifications based on real-world parameters. For example, verification can be based on things such as a stock price, a temperature, and/or a party completing a specific task as can be contemplated by a legal agreement. For these things, the smart contracts, which can execute in a decentralized environment, can rely on evidence queried from a defined source, which can be a centralized or decentralized actor with authority to inform the smart contract's execution. These actors can be called “Oracles.” Oracles can be recognized by the author of the smart contract at the time the smart contract is authored. They can be the authoritative sources against which the smart contract can seek to verify the success criteria for the performance of a ledger operation to complete as anticipated by the parties for whom the smart contract can be relevant; and Para. 0074, Packaged DACs can have unique identifiers that allow them the potential to be tracked, logged, and/or audited. In one implementation, the DAC Generation Service can verify the known status of attestations presented for inclusion in the DAC and/or can ensure authoritative ownership of the DA Sender. The Sender of a DAC can establish an agreement with the current subject matter whereby the current subject matter can act on behalf of the Sender in retrieving and packaging the data associated with the DAC in a single atomic operation. For example, in the case of the Sender as a smart contract seeking attestation to the result of an Oracle, where instead of the smart contract querying the Oracle directly, the smart contract may use its Trusted Client to send a proxied request for data to the Oracle and, therefore, directly receive the Oracle's response in the form of a DAC. This DAC can be used for subsequent processing by the smart contract, and/or distribution and/or storage, as can be desired by the smart contract's constituents. In this proxy relationship, the current subject matter can have the potential to shroud or otherwise anonymize the inquiry of the smart contract. Proxies can be specialized for communication with specific types of Oracles (e.g. financial Oracles, weather Oracles, etc. . . .) and packaging of content from different classes of content. These proxies can register themselves subsequently for the purpose of developing reputation with the smart contract community, and can potentially charge for their inclusion and use with conventional smart contract authoring techniques; and Para. 0025, As smart contracts execute against their respective ledgers, it can be important to link into traditional layers of business accountability and risk management. Among these layers can be providing evidence of the certified execution state of a smart contract as it relates to the assignment of value or other outcome. In the real world, attestation can provide necessary support for activities governed by insurance to protect against risk. For example, Errors and Omissions insurance policies can be used by businesses to protect them from risk. The executing host of a node on a distributed or centralized network, which can be tasked with performing the outcome of a smart contract, can find the non-reputable recording of smart contract execution state to be a helpful artifact. Artifacts of this type can be written to other ledgers and can be submitted to other distributed ledgers (e.g.: blockchains) for storage or processing. Using the DA format can provide a mechanism whereby the contents of the transaction can be sealed from third-party observers who can otherwise have interest in trading against the success of outcomes.)
whereby the authorized data management user can at least one of define, delegate, and/or decentralize rights to manage the data in the context, the rights being the ability for data consumption users to read or write data assigned to the control context using a distributed ledger public/private key; (Para. 0022, The current subject matter can provide mechanisms for specifying, delegating, and enforcing the assignment of Digital Attestations (“DAs”) as they are generated by Oracles and other Senders and can be used by smart contracts and other potential Recipients and interested parties. For example, in a DA exchange, a Sender can present the DA to the current subject matter and receive, in return, a Digital Attestation Container (“DAC”) that may be freely distributed to a Recipient, who at time of receipt can use the DAC to enable a smart contract-based or physical world activity; and Para. 0092] Sharing a DAC with a smart contract can include writing the DAC to a shared directory or repository that can be accessed by the Recipient or publisher of the DAC, and/or the smart contract, which can be established as the location for the DAC to be accessed at the time of the smart contract's specification. The smart contract can be made to poll the specified location for the DAC until the DAC is available, at which time, the DAC can be opened by the smart contract. The current subject matter can be a provider of these repositories for DAC storage and execution. Alternatively, the DAC can be offered as a response from an Oracle to an inquiry made by a smart contract, in which case, the subsequent storage of the DAC, depending on the need to preserve the DAC for future processing or attestation, cannot be necessary.)
receiving the attestation, from an attestor who is one of the at least one authorized and accountable attesting users, the attestation being made by the attestor submitting the attestation data and signing a third distributed ledger transaction, the attestation data containing an attested value, wherein one or more of the at least one properties is operable to define the attested value, the attestation data pertaining to an item or a linkage between items, wherein the item is keyed by a unique identifier of an object corresponding to the item, the attestation data preserving an identity of the attestor, the attestation data containing a last update date and an expiration date; and allowing consumption of attestation data by a third party smart contract or an authorized consuming user signing a distributed ledger transaction, (Abstract, Data characterizing a first access policy for a first digital attestation including data characterizing an attestation affecting an execution of a smart contract can be received. The first digital attestation can be encrypted and packaged into a first digital attestation container. Data characterizing a first request for access to the first digital attestation container can be received by an attestation clearing service. The first request can include a first recipient, and the first recipient can include a first recipient identifier. Access to the first digital attestation container for the first recipient can be determined by the attestation clearing service. The determining can include comparing the first recipient identifier to first access policy. Access to the first digital attestation container can be provided to the first recipient by the attestation clearing service; and Para. 0042, With respect to Digital Attestation, a Digital Attestation (DA) can be private or public information required to be shared with an intended recipient to affect the execution of a smart contract or attest to the data used in the adjudication of a smart contract that was used in deriving its outcome. This can include, for example, a copy of data outputs and calculations provided by supporting Oracles and smart contracts, timestamps, signatures/certificates/keys associated with the data exchange, and can also include additional trusted metadata or attributes associated with the results from related Oracle or smart contract activity used in the exchange that should only be accessed by the DA recipient; and Para. 0093-0094, During its processing, the smart contract can have the ability to retrieve packaged content from the DAC, including, for example, authenticated characteristics of the packaged data, its provenance, and publisher. These authenticated characteristics are determined as a function of the rights management specification used at the time the DAC is generated. Information extracted from the container can have the ability to facilitate determinations made by the smart contract, in way that connecting to an Oracle can typically inform a smart contract's execution. Features including, for example, time-based locking of data can be used to enforce the temporal availability of DAC data that can be packaged in advance of a smart contract's request. For example, temporal availability can prevent the use of a specific attestation by a smart contract beyond a specific date. Similarly, other rights management state enforcement can be used by Information Owners and Rights Managers, and can control information available to a smart contract); and Para. 0098, In the case of a smart contract working as a Sender of a DAC, the result of Oracle requests can be collected and packaged as a DAC that can represent a receipt to the smart contract's execution. A unique identifier of the resulting DAC can be embedded into the calling blockchain and the DAC can be forwarded through the execution of the smart contract to interested parties in the smart contract's execution. In so doing, the results of the smart contract execution cannot need to be memorialized to the calling blockchain for the interested parties in a smart contract to be certain to the attestation of its outcome).
receiving, by the attestor, the fee paid by data consumers, (Para. 0034, Rights Management Specification can be the specification data used by the DAC Generation Services to build a DAC. The Specification can contain information such that the Recipient Client can know the location of the relevant DAC Clearing Services or supporting network, and can specify the roles and credentials that are eligible for requesting DAs, in addition to fees that can be applicable and required for access. Packaging metadata, including that regarding the DAC Issuer (builder) and general identification number can be overloaded in the payload used for clearing the DAC such that it can be used in determining user specified restrictions over the content that may not embedded in the terms and conditions of a requested holding. Requests for a DAC DACH access can be configurable and logged by the DAC Clearing Services to facilitate account auditing and reporting. Transactions can be anonymized with respect to Sender, Recipient, and/or both. Auditing can reflect the attempts to access the DAC under anonymous transaction conditions, and the final clearing that can permit the access to the DA. Once a DACH's DAC has been accessed, the rights management specification used to structure the DAC can be used conjunction with the DAC Clearing Services and can render the DACH ineligible for subsequent clearing.; and Para. 0039, the DAC can be released to an intended Recipient and the attestation it can offer can be issued contingent to subsequent agreement, activity, and/or other conditions including the execution of a monetary payment or state of a distributed ledger (e.g.: a blockchain).) Examiner interprets the term attestor is analogous for the term DAC Clearing Services in the cited prior art. Examiner interprets the term data consumers is analogous for the term Recipient Client in the cited prior art.
Beck does not explicitly disclose A computing system for creating a trusted data management model in a decentralized computing environment, the system comprising: at least one computing processor; and at least one memory storing instructions that, when executed by the at least one computing processor, cause the at least one computing processor to carry on the method of: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure for capturing, indexing, and storing attestation data corresponding to an attestation, wherein an attestation is a claim about an item or a linkage between items made by at least one authorized and accountable attesting user in a data context; creating at least one property, the creation done by an authorized user within the source control context signing a distributed ledger transaction, each of said at least one property including one of the at least one source, a name, a data type, and structure to thereby define associated attestation data.
However, Boston teaches A computing system for creating a trusted data management model in a decentralized computing environment, the system comprising: at least one computing processor; and at least one memory storing instructions that, when executed by the at least one computing processor, cause the at least one computing processor to carry on the method of: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure for capturing, indexing, and storing attestation data corresponding to an attestation, wherein an attestation is a claim about an item or a linkage between items made by at least one authorized and accountable attesting user in a data context, ; creating at least one property, the creation done by an authorized user within the source control context signing a distributed ledger transaction, each of said at least one property including one of the at least one source, a name, a data type, and structure to thereby define associated attestation data(Column 10/line 65, The personal computing devices may include various connections such as a cell phone connection, WiFi connection, Bluetooth connection, satellite network connection, and/or near field communication (NFC) connection, for example. The servers and personal computing devices described above may include at least one programmed processor and at least one memory or storage device. The memory may store a set of instructions. The instructions may be either permanently or temporarily stored in the memory or memories of the processor. The set of instructions may include various instructions that perform a particular task or tasks, such as those tasks described above. Such a set of instructions for performing a particular task may be characterized as a program, software program, software application, app, or software. The modules described above may comprise software, firmware, hardware, or a combination of the foregoing. It is appreciated that in order to practice the methods of the embodiments as described above, it is not necessary that the processors and/or the memories be physically located in the same geographical place.; and Figure 2A; Column 5/line 35, As depicted in FIG. 2A, the generated metadata 11 and smart contract 12 can be added to the blockchain 30. In particular, the metadata 11 and smart contract 12 can be stored in a block on the blockchain 30. FIG. 2B depicts an example of a distributed ledger in the blockchain of FIG. 2A. According to an embodiment, the distributed ledger in blockchain 30 is stored on a plurality of nodes 31, with each node being associated with a cryptographically-verified corresponding ledger 32. With the blockchain 30, the annotated and reviewed document 10's origin, chain of possession, and modifications can be tracked, traced, and presented chronologically in the cryptographically-verified ledger 32 to each participant of the blockchain 30; and Column 6/line 14, FIG. 2C depicts an example embodiment of a blockchain ledger associated with the functional interaction in FIG. 2A. According to an embodiment, the blockchain ledger 32 can include information about (i) the particular hash function value associated with the added metadata 11 and the smart contract 12; and Column 5/line 23, the metadata 11 can include a variety of information about the reviewed document 10. For example, the metadata 11 can indicate (i) the ownership of the reviewed document 10, (ii) the location of the reviewed document 10, (iii) whether the reviewed document 10 needs to be retained or purged, and (iv) information about the particular keys required to access the reviewed document. The smart contract 12 can include computer protocols that execute when predefined conditions occur. For example, the smart contract 12 can execute specific protocols when the knowledge worker begins to curate a plurality of reviewed documents; and Column 6/line 31, FIG. 3 depicts an example embodiment of metadata created by the document analysis module 20 of data exchange system in FIG. 1. As depicted in the figure, the metadata 11 can include a variety of information about a particular document 10, e.g., (i) the current name, (ii) the original name, (iii) provenance information, (iv) ownership information, (v) location information, (vi) whether the knowledge worker curator approved the document for use as training data, (vii) whether a data scientist curator approved the document for use as training data, (viii) whether the document is associated with a retention or purge policy, and (ix) the keys to access, open, and read the document, respectively. According to an embodiment, knowledge worker curators review the improvement data to determine whether the data provides a good example of the concept (for example, is “560 Lexington Avenue” a good example of the concept “Property Address” for an appraisal). The data science curator would instead be considering whether this same example is an appropriate example given the overall model itself (e.g., does this example demonstrate a possible flaw in the typology of the system, or demonstrate the need for a new modeling technique). The keys are used to provide permissions to users (both human and machine) to access the database 40. Once a user is allowed to have access, they can be given a key that is used in an access request to the database. The database only allows users with specific permissions (through those keys) to access the appropriate information.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck to the known invention of Boston would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include a computing system for creating a trusted data management model in a decentralized computing environment, the system comprising: at least one computing processor; and at least one memory storing instructions that, when executed by the at least one computing processor, cause the at least one computing processor to carry on the method of: creating infrastructure, by the deployment of smart contracts to a distributed ledger, the infrastructure including a data structure for capturing, indexing, and storing attestation data corresponding to an attestation, wherein an attestation is a claim about an item or a linkage between items made by at least one authorized and accountable attesting user in a data context; result in an improved invention because applying said technique will provide a secure and reliable way to manage data in a decentralized system, thus improving the overall performance of the invention.
Beck as modified does not explicitly paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment.
However, Johnston teaches paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment, (Para. 0009, designing a credibility attestation system wherein entities can vouch for transactional counterparties by staking value on their engagements, incentivizing participants to accurately represent entity credibility and deterring fraudulent behavior to the betterment of all economies involved ; and Fig. 3B; and Para. 0047, Token protocol 114 (CreD) is an enhanced blockchain smart contract-based utility token in one instance, or a digital asset wrapper in another, that is central to the credification program 109 vouching and incentive protocol. The smart contract may register any digitalized asset or security. In some embodiments, the digitalized asset or security may be selected by the parties or the marketplace… More concretely, the token protocol 114 is the currency of staking. In the depicted embodiment, token protocol 114 is a function of the credification program 109. In other embodiments, the token protocol 114 may be a stand-alone program or function located on another server, computing device, or location provided token protocol 114 has access to the other components of the computing environment 100A.; and Para. 0010, In a first embodiment, the present invention is a method of attesting to the credibility of entities engaged in commerce and trade, utilizing a value-staked vouching mechanism wherein backing positive outcomes results in economic rewards for attesters…receiving, by one or more processors, a request from a voucher account to attest to or stake on an entity's credibility, wherein the voucher account has a documented prior economic engagement with the entity; assigning, by one or more processors, the voucher account to attest to or stake on the credibility of the entity, wherein the assignment allocates a portion of at least one tokenized asset associated with the voucher account.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Johnston would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate attestation data features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include paying, by data consumers, an economic incentive to the attestor via a utility token, wherein the utility token is a blockchain based fungible token representing a fee charged to data consumers to receive access to the attestation data, wherein the fee is operable to be set at the source, property, and/or attestation assignment result in an improved invention because applying said technique will ensure that there is a secure way to reward verifiers with tokens, thus improving the overall performance of the invention.
Beck as modified does not explicitly performing unit conversions using a unit conversion registry, wherein a unit registry code is generated by developers and mapped to an original unit and a desired unit.
However, Lai teaches performing unit conversions using a unit conversion registry, wherein a unit registry code is generated by developers and mapped to an original unit and a desired unit, (Para. 0081-0084, According to a particular embodiment, the forked blockchain utilizes some variation from the rules and configuration parameters utilized by default within the primary consensus blockchain, resulting in the need for a valid forked blockchain. Therefore, the variation of the rules and configuration parameters are encoded within a new blockchain protocol certification 166 for the fork root block 144 which, as noted above, must remain compliant with the original rules and valid range of configuration parameters as set forth by the blockchain protocol certification 166 of the original genesis block 141 for the primary blockchain. Because the fork root block 144 must continue to carry the original blockchain protocol certification 166, a forked blockchain protocol certification may be stored within a block payload 169 segment of the fork root block 144 thus establishing the rules and permissible configuration parameters of subsequent standard blocks 142 in the forked blockchain. When a new blockchain protocol certification 166 is applied for a valid fork, its rules and configuration is applied to all subsequent standard blocks for the fork and all subsequent sub-forks, where additional forks are permitted, and enforced by the participating nodes as though the forked blockchain were an original primary blockchain. Such forks may be desirable for certain customers seeking to apply a specialized set of rules or configurations for a particular group, such as a working group, a certain sub-type of transactions, or some other variation from the primary blockchain where an entirely separate “sidechain” is not required or desirable. A forked blockchain is distinguishable from a sidechain as it remains part of the same blockchain protocol and is permanently connected with the primary blockchain at the fork block 143 with a returned fork hash 149 being returned to and immutably written into the primary consensus blockchain where it will remain via the chain hashing scheme for all subsequent standard blocks of the primary blockchain. Stated very simply, the forked blockchain is explicitly tied to the primary blockchain via the fork block 143. Conversely, a sidechain may be an entirely distinct blockchain protocol for which an agreed rate of exchange or conversion factor is applied to all information or value passed between the primary blockchain and any sidechain without any explicit reference or fork hash 149 embedded within the primary blockchain. Sidechaining therefore is a mechanism by which tokens, value, or payload entries from one blockchain may be securely used within a completely separate blockchain via a pre-defined exchange or conversion scheme, and yet, be permissibly moved back to the original chain, if necessary. By convention, the original blockchain is referred to as the main chain or the primary blockchain, whereas any additional blockchains which allow users to transact within them utilizing the tokens, values, or payload of the main chain are referred to as sidechains. For instance, there may be a private blockchain with a defined linkage to a public blockchain, thus allowing tokens, value, or payload data to be securely moved between the public blockchain and the private blockchain. According to described embodiments, the blockchain protocol certification 166 defining the protocol rules for a forked chain may be developed in any relevant programming or scripting language, such as, Python, Ruby, Perl, JavaScript, PHP, Scheme, VBScript, Java, Microsoft .Net, C++, C#, C, or a custom-created language for defining the protocol rules.
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Lai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include performing unit conversions using a unit conversion registry, wherein a unit registry code is generated by developers and mapped to an original unit and a desired unit, result in an improved invention because applying said technique will allow for more accurate data with the system able to make conversions, thus improving the overall performance of the invention.
14. Regarding Claims 17 and 20, Beck does not explicitly disclose further comprising a compliance oracle facilitating execution of at least one smart contract, wherein the at least one smart contract permits creation and enforcement of policies and wherein the at least one smart contract provides for evaluation of the policies to determine if a proposed state change in the decentralized computing environment is authorized.
However, Lai teaches further comprising a compliance oracle facilitating execution of at least one smart contract, wherein the at least one smart contract permits creation and enforcement of policies and wherein the at least one smart contract provides for evaluation of the policies to determine if a proposed state change in the decentralized computing environment is authorized, (Para. 0147-0150, As shown here, the aspects of authorization control are distributed to the various end points including the API manager 632 which registers roles onto an AccessChain 633 (e.g., a blockchain configured for the purpose) and grants roles to the access manager 634, while the CloudHub 635 also registers roles to the AccessChain 633 and grants roles to the access manager 634, followed by the Exchange cloud 636 which, as with the other end points, also registers roles to the AccessChain 633 and grants roles to the access manager 634, and finally the Access Manager cloud which in addition to being able to register roles to the AccessChain, has the further capability of delegating specific roles to users. In such a way, through the deployment of smart contracts onto an AccessChain configured blockchain network, all services own their own role definitions, while the AccessChain stores and validates and authorizes all permission mappings. Finally, the Access manager hosts “users” and facilitates the assignment of granular permissions at the user level. FIG. 6E depicts another exemplary architecture 640, specifically depicting an exemplary AccessChain configured Blockchain for Customer APIs 641, in accordance with described embodiments. As shown here, there is an API gateway 642 which communicates with an API manager 643 to firstly receive or get the RBAC policy, and secondly the API gateway receives customers' client 644 calls to the API exposed by the API gateway. Third, the API gateway enforces the RBAC policies through the AccessChain configured blockchain 645. Fourth and finally, the API gateway forwards the authorized call to the customer specific or customer hosted API 646. Here it is shown that the Walmart API 644 is attempting to make a call to the CocaCola API 646, however, it must first be brokered through the API gateway 642 and subjected to RBAC policies which are persisted on the AccessChain configured blockchain. According to such embodiments, the AccessChain 645 can enforce the RBAC policy between two distinct customers of the host organization, such as CocaCola and Walmart as shown in this example. Coca Cola defines the RBAC policy via the API manager 643 for the “CocaCola API” while Walmart requests access to the “/order” endpoint of the CocaCola API, to which access is granted pursuant to the RBAC policy enforced by the API gateway).
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Lai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include further comprising a compliance oracle facilitating execution of at least one smart contract, wherein the at least one smart contract permits creation and enforcement of policies and wherein the at least one smart contract provides for evaluation of the policies to determine if a proposed state change in the decentralized computing environment is authorized result in an improved invention because applying said technique will allow the smart contract to automatically check and enforce rules, thus improving the overall performance of the invention.
15. Regarding Claims 18 and 21, Beck does not explicitly disclose further comprising the compliance oracle referencing the at least one smart contract and providing a general-purpose data management layer including flexible controls to enable at least one user to define a data schema, share data, manage access and authority to create, update, and delete decentralized data, track provenance and data staleness, and/or mediate between differing formats for data consumption.
However, Lai teaches further comprising the compliance oracle referencing the at least one smart contract and providing a general-purpose data management layer including flexible controls to enable at least one user to define a data schema, share data, manage access and authority to create, update, and delete decentralized data, track provenance and data staleness, and/or mediate between differing formats for data consumption, (Para. 0130-0131, Each database can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object, and may be used herein to simplify the conceptual description of objects and custom objects as described herein. It is understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. It is understood that the word “entity” may also be used interchangeably herein with “object” and “table.” In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.; and Para. 0147-0148, As shown here, the aspects of authorization control are distributed to the various end points including the API manager 632 which registers roles onto an AccessChain 633 (e.g., a blockchain configured for the purpose) and grants roles to the access manager 634, while the CloudHub 635 also registers roles to the AccessChain 633 and grants roles to the access manager 634, followed by the Exchange cloud 636 which, as with the other end points, also registers roles to the AccessChain 633 and grants roles to the access manager 634, and finally the Access Manager cloud which in addition to being able to register roles to the AccessChain, has the further capability of delegating specific roles to users. In such a way, through the deployment of smart contracts onto an AccessChain configured blockchain network, all services own their own role definitions, while the AccessChain stores and validates and authorizes all permission mappings. Finally, the Access manager hosts “users” and facilitates the assignment of granular permissions at the user level.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Lai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include further comprising the compliance oracle referencing the at least one smart contract and providing a general-purpose data management layer including flexible controls to enable at least one user to define a data schema, share data, manage access and authority to create, update, and delete decentralized data, track provenance and data staleness, and/or mediate between differing formats for data consumption result in an improved invention because applying said technique ensures that users can control and access their data, thus improving the overall performance of the invention.
16. Regarding Claims 19 and 22, Beck does not explicitly disclose further comprising creating attributes based on the at least one smart contract and assigning the attributes to classes or objects and populating the attributes with values based on authorized internal or external sources.
However, Lai teaches further comprising creating attributes based on the at least one smart contract and assigning the attributes to classes or objects and populating the attributes with values based on authorized internal or external sources, (Para. 0283-0288, According to one embodiment, the smart contract applies a data mask to validate compliance of the data or metadata to be written to the blockchain. In other embodiments, the smart contract enforces rules which are applied to the data as part of the validation procedure. According to one embodiment, the smart contract executes as part of a pre-defined smart contract system which executes with any blockchain which permits the use of smart contracts, and the smart contract performs the necessary data validation. According to one embodiment, the data or metadata to be written to the blockchain 1299 is converted to a JSON format to improve storage efficiency. JavaScript Object Notation (JSON) provides an open-standard file format that uses human-readable text to transmit data objects consisting of attribute—value pairs and array data types or any other serializable value…As shown here, the asset created 1314 by application #1 is written onto the blockchain as asset 1315. The blockchain 699 is depicted as receiving the written asset 1315 at standard block 685A following genesis block 684, as shown. Although it will be written to the latest new block on the blockchain 699, such as standard block 685B, or 685C, or some other later block, whatever block that is at the time of the transaction.; and Para. 0321-0333, As depicted here, the blockchain administrator defines metadata via the integration builder's (element 153) GUIs or via the integration builder's API, and that defined metadata 1321 is then pushed onto the specified blockchain 1399. The defined metadata 1321 may be transacted through the REST API 178 provided by the blockchain services interface 190 and ultimately the asset created 1314 is written onto the accessible public blockchain 1399. Now, there is, transacted onto the blockchain, a clearly defined metadata specifying the requirements for the declared application “ApplicationXYZ” and specifically for the “Customer_Record,” which is now structured as follows, as per the defined metadata…Because the defined metadata 1321 is transacted onto the blockchain, any application with permission to access data records on the blockchain 1399 will be able to read and write data in compliance with the requirements specified by the defined metadata 1321. This may be the specifically declared application, “ApplicationXYZ,” or this may be other applications which utilized the data generated or managed by the declared application. Any application can read out the defined metadata 1321 and operate in compliance with the requirements. In particular, it is now depicted that businesses 1305A and 1305B are enabled to share data transacted onto the blockchain 1399 and because the defined metadata 1321 specifies the requirements for formatting such data, the data written to the blockchain 1399 and retrieved from the blockchain will embody a known format, and thus be transferable between the various businesses. As shown here, the blockchain administrator defines the metadata via the blockchain services interface 190 which is transacted onto the blockchain, and then later, business 1305A creates an asset 1314 via application #1 and it writes that asset having the details of a customer record into the blockchain. Subsequently, business 1305B retrieves the asset from the blockchain and when the asset is interpreted 1317 via application #2 executing at business 1305B, that data is successfully interpreted and understood by the application because there is a known and defined metadata structure for the customer record data.)
One of ordinary skill in the art would have recognized that applying the known technique of Beck as modified to the known invention of Lai would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include further comprising creating attributes based on the at least one smart contract and assigning the attributes to classes or objects and populating the attributes with values based on authorized internal or external sources, result in an improved invention because applying said technique will ensure that smart contracts are used to create and assign attributes to items to ensure all data is monitored and accurate , thus improving the overall performance of the invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
System, Method And Program Product For Modifying A Supply Of Stable Value Digital Asset Tokens (US 10373158 B1) teaches a method, system and program product for modifying a supply of stable value digital asset tokens tied to a blockchain.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
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, Neha Patel can be reached on (571) 270-1492. 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.
/D.L.K./Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699