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 .
DETAILED ACTION
Arguments and amendments filed 12/3/2025 have been examined.
Claims 1, 11, 14, 24 and 27 has been amended.
Claims 6 and 19 have been previously cancelled.
Thus, in this Office Action, claims 1-5, 7-18, 20-27 are currently pending.
Terminal Disclaimer
The terminal disclaimer filed on 1/24/2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Patent No. 11,687,558 and 11,023,490 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Arguments
As to the Argument:
“Applicant submits that Madhavan, or Kadt fail to teach or suggest at least the
following limitations: (citation omitted). In contrast, Madhavan teaches a bilateral distributed ledger (BDL) and bilateral assertion model (BAM) that exchanges validation messages among ledger devices for realtime reconciliation. As noted by Madhavan: (citation omitted) Thus, the BAM structure taught by Madhavan supports real-time reconciliation by modifying the distributed data structure directly once validation is complete, eliminating the need for end-of-day reconciliation used in centralized databases.”
The Examiner respectfully disagrees.
To the contrary, Madhavan teaches validating prior to modifying the shared data structure, i.e. the asserted “prior to modifying the selectively replicated and real time reconciling shared data structure“ limitations, See Madhavan Fig. 8 item 812: “determine if request is valid”; before step 818: “modify data stored in a shared data structure”;
see also Madhavan Fig. 9B step. 918 “Determine if all identified participants have validated”, before step 924: “Modify data stored in the portion of the shared data structure”;
see also Fig. 9C item 934: “Validate the request to modify the data” before step 944: “modify the portion of the data structure”
see also Madhavan para. [0096] The operation of the system further includes determining
based on the received validation data transaction messages 316, whether all of the identified other participants 308 and 310 have validated the request to modify the data (block 812), and, based thereon, if all of the identified other participants have validated the request to modify the data, generating a confirmation data transaction message 318 (block 814), and transmitting the confirmation data transaction…The operation of the system then further includes modifying
the data stored in the memory in the shared data structure according to the request to modify the data (block 818).)
As the cited prior art explicitly teaches the above asserted limitations, the examiner remains unconvinced, thus this argument is moot and the rejection under 35 USC 103 remains.
As to the Argument:
“Kadt does not fill the gaps by Madhavan. Kadt relates to implementing an asset
tracking tool that does not require trust of the implementing system for verification of the
system's contents.
Therefore, neither Madhavan nor Kadt teach or suggest Applicant's claimed
selectively replicated and real time reconciling, the notification, validation, and storage
protocol, or the schema sharing and negotiation of the instances as claimed, whereby
requests to make a modification to the shared data structure must be validated, using the ledger structure, by other instances having a relationship with the data request change before that modification is actually made.
Accordingly, for at least the reasons set forth above, neither Madhavan, and Kadt,
alone or in combination, anticipates or renders obvious claims 1, 14, and 27 or the claims which depend therefrom. Applicant therefore requests that this rejection be withdrawn.”
The Examiner respectfully disagrees.
To the contrary, again, Madhavan teaches validating prior to modifying the shared data structure, i.e. the asserted “prior to modifying the selectively replicated and real time reconciling shared data structure“ limitations, See Madhavan Fig. 8 item 812: “determine if request is valid”; before step 818: “modify data stored in a shared data structure”;
see also Madhavan Fig. 9B step. 918 “Determine if all identified participants have validated”, before step 924: “Modify data stored in the portion of the shared data structure”;
see also Fig. 9C item 934: “Validate the request to modify the data” before step 944: “modify the portion of the data structure”
see also Madhavan para. [0096] The operation of the system further includes determining
based on the received validation data transaction messages 316, whether all of the identified other participants 308 and 310 have validated the request to modify the data (block 812), and, based thereon, if all of the identified other participants have validated the request to modify the data, generating a confirmation data transaction message 318 (block 814), and transmitting the confirmation data transaction…The operation of the system then further includes modifying
the data stored in the memory in the shared data structure according to the request to modify the data (block 818).).
See also Madhavan teaches using the ledger for validation, i.e. “validated the data change request, using the ledger data structure” see [0042] Financial institutions, as participants on the BAM/BDL as described herein, may respond to obligations, i.e. assertions thereof, posted to the cash ledger by moving the monies and posting back, e.g. via validation or a counter-assertion, on the cash ledger reflective of the movement;
see also [0112] Similarly, the data stored in the portion of the shared data structure 320 or electronic ledger 732, may further include data which identifies the at least one other participant to validate the request;
see also [0126] Similarly, the message generator 726 may be further operative to generate a response data transaction message for each of the identified at least one other participants, i.e. the ledger device 502B, 502C, 502n associated therewith, comprising data indicative that the data in the portion of the shared data structure 320, or electronic ledger 732, has not been modified if less than all of the identified other participants have validated the request.
As the cited prior art explicitly teaches the above asserted limitations, the examiner remains unconvinced, thus this argument is moot and the rejection under 35 USC 103 remains.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-5, 7-18, 20-27 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 (and similar claim 14 and claim 27) recite:
“modify a selectively replicated and real time reconciling shared data structure comprising a
ledger data structure coupled with a relational database stored in a memory
coupled with the processor of the instance;”
The Examiner searched the priority documents/specification for the above amended limitations and could not find support for the claimed “structure comprising a ledger data structure coupled with a relational database” limitation. Nowhere is the term “coupled” is used with the relational database limitations in the specification. The dependent claims inherit and do not correct his defect and thus are also rejected.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-18 and 20-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Madhavan et al., US Pub. No. 2017/0293669, in view of Jacques de Kadt et al., US Pub. No.: US 2018/0096163.
As to claim 1 (and substantially similar claim 14 and claim 27),
Madhavan discloses
a computer implemented method
(Madhavan abstract)
comprising:
receiving, via a communications network by an instance
of a plurality of remote instances, each of the plurality of remote instances
comprising a processor executing applications which interact with local participant
computer systems,
(Madhavan teaches multiple participant systems which allow multiple resources (such as databases, application servers, message queues, transactional caches, etc.) to be accessed within the same transaction, i.e. “remote instances comprising a processor executing applications which interact with local participant computer systems” see [0085] FIG. 3 depicts example operation of an illustrative system 300 which implements the disclosed bilateral assertion model ("BAM") for interacting with a shared data structure according to one embodiment. FIG. 3 includes example participants 302, 308, and 310. The system 300
may utilize any number of participants 302, 308, 310 from Pl ... Pn. A participant 302, 308, 310 may interact with the system 300 in one or more of a variety of roles, including,
but not limited to: as a party to a transaction (a proposer of the transaction, an asserter of fact or agreement, an issuer of a credential, authorization, license, certification/certificate, or accreditation etc.); as a counterparty to a transaction; as a witness to a transaction; and/or as a watcher to a transaction. It will be appreciated that not all of these roles may be implemented and/or additional and/or alternative roles; see also [0081] The XA standard is a specification by The Open Group for distributed transaction processing (DTP). It describes the interface between the global transaction manager and the local resource manager. The goal of XA is to
allow multiple resources (such as databases, application servers, message queues, transactional caches, etc.) to be accessed within the same transaction, thereby preserving the
ACID properties across applications.)
a data change request communicated by another instance, of the plurality of instances
(Madhavan teaches messages, requesting to change data in the shared data structure, between selected participants, i.e. “a data change request communicated by another instance, of the plurality of instances” see abstract: “The method may comprise the exchange of messages, requesting to change data in the shared data structure, between selected participants, wherein some of the participants must validate requested changes to the shared data. If all participants
validate the requests to change data the changes to the data are made, and if less than all participants validate the requests then the changes are not made.”;
see also [0111] In the case of a request data transaction message, the operation of the system
includes processing of a request data transaction message (block 906). The operation of the system further includes identifying a participant to validate modifications to data (block 908); and modifying a portion of a shared data structure 320 according to the identified participant (block
910).)
the data change request comprising data indicative of a request to modify a selectively replicated and real time reconciling shared data structure comprising a ledger data structure
(Madhavan teaches requests to add new data or modify existing data in a ledger that is real time or self-reconciling in real time and replicated selectively
See [0032-0034] [0032] the BDL provides a selectively distributed data structure, e.g. an electronic ledger, which tracks bilaterally associated assertions among pairs of participants.; [0034] In the disclosed BAM, a party-participant's attempt, request or other indication of an intent to change data in the data structure, e.g. to add new data or modify existing data, is implicitly communicated to the other counter-party participant identified as being interested in that data, e.g. via a request,
see also [0063] As such, the counter-party participant's copy of the data is immediately reconciled. Herein such reconciliation may be referred to as real time or self-reconciliation or
that the data structure is real time or self-reconciling, immediately reconciled, reconciled in real time or inherently reconciled. Furthermore, as data is only replicated selectively, i.e., only among the sub-divided portions of the data structure belonging to the participants which have an interest in that data, unnecessary data transmissions and replication are avoided and, as will be seen, the security of the data is thereby improved. )
coupled with a relational database stored in a memory coupled with the processor of the instance;
(Madhavan teaches local SQL/relational databases see [0077] As such, the traditional operation
of the centralized database/DBMS is not interrupted or affected and may still be used to service those users, e.g. legacy users, who have not adopted, or completed the adoption of, the BAM implementation. In such implementation, the assertions being made and validated may be
assertions as to a net result of a change, or all prior changed, made to the database, akin to a commit operation. For example, consider Imagine a data manipulation language ("DML") operation, such as a SQL operation, on Party A's local store (INSERT/UPDATE/DELETE) via a thread in Java.; see also [0011] The durability property ensures that once a transaction
has been committed, it will remain so, even in the event of power loss, crashes, or errors. In a relational database, for instance, once a group of SQL statements execute, the results need to be stored permanently ( even if the database crashes immediately thereafter).)
validating, automatically by the processor
(Madhavan teaches validating & updating the change request in the shared data structure see [0034] In the disclosed BAM, a party-participant's attempt, request or other indication of an intent to change data in the data structure, e.g. to add new data or modify existing data, is implicitly communicated to the other counter- party participant identified as being interested in that data, e.g. via a request, or other communication reflecting an opportunity, to validate the change, to obtain the counterparty participant's validation, or otherwise cause them to
validate, that the requested change is acceptable,; see also [0036] If the counter-party participant validates the intention of the party to change the data, e.g. responds to the validation request approving the requested change, e.g. acceding to the assertion of fact or agreeing to the proposed agreement, the data structure is updated in accordance therewith as both parties,; see also [0129] The operation of the system further includes identifying a participant to validate modifications to data (block 908); and modifying a portion of a shared data structure 320 according to the identified participant (block 910).)
prior to modifying the selectively replicated and real time reconciling shared data structure based on the request therefore the data change request,
(Madhavan teaches validating prior to modifying the shared data structure
See Fig. 8 item 812: “determine if request is valid”; before step 818:”modifiy data stored in a shared data structure”;
see also fig. 9B step. 918 “Determine if all identified participants have validated”, before step 924: “Modify data stored in the portion of the shared data structure”;
see also Fig. 9C item 934: “Validate the request to modify the data” before step 944: “modify the portion of the data structure”
see also [0096] The operation of the system further includes determining
based on the received validation data transaction messages 316, whether all of the identified other participants 308 and 310 have validated the request to modify the data (block 812), and, based thereon, if all of the identified other participants have validated the request to modify the data, generating a confirmation data transaction message 318 (block 814), and transmitting the confirmation data transaction…The operation of the system then further includes modifying
the data stored in the memory in the shared data structure according to the request to modify the data (block 818).)
wherein validating comprises:
using the ledger data structure separate from the relational database,
(Madhavan teaches modifying the data stored in the portion of the shared data structure for a validation, i.e. “using the ledger data structure separate from the relational database”
see [0111] The operation of the system 700 further includes generating a notification data transaction message (block 912) and transmitting the notification data transaction message
(block 914). The operation of the system 700 further includes receiving, in response to the notification data transaction message, a validation data transaction message (block 916). The operation of the system 700 also includes determining if all identified participants have validated the request to modify data (918) and, if all, or alternatively, a requisite subset of, the identified participants have validated the request to modify data, the operation of the system 700
includes generating a response data transaction message (block 920), transmitting the response data transaction message (block 922), and modifying the data stored in the portion of the shared data structure 320, or electronic ledger 732, (block 924).)
identifying, by the processor, one or more other instances, to validate the data change request, based on the one or more instances having a relationship to the request to modify the shared data structure;
(Madhavan teaches “Determine if all identified participants have validated” item 918 Fig. 9B
see also [0036] If the counter-party participant validates the intention of the party to change the data, e.g. responds to the validation request approving the requested change, e.g. acceding to the assertion of fact or agreeing to the proposed agreement, the data structure is updated in accordance therewith as both parties,
See also [0123] the transaction receiver 720 may be further operative to receive a response data transaction message from the participant, i.e. the ledger device 502B, 502C, 502n associated therewith, the response data transaction message comprising data indicative of a confirmation of receipt by the participant, i.e. the ledger device 502B, 502C, 502n associated
therewith, of the validation transaction message, and determining, whether the received response data transaction message comprises data indicative of a confirmation that the data in the other portion of the shared data structure 320, or electronic ledger 732, has been modified or not)
transmitting, via the communications network, by the processor, the data change validation request message, to each of the one or more instances;
(Madhavan Fig. 9B and item 920: “All Validated”/“Generate a response data transaction message”; see also item 922: “Transmit the response data transaction message” see also 914: “Transmit the notification data transaction message”)
and committing the requested modification of the received data change request to the relational database; and
(Madhavan 669 Fig. 9B item 924: “Modify data stored in the portion of the shared data structure”;
see also [0077] the assertions being made and validated may be assertions as to a net result of a change, or all prior changed, made to the database, akin to a commit operation. For
example, consider Imagine a data manipulation language ("DML") operation, such as a SQL operation, on Party A's local store (INSERT/UPDATE/DELETE) via a thread in Java. The thread does not return until the change is confirmed by party B.;
see also [0080] With respect to databases, a commit operation makes any transactional changes to data stored in the database permanent, i.e. from the perspective of the participants
which now see the data as having been changed.)
receiving a validation data message from at least one of the identified one or more other instances responsive to the data change validation request message
(Madhavan [0095] The operation of the system further includes receiving a validation data
transaction message 316, responsive to the notification data transaction message 314, from
each of the identified at least one other participants, each of the received validation data
transaction messages 316 comprising data indicative of a response to the notification data
transaction message 314 (block 810). As described herein, upon receipt of a notification
data transaction message 314, the recipient determines whether the request to modify the data
is valid, e.g. according to the business rules or logic of the recipient, and generates and
transmits a validation data transaction message 316 comprising data indicative thereof back to
the sender of the notification data transaction message;
See also Madhavan, claim 1: "receiving, by the processor via the network interface responsive
to the notification data transaction messages, a validation data transaction
message from each of the identified at least one other participants, each of the
received validation data transaction messages comprising data indicative of a
response to the request to modify data stored in the portion of the shared data
structure;")
and determining, based on the received validation data message, that all of the identified one or more other instances have or have not validated the data change request;
(Madhavan [0096] The operation of the system further includes determining based on the
received validation data transaction messages 316, whether all of the identified other
participants 308 and 310 have validated the request to modify the data (block 812), and, based
thereon, if all of the identified other participants have validated the request to modify the data,
generating a confirmation data transaction message 318 (block 814), and transmitting the
confirmation data transaction message to the first participant 302 (block 816);
See also Madhavan, claim 1: "determining, by the processor, based on the received validation
data transaction messages, whether all of the identified other participants
have validated the request to modify the data in the portion of the shared data
structure")
when all of the identified one or more other instances have validated the data change request, using the ledger data structure, updating, by the processor, the shared data structure with the data change request
(Madhavan teaches modifying the shared data structure after successful validation see [0096]
The operation of the system further includes determining based on the received validation data
transaction messages 316, whether all of the identified other participants 308 and 310 have
validated the request to modify the data (block 812), and, based thereon, if all of the identified
other participants have validated the request to modify the data ... The operation of the system
then further includes modifying the data stored in the memory in the shared data structure
according to the request to modify the data (block 818).;
See also Madhavan, claim 1, and §77: "if all of the identified other participants have validated
the request to modify the data in the portion of the shared data structure: [ ... ]
modifying, in the memory via the processor, the data stored in the portion of the
shared data structure according to the request to modify the data;"
In combination with a centralized SQL database, [0077] teaches the implicit committing
after a completed (successful) validation: "[ ... ] a SQL operation, on Party A's local store
(INSERT/UPDATE/DELETE) via a thread in Java. The thread does not return until the change is
confirmed by party B. This would be similar to having a trigger on Party A's databases that
remotely modifies Party B's database accordingly but Party B's database also has a trigger that
triggers a Java program that validates the changes. Upon validation, Party B's database is
changed and the implicit response back to Party A's database commits the changes that Party
A made in the first place hence releasing the thread.";
See also Madhavan teaches using the ledger for validation, i.e. “validated
the data change request, using the ledger data structure” see [0042] Financial institutions, as participants on the BAM/BDL as described herein, may respond to obligations, i.e. assertions thereof, posted to the cash ledger by moving the monies and posting back, e.g. via validation or a counter-assertion, on the cash ledger reflective of the movement;
see also [0112] Similarly, the data stored in the portion of the shared data structure 320 or electronic ledger 732, may further include data which identifies the at least one other participant to validate the request;
see also [0126] Similarly, the message generator 726 may be further operative to generate a response data transaction message for each of the identified at least one other participants, i.e. the ledger device 502B, 502C, 502n associated therewith, comprising data indicative that the data in the portion of the shared data structure 320, or electronic ledger 732, has not been modified if less than all of the identified other participants have validated the request)
when less than all of the identified one or more other instances have validated
the data change request, using the ledger data structure
not updating, by the processor, the shared data structure with the data change request
(Madhavan teaches rejecting changed, when less than all of the identified other participants have validated [0097] However, in one embodiment, if less than all of the identified other participants have validated the request the operation of the system further includes generating a rejection data transaction message 316 (block 820), and transmitting the rejection data transaction message 316 to the first participant 302 (block 822).... The operation of the system then further includes not modifying the data 306 stored in the memory in the shared data structure according to the request to modify the data (block 824); See also Madhavan, claim 1: "if less than all of the identified other participants have validated the request: [ ... ] not modifying, in the memory via the processor, the data stored in the portion of the shared data structure according to the request to modify the data;"
See also Madhavan teaches using the ledger for validation, i.e. “validated the data change request, using the ledger data structure” see [0042] Financial institutions, as participants on the BAM/BDL as described herein, may respond to obligations, i.e. assertions thereof, posted to the cash ledger by moving the monies and posting back, e.g. via validation or a counter-assertion, on the cash ledger reflective of the movement;
see also [0112] Similarly, the data stored in the portion of the shared data structure 320 or electronic ledger 732, may further include data which identifies the at least one other participant to validate the request;
see also [0126] Similarly, the message generator 726 may be further operative to generate a response data transaction message for each of the identified at least one other participants, i.e. the ledger device 502B, 502C, 502n associated therewith, comprising data indicative that the data in the portion of the shared data structure 320, or electronic ledger 732, has not been modified if less than all of the identified other participants have validated the request).
While Madhavan teaches shared transaction partitions and classes for entries/assertions/signatures using a shared protocol;
Madhavan does not explicitly disclose:
generating, by the processor, a data change validation request message using a schema shared by the instance and each of the one or more other instances;
however, Jacques de Kadt discloses:
generating, by the processor, a data change validation request message using a schema shared by the instance and each of the one or more other instances;
(Jacques de Kadt teaches using schema formats for cryptographically secured ledger updates including JSON see [0041] The front end interface 212passes the request 208 to an entity associated with the cryptographically secured ledger 210 to determine whether the request 208 is valid and any constraints, e.g., on other assets or limiting the requester's authority to make the associated change, apply. For example, if a given asset is associated with a key, a defining schema or database engine may automatically require that any change associated with that asset be initiated by the holder of that key;
See also [0015] The aforementioned constraints, such as update dependencies on, e.g., the existence of certain keys, fields, rows, columns, and the like, as well as permissions, may be implemented at one ( or a combination) of several layers. For example, a schema may be used to prescribe the relationships between different columns and/or fields, as well as how the data and/or metadata contained within the cryptographically secured ledger is to be represented in the associated database table. For example, an original schema may require a certain number of fields and restrictions or restraints on those fields. A new schema may be submitted that, for example, changes the number of fields, their characteristics, and what restrictions or restraints are on those fields. The schema, and transactions/changes associated therewith, may be committed to the cryptographically secured ledger and reflected in a similar fashion to other data in the cryptographically secured ledger;
see also [0079] The handling of all requests and responses, as well as the delivery of content between the client device 902 and the application server 908, can be handled by the web server
using PHP: Hypertext Preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example;
See also [0044] FIG. 3 illustrates an example environment 300 in which a schema defining one or more database formats ( e.g., fields) associated with an asset is updated so as to further
update the database representation of the asset, in accordance with some embodiments.;
see also [0023] For example, a client device 102 accesses a database 104, such as a relational database or a non-relational (e.g., NoSQL) database. In an embodiment, a managed,
distributed, non-relational database is provided as a service by the same computing resource service provider that also provides access (e.g., also as a service) to a cryptographically
secured ledger 106, and a NoSQL database is used so as to ease integration between the two ( owing to the more flexible data modeling/schema definitions enabled by nonrelational databases). Furthermore, such non-relational databases may be selected for their improved latency, throughput, and/or scalability relative to traditional relational databases. However, in some embodiments, a relational database may also be used, e.g., in implementations where
absolute relational consistency is desired.).
It would have been obvious to one having ordinary skill in the art at the time the time of the
effective filing date to apply updated to ledges using schemas via JSON, as taught by Jacques de Kadts, to the system of Madhavan, since it was known in the art that ledger consensus systems provide a format in which the database reflects the information in the cryptographically secured ledger which may be defined by one or more mechanisms where a schema may be implemented to associate the raw transactional data persisted in the cryptographically secured ledger with assets or other objects, as well as metadata associated with those objects where the schema may define the specific fields, columns, or rows for the associated data and metadata, and as previously mentioned, may be treated simply as another object in the cryptographically secured ledger ( e.g., updates and/or ownership transactions, and constraints associated with those transactions, may also be applied to schema objects) where a given record,
as defined. in the schema, may be associated with an asset, and may also include metadata associated with the asset, such as a current owner, links to associated assets, creator information, and the like, and records may be represented in the database table where rather than directly query the inherently serial cryptographically secured ledger a requester may merely query the generated database table in a familiar format for quick and efficient
retrieval of information related to assets held or otherwise represented in the cryptographically secured ledger (Jacques de Kadt [0035]).
As to claim 2, Madhavan as modified discloses the computer implemented method of claim 1, wherein the identified one or more other instances comprise less than all available instances
(Madhavan [0066] Conversely, if less than all of the identified other participants have validated
the request, the method may comprise generating a response data transaction message to the
requesting participant, or alternatively or in addition thereto, for each of the identified at least one other participants comprising data indicative that the data in the portion of the shared data
structure has not been modified, transmit the response data transaction message to the
requesting participant and/or each of the identified at least one other participants, and not
modify the data stored in the portion of the shared data structure according to the request to
modify the data;
see also [0097] However, in one embodiment, if less than all of the identified other participants
have validated the request the operation of the system further includes generating a rejection
data transaction message 316 (block 820), and transmitting the rejection data transaction
message 316 to the first participant 302 (block 822). In some embodiments, operation
of the system includes communicating the rejection data transaction message 316 to the other
participants 308 and 310.).
As to claim 3, Madhavan as modified discloses the computer implemented method of claim 1, wherein when the identified one or more other instances comprises only one other instance, the shared data structure which is maintained by the only one other instance, is updated upon transmission of the response to the validation request message validating the data change request
(Madhavan teaches having only one other participant/party see [0086] or otherwise results in
only one participant having the ability to reconstruct lost transactions and that participant
knowingly or unintentionally fails to provide complete or accurate data.; see also [0183] The
proposer may choose to pre-sign the proposal if there is only one counter party. This implies
that the proposer does not intend to send a confirmation. In such a case signing the entry will
automatically make it CONFIRMED. The state ACCEPTED on an entry will be present
when the recipient signs and sends back the proposal. The state REJECTED on an entry will be
present when the recipient does not sign and rejects the proposal).
As to claim 4, Madhavan as modified discloses the computer implemented method of claim 1, wherein the data change request is received from an application programming interface connected to the Instance
(Madhavan [0219] In one embodiment, the system 700 described above may be coupled with
an external process and/or device, not shown, which monitors the portion of the shared
data structure 304 for modifications thereto, such as for validated modifications, and implements
actions based thereon. For example, in a financial implementation where the validated
modification comprises an assertion of a debt to another party, the external process and/or
device, upon determining that the assertion has been validated, acts in accordance therewith to
cause funds to be transferred or disbursed in satisfaction of the debt. In one embodiment, the
system 700 may provide an interface, such as an application program interface, via
which other software and/or devices may access the shared data structure 304, such as
to make queries, i.e. pull data from the shared data structure 304, or receive unsolicited
data, updates or messages, i.e. data pushed from the shared data structure 304 ;
see also [0108] In one embodiment, the user interface 712 may comprise a programmatic
interface such as an application program interface ("API") to which other software programs
and/or devices are connected, such as via a network, those other software programs
and/or devices providing the requisite interactivity to a user of the system 700. In one
embodiment, the user interface 712 is coupled with the system 700 via a network. Alternatively,
the user interface 712 may be directly coupled with the system 700.).
As to claim 5, Madhavan as modified discloses the computer implemented method of claim 1, wherein the shared data structure comprises different sets of data for each of the one or more other instances
(Madhavan teaches partitions for different participants, i.e. "different sets of data for each of the
one or more other Instances" see [0109] The electronic ledger 732 stored in the memory
714 may further be subdivided or otherwise organized as a plurality of partitions where each
partition includes data, e.g. entries, indicative of a pair of participants, e.g. bilateral
participants. For example, if a transaction occurs between ledger device 502A and 502B, data
indicative of that transaction would be stored in a partition 702 in electronic ledger
732. A transaction, i.e. entries containing data indicative thereof, may be assigned a unique
identifier with respect to other transactions ( overall or within a given partition), such
as a sequence number, for identification purposes when they are stored in a partition 702.
Subsequent transactions, i.e. entries containing data indicative thereof, between 502A and
502B would be stored in the same partition 702).
As to claim 7, Madhavan as modified discloses the computer implemented method of claim 1, wherein the data change message comprises an assertion of a transaction
(Madhavan teaches various assertion messages see [0034] The data being modified
or added to the data structure may be indicative of an assertion, such as an assertion of fact or
truth, a proposed agreement, an authorization, license, certification, accreditation, etc., or other
statement of an intention to create, modify, or remove data from the shared data structure.;
see also [0036] If the counter-party participant validates the intention of the party to change the
data, e.g. responds to the validation request approving the requested change, e.g.
acceding to the assertion of fact or agreeing to the proposed agreement, the data structure is
updated in accordance therewith as both parties, who are the only parties interested
in that data, have approved the change.; see also [0088] Exemplary data transaction messages
include request data transaction messages 312, notification data transaction messages 314,
validation data transaction messages 316 and response data transaction messages 318.
Request data transaction messages 312 may include data indicative of one or more proposals,
such as a proposal of an agreement or other proposition or assertion of an opinion, or
an assertion, such as an assertion of fact, e.g. an assertion of the existence of an agreement,
an authorization, a license, a certification, an accreditation, a statement of intention, e.g.
an intention to create, modify or remove data, an assertion of a revocation of an agreement,
authorization, license, certification or accreditation, etc.).
As to claim 8, Madhavan as modified discloses the computer implemented method of claim 7, wherein the assertion comprises a novation of a trade transaction by an electronic trading system
(Madhavan teaches novation assertions see [0089] Once an assertion is made and
validated, as described, it may form a logically/effectively permanent unalterable record, i.e. as
viewed by the parties, users of the system. Accordingly, to effect a change to that assertion, a
subsequent assertion, once validated, may act to supersede or modify a previous validated
assertion, such as by acting as a revocation to revoke the prior assertion, an addendum
to add additional parameter, an amendment to alter terms and/or, a novation to alter the
parties to a prior assertion, etc. As can be seen then, and as discussed in more detail below,
as the original assertion remains unaltered, to understand the present state/understanding of
that assertion, it may need to be viewed in the context of, e.g. netted with, any subsequent
assertions.;
see also [0045] As was discussed elsewhere herein, the clearing function is typically performed
is by novating the trade i.e. CME inserting itself in the middle of a BUY /SELL agreement and
becoming the buyer for the seller and seller for the buyer for matched trades.; and [0017]
Clearing is the procedure through which the Clearing House becomes buyer to each seller of a
futures contract, and seller to each buyer, also referred to as a "novation," and assumes
responsibility for protecting buyers and sellers from financial loss due to breach of contract, by
assuring performance on each contract.).
As to claim 9, Madhavan as modified discloses the computer implemented method of claim 1, wherein the data change message comprises a change of permission for data in the shared data structure
(Madhavan teaches permissions/ defining which participants may access data stored see
[0037] It will be appreciated that the counter-party participant need not receive any confirmation message as it is already aware that if it approved the change, the change will be made, and if it
did not approve the change, the change will not be made. In implementations using a shared
data structure maintaining a single copy of the data to which all participants have access, each
data record in the data structure may include specific and unique permissions defining which
participants may access data stored therein, e.g. defining which participants may be permitted
to attempt or otherwise request a modification the data in that particular data record and which
other participants have an "interest" therein and should be notified as described above, where
the permissions may vary for each data record in the data structure.).
As to claim 10, Madhavan as modified discloses the computer implemented method of claim 1, wherein the identified one or more other instances are each characterized as at least one of a participant,
(Madhavan teaches party participants see [0033] Generally, all transactions in the disclosed
embodiments may be bilateral, or otherwise decomposed into component bilateral transactions,
e.g. assertions, between two participants, referred to as a party and a counter-party. That is, for
each data stored in the data structure, there are two interested participants having an interest in,
or otherwise related to, that data, referred to as the party-participant and the counter-party
participant.; see also [0094] FIG. 8 depicts a flow chart 800 showing example operation of the
system 400 of FIG. 3. In particular FIG. 8 shows an example computer implemented method for
facilitating interaction with a shared data structure, stored in a memory, by a plurality of
participants.)
a witness, or a watcher
(Madhavan [0074] In a multilateral implementation as will be described,
using witness and/or watcher parties, i.e. non-interested third party participants which also store
copies of transactions, fault tolerance may be improved via the additional redundancy
provided.; see also [0094] and one or more "witness" participants, of the plurality of participants
to validate modifications to the data (block 804). It will be appreciated that other participants,
such as one or more "watcher" participants, may also be identified, for example, for the purpose
of recording the transaction.).
As to claim 11, Jacques de Kadt as modified discloses
the computer implemented method of claim 1, wherein the schema is shared using JavaScript Object Notation
(Jacques de Kadt teaches using schema formats for cryptographically secured ledger updates including JSON See [0015] The aforementioned constraints, such as update dependencies on, e.g., the existence of certain keys, fields, rows, columns, and the like, as well as permissions, may be implemented at one ( or a combination) of several layers. For example, a schema may be used to prescribe the relationships between different columns and/or fields, as well as how the data and/or metadata contained within the cryptographically secured ledger is to be represented in the associated database table. For example, an original schema may require a certain number of fields and restrictions or restraints on those fields. A new schema may be submitted that, for example, changes the number of fields, their characteristics, and what restrictions or restraints are on those fields. The schema, and transactions/changes associated
therewith, may be committed to the cryptographically secured ledger and reflected in a similar fashion to other data in the cryptographically secured ledger;
see also [0079] The handling of all requests and responses, as well as the delivery of content between the client device 902 and the application server 908, can be handled by the web server
using PHP: Hypertext Preprocessor ("PHP"), Python, Ruby, Perl, Java, HTML, XML, JSON, and/or another appropriate server-side structured language in this example;
See also [0044] FIG. 3 illustrates an example environment 300 in which a schema defining one or more database formats ( e.g., fields) associated with an asset is updated so as to further
update the database representation of the asset, in accordance with some embodiments.;
see also [0023] For example, a client device 102 accesses a database 104, such as a relational database or a non-relational (e.g., NoSQL) database. In an embodiment, a managed,
distributed, non-relational database is provided as a service by the same computing resource service provider that also provides access (e.g., also as a service) to a cryptographically
secured ledger 106, and a NoSQL database is used so as to ease integration between the two ( owing to the more flexible data modeling/schema definitions enabled by nonrelational databases). Furthermore, such non-relational databases may be selected for their improved latency, throughput, and/or scalability relative to traditional relational databases. However, in some embodiments, a relational database may also be used, e.g., in implementations where
absolute relational consistency is desired.).
As to claim 12, Madhavan as modified discloses the computer implemented method of claim 1, wherein the ledger data structure comprises a bilateral distributed ledger ("BDL")
(Madhavan [0032] The disclosed embodiments relate to implementation of a bilateral assertion
model ("BAM") for interacting with a data structure which stores data of interest to, or
otherwise shared among, multiple parties, and, in particular an implementation of a BAM using a
bilateral distributed ledger ("BDL"), as a substrate, having the properties of
immutability, irrefutability, confidentiality, recoverability, atomicity, and durability. As will be
described, the BDL provides a selectively distributed data structure, e.g. an electronic ledger,
which tracks bilaterally associated assertions among pairs of participants.;
see also [0108] FIG. 7 A depicts a more detailed block diagram of a bilateral distributed ledger
("BDL") device 502A, 502B, 502C, or 502n of FIG. 6 according to one embodiment. The
ledger device 502A includes a portion of the data structure 320, i.e. an electronic l