Patent Grant
12099997
The present invention relates to the field of tokenized and cryptographically secured economic values useful in transactions, which employ distributed authentication and/or transaction closing. In particular, the technology addresses tokens which represent liabilities or net liabilities, and which are transferable, and may be anonymous and/or unsecured.
Note that a tokenized debt asset merely associated with a third party liability is not a tokenized liability per se.
Citation or identification of any reference herein, or any section of this application shall not be construed as an admission that such reference is available as prior art. The disclosure of each publication and patent listed or referenced herein are hereby incorporated by reference in their entirety in this application, see 37 C.F.R. § 1.57(c), and shall be treated as if the entirety thereof forms a part of this application. Such references are provided for their disclosure of technologies as may be required to enable practice of the present invention, to provide written description for claim language, to make clear applicant's possession of the invention with respect to the various aggregates, combinations, permutations, and subcombinations of the respective disclosures or portions thereof (within a particular reference or across multiple references) in conjunction with the combinations, permutations, and subcombinations of various disclosure provided herein, to demonstrate the non-abstract nature of the technology, and for any other purpose. Except as expressly indicated, the scope of the invention is inclusive, and therefore the disclosure of a technology or teaching within these incorporated materials is intended to encompass that technology or teaching as being an option of, or an addition to, other disclosure of the present invention. Likewise, the combination of incorporated teachings consistent with this disclosure is also encompassed. The citation of references is intended to be part of the disclosure of the invention, and not merely supplementary background information. While cited references may be prior art, the combinations thereof and with the material disclosed herein is not admitted as being prior art.
The incorporation by reference does not extend to teachings which are inconsistent with the invention as expressly described herein as being essential. The incorporated references are rebuttable evidence of a proper interpretation of terms, phrases, and concepts employed herein by persons of ordinary skill in the art. No admission is made that any incorporated reference is analogous art to the issues presented to the inventor, and the selection, combination, and disclosure of these disparate teachings is itself a part of the invention herein disclosed.
A distributed authentication system is one in which “truth” is determined by a distributed set agents, without central control or authority.
A distributed consensus system is one in which “truth” is determined by a vote or poll, of a distributed set agents, each with the ability to independently ascertain the validity of a proposition. A rule is applied to the vote or poll, to achieve consensus.
A blockchain is a growing list of records or blocks, each containing a cryptographic hash of a prior record or block, a timestamp, and transaction data, e.g. a Merkle tree. Typically, the data in each proposed new block is subject to test or contest, while prior blocks are presumed authenticated according to a correspondence of the block data to the hash. By design, a blockchain is resistant to modification of its data. This is because once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. In general, blockchain technologies have been considered as a way to represent and manage assets, that is rights that have affirmative positive value for the rights holder. This derives from their original invention as a means to provide anonymity and transferability, non-repudiation of a transaction, avoidance of double spending, and distributed architecture without a trusted third party.
The first decentralized cryptocurrency, bitcoin, was created in 2009 by presumably pseudonymous developer Satoshi Nakamoto. It used SHA-256, a cryptographic hash function, in its proof-of-work scheme. In April 2011. Namecoin was created as an attempt at forming a decentralized DNS, which would make internet censorship very difficult. Soon after, in October 2011. Litecoin was released. It used scrypt as its hash function instead of SHA-256. Another notable cryptocurrency, Peercoin used a proof-of-work/proof-of-stake hybrid. Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, whitepaper, Oct. 31, 2008 defined the original vision of Bitcoin. Bitcoin is described as a purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. Bitcoin proposed a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. Thus Bitcoin is predicated on a competition based largely on computational complexity. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. Bitcoin, and its progeny, therefore focus on a competition predicated on a desirability of the token representation of wealth, the so-called “Bitcoin”, and that game theory controlled its utility. However, that same competitive paradigm according to game theory, does not directly reveal how a token with a negative value, i.e., objectively undesirable, might be feasible to conduct transactions without a trusted intermediate.
Bitcoin serves the need for an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. Bitcoin provides a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. But, it does not address the antithesis a token representing a debt or obligation, since the possessor of a token is generally anonymous according to the protocol, and each transfer is identified only by a cryptographic digital wallet address Bitcoin defines an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.
A previously known cryptocurrency (or crypto currency or crypto for short) is a digital asset designed to work as a medium of exchange wherein individual coin ownership records are stored in a ledger existing in a form of computerized database using strong cryptography to secure transaction records, to control the creation of additional coins and to verify the transfer of coin ownership. It typically does not exist in physical form (like paper money) and is typically not issued by a central authority. Cryptocurrencies typically use decentralized control as opposed to centralized digital currency and central banking systems. When a known cryptocurrency is minted or created prior to issuance or issued by a single issuer, it is generally considered centralized. When implemented with decentralized control, each cryptocurrency works through distributed ledger technology, typically a blockchain, that serves as a public financial transaction database.
David Chaum conceived an anonymous cryptographic electronic money called ecash and implemented it through Digicash, a form of cryptographic electronic payments which required user software in order to withdraw notes from a bank and designate specific encrypted keys before it can be sent to a recipient. This allowed the digital currency to be untraceable by the issuing bank, the government, or any third party. Because it was linked to deposits, it is an example of a stablecoin, and was not intended to have a value decoupled from the regular economy. In 1996, the National Security Agency published a paper entitled How to Make a Mint: the Cryptography of Anonymous Electronic Cash, describing a Cryptocurrency system, first publishing it in an MIT mailing list and later in 1997, in The American Law Review (Vol. 16, Issue D). See, en.wikipedia.org/wiki/Cryptocurrency. In 1998. Wei Dai published a description of “b-money”, characterized as an anonymous, distributed electronic cash system. Shortly thereafter, Nick Szabo described bit gold. Like bitcoin and other cryptocurrencies that would follow it, bit gold was described as an electronic currency system which required users to complete a proof of work function with solutions being cryptographically put together and published.
According to Jan Lansky, a cryptocurrency is a system that meets six conditions: The system does not require a central authority; its state is maintained through distributed consensus. The system keeps an overview of cryptocurrency units and their ownership. The system defines whether new cryptocurrency units can be created. If new cryptocurrency units can be created, the system defines the circumstances of their origin and how to determine the ownership of these new units. Ownership of cryptocurrency units can be proved exclusively cryptographically. The system allows transactions to be performed in which ownership of the cryptographic units is changed. A transaction statement can only be issued by an entity proving the current ownership of these units. If two different instructions for changing the ownership of the same cryptographic units are simultaneously entered, the system performs at most one of them (with a rule present to determine which one is performed).
A blockchain account can provide functions other than making payments, for example in decentralized applications or smart contracts. In this case, the units or coins are sometimes referred to as crypto tokens (or cryptotokens). Cryptocurrencies are generally generated by their own blockchain like Bitcoin and Litecoin whereas tokens are usually issued within a smart contract running on top of a blockchain such as Ethereum.
Decentralized cryptocurrency is produced by the entire cryptocurrency system collectively, at a rate (or under some other constraint) which is defined. Within a cryptocurrency system, the safety, integrity and balance of ledgers is maintained by a community of mutually distrustful parties referred to as miners who use their computers to help validate and timestamp transactions, adding them to the ledger in accordance with a particular timestamping scheme. Most cryptocurrencies are designed to gradually decrease production of that currency, placing a cap on the total amount of that currency that will ever be in circulation.
The validity of each decentralized cryptocurrency's coins is typically provided by a blockchain. A blockchain is a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a hash pointer as a link to a previous block, a timestamp and transaction data. By design, blockchains are inherently resistant to modification of the data. It is “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way”. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks which requires collusion of the network majority.
Blockchains are secure by design and are an example of a distributed computing system with high Byzantine fault tolerance. Decentralized consensus has therefore been achieved with a blockchain. (Note that one aspect of the present invention is to reconsider the consensus rules, such that consensus alone would not necessarily produce retroactive changes however, a cryptocurrency must have mutually acceptable characteristics between parties to a transaction, and a liquid cryptocurrency requires a large pool of parties. Therefore, while a majority consensus may be abrogated, some form of consensus is required for a stable and valuable cryptocurrency). Cryptocurrencies use various timestamping schemes to “prove” the validity of transactions added to the blockchain ledger without the need for a trusted third party. The first timestamping scheme invented was the proof-of-work scheme. The most widely used proof-of-work schemes are based on SHA-256 and scrypt. Some other hashing algorithms that are used for proof-of-work include CryptoNight. Blake, SHA-3, and X11. The proof-of-stake is a method of securing a cryptocurrency network and achieving distributed consensus through requesting users to show ownership of a certain amount of currency. It is different from proof-of-work systems that run difficult hashing algorithms to validate electronic transactions. The scheme is largely dependent on the coin, and there's currently no standard form of it. Some cryptocurrencies use a combined proof-of-work and proof-of-stake scheme. (The proof of stake is an interesting option for negative valued tokens, since the required proof of stake at least temporarily deanonymizes the token holder, but creates a game theoretic competing incentive for the outed stake holder to minimize the amount of liability represented).
In various cryptocurrency networks, mining is a validation of transactions. For this effort, successful miners may obtain new cryptocurrency as a reward. The reward decreases transaction fees by creating a complementary incentive to contribute to the processing power of the network. The rate of generating hashes, which validate any transaction, has been increased by the use of specialized machines such as FPGAs and ASIGs running complex hashing algorithms like SHA-256 and scrypt. Some miners pool resources, sharing their processing power over a network to split the reward equally, according to the amount of work they contributed to the probability of finding a block A “share” is awarded to members of the mining pool who present a valid partial proof-of-work. (The existence of such pools represents a collusion, and has negative implications for security of a strict consensus-based model). Proof-of-work cryptocurrencies, such as bitcoin, offer block rewards incentives for miners. There has been an implicit belief that whether miners are paid by block rewards or transaction fees does not affect the security of the blockchain, but a study suggests that this may not be the case under certain circumstances.
A cryptocurrency wallet stores the public and private “keys” or “addresses” which can be used to receive or spend the cryptocurrency. With the private key, it is possible to write in the public ledger, effectively spending the associated cryptocurrency. With the public key, it is possible for others to send currency to the wallet.
Bitcoin is pseudonymous rather than anonymous in that the cryptocurrency within a wallet is not tied to people, but rather to one or more specific keys (or “addresses”). Thereby, bitcoin owners are not identifiable, but all transactions are publicly available in the blockchain. Still, cryptocurrency exchanges are often required by law to collect the personal information of their users. Additions such as Zerocoin, Zerocash and CryptoNote have been suggested, which would allow for additional anonymity and fungibility. Most cryptocurrency tokens are fungible and interchangeable. However, unique non-fungible tokens also exist. Such tokens can serve as assets in games like Cryptokitties.
The rewards paid to miners, e.g., in a proof of work distributed consensus mechanism, increase the supply of the cryptocurrency. By making sure that verifying transactions is a costly business the integrity of the network can be preserved as long as benevolent nodes control a majority of computing power. The verification algorithm requires a lot of processing power, and thus electricity in order to make verification costly enough to accurately validate public blockchain. The current value, not the long-term value, of the cryptocurrency supports the reward scheme to incentivize miners to engage in costly mining activities. Some sources claim that the current bitcoin design is very inefficient, generating a welfare loss of 1.1% relative to an efficient cash system. The main source for this inefficiency is the large mining cost. This translates into users being willing to accept a cash system with an inflation rate of 230% before being better off using bitcoin as a means of payment. However, the efficiency of the bitcoin system can be significantly improved by optimizing the rate of coin creation and minimizing transaction fees. Another potential improvement is to eliminate inefficient mining activities by changing the consensus protocol altogether.
Transaction fees for cryptocurrency depend mainly on the supply of network capacity at the time, versus the demand from the currency holder for a faster transaction. The currency holder can choose a specific transaction fee, while network entities process transactions in order of highest offered fee to lowest. Cryptocurrency exchanges can simplify the process for currency holders by offering priority alternatives and thereby determine which fee will likely cause the transaction to be processed in the requested time. For ether, transaction fees differ by computational complexity, bandwidth use, and storage needs, while bitcoin transaction fees differ by transaction size and whether the transaction uses SegWit. Some cryptocurrencies have no transaction fees and instead rely on client-side proof-of-work as the transaction prioritization and anti-spam mechanism.
Cryptocurrency exchanges allow customers to trade cryptocurrencies for other assets, such as conventional fiat money, or to trade between different digital currencies Atomic swaps are a mechanism where one cryptocurrency can be exchanged directly for another cryptocurrency, without the need for a trusted third party such as an exchange.
An initial coin offering (100) is a controversial means of raising funds for a new cryptocurrency venture. An 100 may be used by startups with the intention of avoiding regulation. However, securities regulators in many jurisdictions, including in the U.S., and Canada, have indicated that if a coin or token is an “investment contract” (e.g., under the Howey test, i.e., an investment of money with a reasonable expectation of profit based significantly on the entrepreneurial or managerial efforts of others), it is a security and is subject to securities regulation. In an 100 campaign, a percentage of the cryptocurrency (usually in the form of “tokens”) is sold to early backers of the project in exchange for legal tender or other cryptocurrencies, often bitcoin or ether. Cryptocurrency networks display a lack of regulation that has been criticized as enabling criminals who seek to evade taxes and launder money. Money laundering issues are also present in regular bank transfers, however with bank-to-bank wire transfers for instance, the account holder must at least provide a proven identity. Transactions that occur through the use and exchange of these altcoins are independent from formal banking systems, and therefore can make tax evasion simpler for individuals. Since charting taxable income is based upon what a recipient reports to the revenue service, it becomes extremely difficult to account for transactions made using existing cryptocurrencies, a mode of exchange that is complex and difficult to track. Systems of anonymity that most cryptocurrencies offer can also serve as a simpler means to launder money. Rather than laundering money through an intricate net of financial actors and offshore bank accounts, laundering money through altcoins can be achieved through anonymous transactions.
A particular problem of cryptocurrencies prior to Bitcoin is that, without a central ledger, the payee couldn't verify that one of the owners did not double-spend the coin. A common solution was therefore to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin (or the coin transfer logged and associated with a new owner), and only coins issued (or reissued) directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the entity running the mint, with every transaction having to go through them, just like a bank.
When the token is negative valued, the recipient in a transaction accepts the token as an expression of an obligation to pay a third party. “Double spending” does not occur in the same sense, since that would mean that the holder satisfied the debt multiple times, though in case the holder has multiple claimants seeking repayment, the issue is to whom and by whom is the debt owed?
The double payment issue in Bitcoin provides a way for the payee to know that the previous owners did not sign any earlier transactions. The earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint-based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [Dai Wei, “b-money”. (1998-11-01) www.weidai.com/bmoney.txt], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.
A timestamp server is provided, that works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [Henri Massias, Xavier Serret-Avila, Jean-Jacques Quisquater. “Design of a secure timestamping service with minimal trust requirements”, 20th Symposium on Information Theory in the Benelux (1999-05) citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.6228; Stuart Haber, W. Scott Stornetta, “How to time-stamp a digital document”. Journal of Cryptology (1991) doi.org/cwwxd4, DOI: 10.1007/bf00196791; Dave Bayer, Stuart Haber, W. Scott Stornetta, “Improving the Efficiency and Reliability of Digital Time-Stamping”, Sequences II (1993) doi.org/bn4rpx. DOI: 10.1007/978-1-1613-9323-8_24; Stuart Haber, W. Scott Stornetta, “Secure names for bit-strings”, Proceedings of the 1th ACM conference on Computer and communications security-CCS '97 (1997) doi.org/dtnrf6, DOI: 10.1145/266420.266430]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.
To implement a distributed timestamp server on a peer-to-peer basis, a proof-of-work system similar to Adam Back's Hashcash [Adam Back, “Hashcash-A Denial of Service Counter-Measure”, (2002-08-01) citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.8] was proposed, rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For the Bitcoin timestamp network, the proof-of-work is implemented by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.
The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. Satoshi concluded that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added, though this is only true if the computational power available per CPU is equal and constant over time.
To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases. However, this does not address the difficulty of previously committed blocks of the blockchain.
The steps to run the network are as follows
Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer, the nodes that were working on the other branch will then switch to the longer one. This, of course, exposes the risk that a first node with exponentially greater computational capacity might publish two blocks before other nodes publish one, in which case the chain from the first node is longer. If the intermediate node is corrupted, then the chain may be corrupted, and detecting the corruption and catching up by the other nodes may be difficult. Therefore, the security of the network over time is dependent on continued investment by participants to ensure computational parity and lack of domination by any one party. New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one. However, the ability of the Bitcoin community to tolerate distributed denial of service attacked is not well studied.
By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. So long as the incentive to mine persists, so does the incentive to forge the first transaction. Likewise, if the reward is a debt, there is no incentive to mine, and an active disincentive to do so, meaning that this type of incentive is inoperative for negative valued tokens.
Bitcoin can also incentivize mining with transaction fees. This could be modified for negative valued token, since the miner could transfer a token representing debt to a participant in a transaction to be recorded on the blockchain. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of Bitcoins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
The incentive may help encourage Bitcoin network nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules such rules that favor him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. The optimal incentive for an economy according to an inverse paradigm, with a negative valued token, are less readily ascertained.
Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save storage space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [Massias et al., Haber et al., Ralph C. Merkle, “Protocols for Public Key Cryptosystems”, 1980 IEEE Symposium on Security and Privacy (1980-01) doi.org/bmvbd6. DOI: 10.1109/sp.1980.10006], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. However, this exposes a risk that if a majority of nodes are “fooled” by a sequence of fraudulent blocks, the evidence may be generally purged according to the normal operation of implementing code. A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes 80 bytes*6*24*365=1.2 MB per year. With computer systems typically selling with 2 GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2 GB per year, storage should not be a problem even if the block headers must be kept in memory.
It is possible to verify Bitcoin payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. In the case of a debt or obligation, the party to whom the debt is owed (the “creditor”) does not necessarily know who owes the debt (the “debtor”), since the token-holder may remain anonymous. Presumably, that creditor would know if the obligation has been satisfied, and the prior token holder (prior debtor) would have an ability to retain proof of satisfaction. Note that the creditor itself holds an asset, that can be represented as a positive valued token, but this is different and distinct from the negative-valued token held by the debtor.
As such, the Bitcoin transaction verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. This, trust in an intermediary is replaced with trust in consensus. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent Bitcoin payments would probably still want to run their own nodes for more independent security and quicker verification. At present, transaction processing (mining) is typically by separate entities than commercial transaction consummation, and therefore the advice has not been heeded. In short, the risks of merchants relying on the Bitcoin miners far exceed the reward of a respective miner in performing its task, and merchants have generally avoided reasonable steps to mitigate the inherent risks.
Although it would be possible to handle Bitcoins individually, it would be unwieldy to make a separate transaction for every cent (e.g., Satoshi) in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs one for the payment, and one returning the change, if any, back to the sender. It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a particular Bitcoin problem. There is never the need to extract a complete standalone copy of a Bitcoin transaction's history.
The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the “tape”, is made public, but without telling who the parties were.
As an additional firewall, a new key pair should be used for each Bitcoin transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. The analogous privacy issues arise with respect to negative valued tokens.
Consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not normally going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them, assuming that this is detectable and steps are in place to actually detect the issue. An attacker might try also to change one of his own transactions to take back money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by −1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [William Feller, “An Introduction to Probability Theory and its Applications”, John Wiley & Sons (1957), archive.org/details/AnIntroductionToProbabilityTheoryAndItsApplicationsVolumel]:
Given the assumption that p>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases (subject to presumptions about commensurate computational power and lack of collusion). With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. Assume the Bitcoin sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.
The Bitcoin receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and s blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value: λ=zq/p.
To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point:
Rearranging to avoid summing the infinite tail of the distribution . . .
Bitcoin provides a system for electronic transactions without relying on trust. Bitcoins are made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, a peer-to-peer network using proof-of-work is used to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.
System security derives from “proof or work”, though an alternate “proof of stake” is also deemed feasible.
Cap, Clemens H. “A structural analysis of Bitcoin.” INFORMATIK 2012 (2012) discusses a more rigorous analysis of Bitcoin, and proposes enhancements. In Bitcoin, participants issue transactions to change their local state and broadcast transactions to other participants using gossiping [Patrick Eugster, Pascal Felber, and Fabrice Le Fessant. The “art” of programming gossip-based systems. SIGOPS Oper. Syst. Rev., 41(5):37-12, October 2007.]: A node does not send its transactions to all other participants but only to a subset to which it is connected; recipients forward received transactions to their own peers unless they already knew the received transaction themselves. Broadcast is not reliable (i.e., a number of transactions may not be delivered to a number of nodes) and not ordered (i.e., the sequence in which transactions are received may differ from node to node and from the sequence in which they were sent). This is consistent with the failure model of Bitcoin, where a number of Byzantine (Byzantine failure mode assumes that a node may exhibit completely arbitrary, random, even malicious behavior) nodes may exhibit completely arbitrary or malicious behavior, and with the state of the art in totally ordered broadcast [Xavier Defago, Andre Schiper, and Peter Urban. Total order broadcast and multicast algorithms Taxonomy and survey. ACM Comput. Surv., 36(4):372-121, December 2004.] (impossible in asynchronous models with crash failures, difficult in Byzantine settings or without additional assumptions, such as channel reliability or trustworthy supernodes [Benjamin Reed and Flavio P. Junqueira. A simple totally ordered broadcast protocol. In Proceedings of the 2nd workshop on large-scale distributed systems and middleware, LADIS '08, pages 2:1-2:6, New York, NY, USA, 2008. ACM.], scaling badly if these assumptions are dropped).
This produces problems A node may receive transaction t2 in a state where it cannot be applied (e.g., one node generates a bank account by t1 and then references it in t; a different node receives t2 before t1). In spite of unreliable broadcast, every transaction should eventually be recognized by every node. If asked for their current state, different participants may report different states: There is no notion of global time and no mechanism to have the participants report their state at the “same” time. The sequence of states seen by a participant may depend on the participant. All this is due to the following reasons:
Latency: Some participants have not yet received all issued transactions or have not yet applied them for updating their local state.
Unreliable Broadcast: Some participants did not receive a transaction.
Order of Transactions Two participants X and Y may have seen two transactions t, and to in a different order. This may produce three conceptually different effects Same final state, different path; Different final states; Different sequence.
Byzantine Failures Participants misbehave, by bad intent or by malfunction. They send different transactions to some participants, tricking them into inconsistent states.
Network Partitioning may happen without the participants noticing. This produces several connected components, each of which is unaware of the transactions taking place in the other components.
Applications impose consistency criteria on the states of the participants.
Bitcoin takes a fresh approach. It rejects the idea of trust in a single entity. It assumes a (very) large number of participants (˜106), which kills traditional serialization approaches. Furthermore, Bitcoin does not require a common code base: Every node exchanges messages with other nodes, and it is by a probabilistic game theoretic incentive that the swarm seems to pursue a common goal, which, hopefully, attracts a sufficient number of cooperative nodes, which only in turn guarantee the incentive, which was the reason to participate. In this sense, Bitcoin is a self-organized, emergent and (hopefully) self-stabilizing network of communicating nodes.
In the Bitcoin community, a more traditional, governed understanding is prevailing: A network of peer-to-peer nodes, running in their vast majority a recent version of the official Bitcoin software. A few nodes may deviate from the “official” behavior, which is tolerated by the probabilistic consensus as long as only a minority engages in counter-specification behavior. In Bitcoin, minority does not refer to numbers of participants but computing power, as demonstrated by a proof-of-work mechanism.
This more traditional interpretation may be due to social, economic and psychological effects: The active member of the community invests time, money (for running nodes) and entrepreneurial expectations. This is easier, if it is based on a belief in a stable system, well-governed by a solid architecture and endangered only by a small minority of malign attackers. This belief might be an appropriate (and stabilizing) social model; from a structural point of view, however, Bitcoin is an anarchic network of interacting but completely autonomous nodes, whose seemingly goal-directed behavior emerges from advantages the participants expect from their predictions on the average behavior of a majority of nodes.
Network partitioning is dealt with by assuming that in contemporary Internet a long-term partitioning into disconnected components will not go unnoticed by the participants and by hiding conflict resolution upon rejoining in the resilience properties against malicious minorities. Byzantine failures and unreliable communication are dealt with in a statistical manner; the algorithm aims that states of nodes eventually converge to a consistent world view. To guarantee such a common limit for all participants is the task of the Bitcoin algorithm: After a while all participants should have agreed on a common past (and on the produced states); the moment might be earlier or later, depending on the communication latency.
The incentive mechanism suggests modeling Bitcoin by game theory [James N. Webb. Game Theory: Decisions, Interaction and Evolution. Springer, 2006.]: A certain (large) number of participants is playing a repeated number of rounds. In every round, a participant may choose between a number of options, which in Bitcoin correspond to sending messages of a specific content to other participants. Since Bitcoin is not operating in synchronized rounds and with a fixed number of nodes, not sending a message is an option. The random nature of a proof-of-work may be reflected by mixed strategies and by placing constraints on the respective probabilities. From this perspective, a node decides between sending a correctly found new block (with a probability constrained by its hash performance), not sending a message, or sending an incorrect block. According to game theory, the goal of a node is to select its behavior in such a manner as to maximize the payoff in the game. Unfortunately, there are serious problems with this approach. In repeated games, the payoff often is obtained by summing the payoffs of all rounds. However, in Bitcoin a payoff is not connected with a single round, but evolves over time and retains a stochastic nature.
For example, an attacker might double spend to two different Bitcoin exchanges and subsequently ask them to convert his Bitcoins into Dollars. There is a certain probability that the attack succeeds and both exchanges will pay the appropriate amount in Dollar before realizing the attack by a block chain reorganization. This probability depends on the confirmation policy of the exchanges. Thus, the payoff depends on a large number of events, corresponding to many rounds in the game. Even worse, the probability that a Bitcoin transaction will be undone and the block chain will reorganize never becomes zero. The payoff becomes certain only when a participant finally crosses the boundary from digital (Bitcoin) to real (Dollar) economy. It is generally believed that this probability is so small that the impact can be neglected for practical purposes. However, when in search of a modeling tool which is able to rigorously prove this property we must not base the choice of the tool on the assumption we want to prove.
A more suitable tool might be a random walk, where the length of the walk provides a measure for the probability of reverting a transaction. This is the method chosen by Satoshi in the Bitcoin white paper. The approach assumes that a majority of nodes will adhere to the “official” Bitcoin protocol. It then argues in that a minority of nodes, which deviate from the official protocol, will not be able to damage the incentive, which is produced by the “official” protocol. This observation is important, since it guarantees Bitcoin stability of a convinced majority against a malevolent minority. However, for a completely decentralized system, this is not enough. There is no authority ensuring a majority or even a notion of an “official” protocol version. Every participant is free to switch to a modified protocol: he will switch, if this increases his payoff. The assumption, that a majority of nodes will stick to the “official” protocol is not accounted for or, in other versions of the debate, is explained (using circular reasoning) by referring to the incentive generated by the “official” protocol. The reasoning does not explain why a majority of nodes would want to stick to the “official” or any other currently used version of the protocol. The inherent dynamics of the protocol with regard to bounty-size and difficulty, as well as the growing interest by the open source community, is likely to further drive this issue by suggestions of new protocol variants. Both theories, game theory and random walks assume a behavior where nodes attempt to maximize their profit.
Heard-of Byzantine consensus lets the swarm chose “correct” behavior by a one-identity-one-vote scheme and is susceptible to sybil attacks. Proof-of-work improves this by counting the votes according to node hash performance. Proof-of-stake counts the votes according to the stake a node currently has in the Bitcoin system. The latter may be defined by the bounty acquired through past mining activities or by the total wealth currently held. When social aspects are a core aspect in Bitcoin stability, stake measured in real economic units might prove more important that hash performance.
According to the blockchain principle, rights are immutably stored on a ledger which may be distributed, and control over rights is provable by a claimant by possession of a cryptographic key. The immutability is a result of the consensus processing of a subsequent block, which depends on the prior block(s), and thus the accepted subsequent block constrains the entire chain of preceding blocks. If the consensus fails, there may be two subsequent blocks, each dependent on the prior chain, which is terms a fork. Forks may be intentionally created, or develop as a result of isolation of subsets.
Because an affirmative claim over a right represented in the blockchain is required, typically based on possession of a private (secret) key, an “owner” of a right recorded on a blockchain may deny ownership or simply refuse to be unmasked. For example, the entity behind the pseudonym “Satoshi Nakamoto”, apparent inventor of Bitcoin, remains unknown, even though various claimants have alleged ownership, but without presentation of the private key that would prove identity, or at least chain of ownership. Further, per various accounts, even accidental loss of the key can result in irretrievable rights.
Therefore, the structure of the existing blockchain for recording, managing and transferring tokenized rights is dependent on a positive value of the right embodied in the record, and therefore a positive demand for its value. On the other hand, absent an incentive to claim a record, i.e., a negative economic value, the blockchain is suboptimal for tokenized liabilities.
A tokenized liability can be thought of, in one sense as the flip side of a tokenized right, though the incentives and constraints are vastly different, and as a result, the network dynamics of a blockchain would typically be destined for failure when employed for negative value tokens, e.g., liabilities.
For example, in the Bitcoin network, processing of blocks is incentivized by award of new tokens to “miners”. Who would participate as a miner if the result was increased liability?
Inverting the stakes for miners would turn proof of work into proof of laziness, or proof of stake to proof of irrelevance. While alternate antitheses might be elaborated, in general. The logic and rules for such an infrastructure have not been presented in the body of work involving cryptocurrencies and smart contracts. In a smart contract, rights and obligations are coupled; however, enforcement of liabilities is typically automated, i.e., the obligation is an integral part of the smart contract, secured within the system, without volitional compliance.
On the other hand, one could imagine an inverted system in which “mining” blocks verifiably consumes tokens, and as a result, reduces liability, resulting in gain to the party who performs the “mining”. Similarly, other mechanisms for reliable processing of blocks may be provided, for example by linking to another chain, transaction fees, or the like.
Likewise, in real economic transactions, each counterparty to the transaction provides “consideration” and thus transfers value to the other. Consider an exchange of a Bitcoin (BTC) for a corresponding amount of Bitcoin Cash (BCH). In the proposed transaction, there is presumably a paired transfer, but in actuality, each party is exposed to risk because only the acquisition of the “valuable” tokenized right is protected, while the counter-transaction (a liability) is not integrally coupled, and the fact that in the hypothetical, the liability is tokenized, is irrelevant. One solution is use of an escrow, but this requires a trusted intermediary.
Sidney Powell, “DeFi 2025 Unsecured Crypto Loans” (Jun. 17, 2019), medium.com/swlh/defi-2025-unsecured-crypto-loans-c54262507cc9, and Sidney Powell, “Crypto Lending-The Missing Ingredient” (Jun. 10, 2019) medium.com/swlh/crypto-lending-the-missing-ingredient-1862454cdf53 discusses crypto loans and unsecured crypto liabilities. Powell states that in 2018 and early 2019 an explosion in activity in the decentralized finance space (aka “DeFi” or “Open Finance”) occurred, focusing on the lending segment within DeFi: this space comprises decentralized applications on which users can borrow cryptocurrency through smart contracts which are recorded on the Ethereum blockchain. The space opened up with the launch of Maker in December 2017 which allows users to borrow Dai stablecoin by staking Ether (ETH) as collateral for the loan and paying interest (referred to as the Stability Fee) in Maker's native token, MKR. Maker is offering a margin loan product in which borrowers provide security which is larger than the amount of money they want to borrow. If the borrower refuses to repay the loan then their security is liquidated to repay the loan. This form of lending depends on the security value remaining greater than the balance of the loan and with a buffer to ensure that if the asset has to be sold quickly in a distressed market, any decline in price can be absorbed without the loan being underwater. To ensure this is the case, borrowers are able to top up their security position by sending more ETH to the address of the smart contract managing the loan.
The margin loan product is particularly well suited to cryptocurrency lending because the overcollateralization makes enforcement in cases of default simple and automatic, there is no requirement to link an on-chain address to an off-chain identity for the purpose of collecting bad debts or taking security over a real-world asset like a car. The key roadblock to unsecured and under-collateralized crypto-loans is that enforcement must pierce the pseudonymity veil to access either a real-world identity or assets. A fraudulent borrower who defaults on an unsecured crypto-loan must be able to be blacklisted from future access to credit in a way that cannot easily be circumvented by creating a new wallet address. The problem for unsecured lending is that a lender faces only an address and cannot verify that the borrower on the other side of that address will not take out a loan, disappear and then create a new address to repeat the process. There are two perspectives on how to solve this identity verification, and gamification of the loan product. Identity verification would see borrowers required to submit to a full Know Your Customer (KYC) check to link the wallet address to a real identity that can't be duplicated. If that address defaulted, the identity could be blacklisted in a database accessible to any crypto-loan provider, and the requirement for any unsecured borrower to match their wallet address to an identity would prevent that borrower from just creating a new address and taking out a new loan. Presently, there are a number of projects working on KYC solutions in which a user's information (e.g., passport, address date of birth, driver's license) is stored in a decentralized manner and they retain control over access to that information. A solution here which can plug into DeFi is still a long way off as there would also need to be a publicly queryable blacklist of defaulted borrowers to ensure that a borrower could not perpetrate the same fraud across multiple crypto-loan providers.
The second avenue, gamifying crypto loan products to disincentivize fraud, is nascent. This approach could take several novel forms, including a bounty for good behavior, referrals or staking reputation points for related addresses. While the identity verification approach aims to remove the potential for fraudulent actors to hide behind multiple wallet addresses, the gamification approach aims to set up incentives so that fraud is removed or minimized without removing the pseudonymity of wallet addresses. A user could have multiple addresses borrowing from the same platform but would choose to perform because of the threat of punishment for bad behavior or possibility of reward for good behavior outweighs the benefit of fraud, all without having to link their addresses to a real-world identity. Gamification, sought to structure incentives so that borrowers would voluntarily choose not to exit scam lenders. Gamification could at best defer an exit scam rather than prevent it altogether as long as the possibility remained for one user to control all addresses on the system.
Lenders using DeFi platforms to provide loans to customers need a source of funding. In the traditional financial system. Lenders borrow by issuing bonds to investors which are secured by a portfolio of loans. There is currently no way to do this on blockchain but there will need to be a solution for Lenders to raise funding on-chain to meet the coming wave of borrower demand for loans. This will be the beginning of the crypto-bond market, with bonds at-first secured by crypto-assets. The first crypto-assets beyond Ether or stablecoins to be used as collateral will be revenue-generating ones because the revenues can service the interest repayments. Crypto loans are an obvious example, but other options may include content rights, for example, a writer running an online publication with a subscriber base (paying in stablecoin) could borrow against future subscription fees by redirecting those fees to an escrow smart contract which repays bond investors.
Borrowing using an on-chain margin loan with Maker was easy; a borrower would lock up Ether as collateral and borrow in stablecoin (Dai on Maker). As long as the value of the locked Ether stayed above 150% of the loan balance the borrower would not be margin called. If it dropped below this threshold or the borrower defaulted, the locked Ether would be liquidated to repay the loan, ensuring that the Lender suffered no credit loss. Whilst margin loans had taken off, unsecured crypto loans were a different matter because of the vulnerability to fraudulent borrowers. A borrower who didn't have to supply at least 100% of the loan amount as collateral would always have some incentive to disappear with the loan. The threat of barring access to future finance would be a sufficient deterrent to most, however, the ability of malicious borrowers to easily create new pseudonymous addresses to repeat the process without detection meant that malicious actors could not be effectively blacklisted. In a worst-case scenario, a malicious user could create hundreds of fake addresses, take out loans and then proceed to default on all of them simultaneously, known as a Sybil Attack. As long as a given user could create multiple addresses which could not be traced back to them then unsecured crypto loans would be vulnerable to Sybil Attacks.
Know your customer (KYC) solutions attempted to replicate the inefficient process which had been applied as a norm in the 1990s when the web was still in its infancy. It was assumed that the process of importing the stock standard KYC process on-chain was worthwhile because it was an inherited norm endorsed in a number of jurisdictions. Proposed solutions involved photographing physical identification documents (often accompanied by handwritten notes to act as a timestamp), verifying them, and then encrypting and storing these in a decentralized manner to be shared at the user's discretion with third parties performing KYC checks, i.e., crypto lenders. Seeking to import the inefficient process on-chain threw up challenges who had custody of the digital copies could they be stored securely, could someone else's verification process by relied on by third parties and KYC standards differed across jurisdictions. Furthermore, many of the unbanked without government issued documentation who stood to benefit most would be shut off from access Thus, the DeFi space considered importing fees middle men, centralization and existing financial structures to solve the corresponding problems to those of non-crypto finance.
Meanwhile, the cost of biometric sensors was dropping, and many smartphones came with fingerprint recognition and cameras suitable for iris scanning. The same way that smartphone GPS birthed the ridesharing industry, smartphone biometrics held the key to DeFi's identity problem. Verified GPS geolocation coordinates can also assist in authentication. The community had been trying to reverse engineer a solution to pull an outmoded identity verification process into the future of finance, not unlike building a hyperloop for the horse-and-carriage. However, reduced to its most basic form, the problem lay in proving that a given address could not be one of many controlled by a single person. The solution could be inverted as a question of whether a method could be devised in which a person could take an unalterable piece of information unique to them and use it to create an address. The answer lay at the intersection of biometrics and cryptography.
Helium also developed a proof of location protocol. See, Amir Haleem, Andrew Allen, Andrew Thompson, Marc Nijdam, and Rahul Garg, “Helium: A Decentralized Machine Network” Whitepaper (2018-11-14).
Developers had started with the assumption that all addresses were created equal. There was one class of Externally Owned Accounts which were controlled by private key. Externally Owned Accounts triggered all activity with Contract Accounts on the Ethereum blockchain. Developers soon turned their attention to combining biometrics with cryptography. Working with teams of biochemists and cryptographers, they created the Biometrically Owned Account (BOA), a new class of Account in which the key pair was generated from the user's biometric signature. To enroll for a BOA, a user took their iris scan using a smartphone, then it was run through an open source algorithm to hash the biometric signature's binary code to generate a key and address.
The exact same address would be generated each time, giving an enrolling user only one possible Ethereum address. If a different encoding algorithm were used then a different address would result, hence it was important that all DeFi lenders adopted the same standard. The user's identity could not be reversed out of the address using the same open source algorithm, preserving privacy. Acknowledging users' desires not to have their financial activity commingled with other on-chain activity, other industries adopted different open source encryption algorithms so that a user could have different BOAs for different purposes—health, social media, finance etc.
Any person with access to a biometric-enabled smartphone could now create a unique address with their biometric signature, but only once, preventing Sybil fraud. The BOA became the ticket to accessing previously unavailable financial products. The global financial system was becoming flatter. As the BOA was the most effective means of lenders preventing a Sybil Attack, only users with a BOA address could apply for undercollateralized loans. Many crypto lenders emerged to meet the untapped demand for under-secured crypto loans as the total addressable market was orders of magnitude larger than the market for margin loans. Defaulting borrowers would lose access to DeFi loans through their BOA while the default remained unpaid. Of course, this didn't eliminate fraud entirely, there were still edge cases where BOAs were taken out for other people and window-dressed to appear legitimate. By-and-large however, the wholesale fraud people expected to engulf a pseudonymous system of borrowing never materialized because most people who wanted access wanted to reuse the product. While the advent of undercollateralized crypto loans and BOAs transformed access to finance, the precepts of underwriting remained the same. Lenders still needed to consider the borrower's ability to repay when underwriting. With a digital native financial product, it only made sense that credit assessment use digital native evidence. Lenders paid most attention to:
Early adopters of the undercollateralized crypto loan were blockchain developers because they were already highly integrated with the on-chain economy. They were more likely to freelance on projects for multiple employers, were paid in cryptocurrency and were able to demonstrate a long track record of income to service loans. Underwriters would scrape their BOA's transaction history and provide approval and funds within minutes. A loan token would also be transferred to the BOA which contained the schedule of payments to demonstrate whether an account was overdue or not. Borrowers who repaid on time would receive access to better future loan terms.
Thus some thought has been invested in the problem of addressing liabilities represented in cryptographic token/currencies, extending to the unsecured model.
Drainville, Danielle. “An analysis of the Bitcoin electronic cash system.” Univ. Waterloo 15 (2012), discusses Bitcoin. Bitcoin is a decentralized peer-to-peer network. It was introduced on Nov. 1, 2008 in a paper by the pseudonymous Satoshi Nakamoto [Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Unpublished, Nov. 1, 2008. www.bitcoin.org; Buterin, V. Bitcoin: Prehistory, Predecessors and Genesis. Bitcoin Magazine, 1:14-18. May 2012]. Unlike paper cash or electronic cash, Bitcoin does not rely on a central authority like the government or a bank. Instead, it relies on a proof-of-work system to verify and authenticate transactions, which are also made public for further verification. This new form of currency is also unique in that the number of coins in circulation will increase in a pre-determined way until the goal of 21 million coins in circulation is reached sometime in the year 2140 [Barber. S., Boyen, X., Shi, E, and Uzun, E. Bitter to Better—How to Make Bitcoin a Better Currency. 16th International Conference on Financial Cryptography and Data Security. Lecture Notes in Computer Science, 7397:399-414, 2012.]. Bitcoin is a peer-to-peer based electronic cash system that does not make use of a central authority. In the Bitcoin network, each node represents one of potentially many public keys belonging to a Bitcoin user, and communicates directly with each other node. All the information is made public for every user to see. Also, decisions are made through a majority vote. In Bitcoin, “voting” is primarily done by working with previous transactions and blocks.
A Bitcoin (BTC) can be thought of as a chain of digital signatures. When sending a coin from one user to another, the previous transaction in which this coin was used is hashed together with the recipient's public key, to then be signed by the sender. This hash and signature are then added to the end of the coin chain. Since the sender's public key is included in the previous transaction for the coin in question, any user can use it to verify the validity of the subsequent signature: see
To prevent a malicious user from double-spending a coin, some form of timestamping needs to be done. This leads to the proof-of-work (PoW) process which uses a reward system to motivate users, as well as generate new coins.
Proof-of-work is essentially taking the hash of a block of items and publishing this hash to the network. The items in question for the PoW block are transactions that need to be verified, the hash of the previous block, and a nonce. Since each block contains the hash of the previously generated block, the blocks form a chain of hash values as with transactions. The goal is to systematically increase the nonce so that the hash of the block that is currently being generated is less than a predetermined number given as targeted difficulty. This target is updated every 2016 blocks to ensure that the time it takes to generate a block is on average 10 minutes. This implies that the block cannot be altered without redoing all the work required to fi a nonce giving a valid hash, as well as the work required to generate all the subsequent blocks in the PoW chain. Users will accept a block if all the transactions contained in it are valid and if the coins have not been previously spent. They will show their acceptance of this block by using the newly found hash in the “previous hash” section of the next block they attempt to generate, thus adding a new block to the chain. This chain is called the block chain; see
Bitcoin users can generate new blocks or “mine”, using their computing power. The more computing power they possess the greater the chance of being the fi to win the race to block generation. As a reward for expending this power, successful users are rewarded with a predetermined amount of Bitcoins. This is also how coins are introduced to the system. The reward is set to decrease by half every 210 000 blocks. It starts at 50 BTC& then will decrease to 25 BTCs, followed by 12.5 BTCs, and so on until the predetermined cap of 21 million BTCs are in circulation by the year 2110. As a matter of fact, the reward recently reduced to 25 BTCs on Nov. 28, 2012. Certain transactions contain an incentive of a few BTCs that go to the user who generated the block verifying the transactions in question. As an added bonus for spending their computing power for mining, these incentives are added to the reward. Both the reward and the incentives are stored in the block implicating them, in what is called the coinbase. Once a block is generated, this creates a transaction from the coinbase to the successful miner. It should be noted that this is the only type of transaction that does not have a traditional input.
Since multiple users are attempting to generate blocks and obtain the reward, there is a possibility that two blocks are created around the same time thus creating a fork in the chain. It should be noted that users are not necessarily creating blocks verifying the same transactions. To remedy the fork, users will have a tendency to trust the prong with the highest level of difficulty, which usually happens to be the longest chain. The blocks that are not part of the longest chain are then dropped and the transactions they verified are put back in miners' memory pool. The chain in its entirety stems from the “genesis block”.
To ensure the security and validity of transactions, certain cryptographic primitives are used. For instance, the hash function used for both transactions and block generation is SHA-256 [FIPS 180-3. Secure Hash Standard, Federal Information Processing Standards Publication 180-3. National Institute of Standards and Technology, 2008.]. Also, the signature algorithm used is the elliptic curve digital signature algorithm (ECDSA) [Bitcoin Wiki: bitcoin.it/; FIPS 186-3. Digital Signature Standard. Federal Information Processing Standards Publication 186-3. National Institute of Standards and Technology, 2009.]. These are used to prevent a malicious user from breaking the system and gaining control of it. In this paper, the scheme is said to be broken if an attacker can impersonate other users by forging signatures or breaking the hash function and double-spending coins. The use of the hash function prevents malicious users from stealing and creating their own coins. This is due to the fact that they are protected by being hashed in a transaction, which is contained in a block, as well as with the added digital signature.
The way Bitcoin is designed implies that the last of the 21 million Bitcoins will be mined by the year 2140. This means that the cryptographic primitives used must remain secure until that time. Taking into consideration the growth of computer power over the past 10 years and the infamous Moore's Law, it is safe to assume that SHA-256 and ECDSA will be deemed insecure in that time frame. One of the more pressing concerns with cryptography nowadays is the pending arrival of large-scale quantum computers. Fortunately, the Bitcoin developers have mentioned a potential solution for this possibility. The hash function H used for the Bitcoin system is SHA-256 [FIPS 180-3. Secure Hash Standard, Federal Information Processing Standards Publication 180-3. National Institute of Standards and Technology. 2008.]. To prevent a malicious user from breaking the scheme, the function must satisfy all three cryptographic security requirements for hash functions, preimage resistance, second preimage resistance, and collision resistance. The signature algorithm used for validating transactions and confirming the identity of the payer is ECDSA [FIPS 186-3. Digital Signature Standard. Federal Information Processing Standards Publication 186-3. National Institute of Standards and Technology, 2009]. The elliptic curve used is secp256k1 from the SEC2 standard [Standards For Efficient Cryptography Group. SEC 2: Recommended Elliptic Curve Domain Parameters. p. 15. September 2000.]. This curve is a variation of the Koblitz curve.
Bitcoin is its own form of currency and payments are made directly from a user's wallet. Coins are represented by a long line of transactions, which can be found in the block chain. This implies the scheme is recognizable. The value associated to a coin is the value given to it by the Bitcoin community and virtual exchanges. To reduce the space requirement of the block chain, all transactions contained in a block can be compacted using a Merkle hash tree [Merkle, R. Protocols for Public key Cryptosystems, Proceedings of the 1980 IEEE Symposium on Security and Privacy. 122-131, 1980.]. It is also possible for users to store a portion of their wallet on their smartphone by simply downloading an application. This makes Bitcoin portable. The main feature of Bitcoin is that there is no central authority through which all transactions have to pass to be validated. Since there is no financial network, Bitcoin is transferable. Bitcoins are divisible. Bitcoins are unforgeable by design. The first thing a user in the network does when including a transaction in a block is verify the coin's history, as well as verify that the input value is greater than or equal to the output value. If either of these tests fail, it is determined that the payer is trying to send money that does not exist and the transaction is canceled.
Untraceability is not an intended feature of Bitcoin. By design, transactions are made widely public, thus implying that the path taken by coins can be traced from one address to another.
Anonymity is also not an intended security feature of Bitcoin. However, it is possible for a user to use their address as a pseudonym, use a different address per transaction and use mixers among other things to maintain some degree of anonymity. Reuse of the same address and tracing of token flows leak user identity.
Once a coin is spent, it is added to a block in the block chain. Therefore, if a malicious user were to double spend a coin, a miner would detect it. Also, Bitcoin prevents double-spending as long as the hash function and the signature algorithm are not broken. It must be noted that the Bitcoin system is only secure against double-spending in slow payment situations (situations where payments are left for an average of 10 minutes to be verified and added to the block chain before a good is delivered to the payer), as opposed to fast payment situations (situations where a good is delivered immediately).
Bitcoin also prevents a malicious user from spending coins that do not belong to her. This can be determined by comparing the receiving address in the previous transaction in which the coin in question was involved with the given public key. Also, if the transaction and signature do not coincide, it can be determined that the transaction has been tampered with.
A Bitcoin address is the hash of the elliptic curve public key, and not the public key itself. However, it is in fact perfectly legitimate cryptographic terminology to refer to the pubkey hash as a public key itself. This is because Bitcoin's cryptography can be considered to be a custom digital signature algorithm, where the public key consists of the hash of the ECC pubkey, the signature consists of the ECC pubkey concatenated with the BOC signature, and the verification algorithm involves checking the ECC pubkey in the signature against the ECC pubkey hash provided as a public key and then verifying the ECC signature against the ECC pubkey.
Vitalik Buterin, Ethereum White Paper, “A Next Generation Smart Contract & Decentralized Application Platform”, discusses the Etherium platform.
When Satoshi Nakamoto first set the Bitcoin blockchain into motion in January 2009, he was simultaneously introducing two radical and untested concepts. The first is the “bitcoin”, a decentralized peer-to-peer online currency that maintains a value without any backing, intrinsic value or central issuer. So far, the “bitcoin” as a currency unit has taken up the bulk of the public attention, both in terms of the political aspects of a currency without a central bank and its extreme upward and downward volatility in price. However, there is also another, equally important, part to Satoshi's grand experiment: the concept of a proof of work-based blockchain to allow for public agreement on the order of transactions. Bitcoin as an application can be described as a first-to-file system: if one entity has 50 BTC and simultaneously sends the same 50 BTC to A and to B, only the transaction that gets confirmed first will process There is no intrinsic way of determining from two transactions which came earlier, and for decades this stymied the development of decentralized digital currency. Satoshi's blockchain was the first credible decentralized solution. And now, attention is rapidly starting to shift toward this second part of Bitcoin's technology, and how the blockchain concept can be used for more than just money.
Commonly cited applications include using on-blockchain digital assets to represent custom currencies and financial instruments (“colored coins”), the ownership of an underlying physical device (“smart property”), non-fungible assets such as domain names (“Namecoin”) as well as more advanced applications such as decentralized exchange, financial derivatives, peer-to-peer gambling and on-blockchain identity and reputation systems. Another important area of inquiry is “smart contracts”-systems which automatically move digital assets according to arbitrary pre-specified rules. For example, one might have a treasury contract of the form “A can withdraw up to X currency units per day, B can withdraw up to Y per day, A and B together can withdraw anything, and A can shut off B's ability to withdraw”. The logical extension of this is decentralized autonomous organizations (DAOs)-long-term smart contracts that contain the assets and encode the bylaws of an entire organization. What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create “contracts” that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code.
The concept of decentralized digital currency, as well as alternative applications like property registries, has been around for decades. The anonymous e-cash protocols of the 1980s and the 1990s, mostly reliant on a cryptographic primitive known as Chaumian blinding, provided a currency with a high degree of privacy, but the protocols largely failed to gain traction because of their reliance on a centralized intermediary. In 1998, Wei Dai's b-money became the first proposal to introduce the idea of creating money through solving computational puzzles as well as decentralized consensus, but the proposal was scant on details as to how decentralized consensus could actually be implemented. In 2005, Hal Finney introduced a concept of “reusable proofs of work”, a system which uses ideas from b-money together with Adam Back's computationally difficult Hashcash puzzles to create a concept for a cryptocurrency, but once again fell short of the ideal by relying on trusted computing as a backend.
Because currency is a first-to-file application, where the order of transactions is often of critical importance, decentralized currencies require a solution to decentralized consensus. The main roadblock that all pre-Bitcoin currency protocols faced is the fact that, while there had been plenty of research on creating secure Byzantine-fault-tolerant multiparty consensus systems for many years, all of the protocols described were solving only half of the problem. The protocols assumed that all participants in the system were known, and produced security margins of the form “if N parties participate, then the system can tolerate up to N/4 malicious actors”. The problem is, however, that in an anonymous setting such security margins are vulnerable to sybil attacks, where a single attacker creates thousands of simulated nodes on a server or botnet and uses these nodes to unilaterally secure a majority share.
The innovation provided by Satoshi is the idea of combining a very simple decentralized consensus protocol, based on nodes combining transactions into a “block” every ten minutes creating an ever-growing blockchain, with proof of work as a mechanism through which nodes gain the right to participate in the system. While nodes with a large amount of computational power do have proportionately greater influence, coming up with more computational power than the entire network combined is much harder than simulating a million nodes. Despite the Bitcoin blockchain model's crudeness and simplicity, it has proven to be good enough, and would over the next five years become the bedrock of over two hundred currencies and protocols around the world.
From a technical standpoint, the Bitcoin ledger can be thought of as a state transition system, where there is a “state” consisting of the ownership status of all existing bitcoins and a “state transition function” that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move SX from A to B, and the state transition function reduces the value in A's account by SX and increases the value in B's account by SX. If A's account has less than SX in the first place, the state transition function returns an error. Hence, one can formally define:
In the banking system defined above:
But:
The “state” in Bitcoin is the collection of all coins (technically, “unspent transaction outputs” or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address and one or more outputs, with each output containing a new UTXO to be added to the state.
The state transition function APPLY(S,TN)→S′ can be defined roughly as follows:
The first half of the first step prevents transaction senders from spending coins that do not exist, the second half of the first step prevents transaction senders from spending other people's coins, and the second step enforces conservation of value.
In order to use this for payment, the protocol is as follows. Suppose Alice wants to send 11.7 BTC to Bob. First, Alice will look for a set of available UTXO that she owns that totals up to at least 11.7 BTC Realistically, Alice will not be able to get exactly 11.7 BTC; say that the smallest she can get is 6+4+2=12. She then creates a transaction with those three inputs and two outputs. The first output will be 11.7 BTC with Bob's address as its owner, and the second output will be the remaining 0.3 BTC “change”, with the owner being Alice herself.
If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called “blocks”. The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, “blockchain” that constantly updates to represent the latest state of the Bitcoin ledger.
The algorithm for checking if a block is valid, expressed in this paradigm, is as follows:
Essentially, each transaction in the block must provide a state transition that is valid. Note that the state is not encoded in the block in any way; it is purely an abstraction to be remembered by the validating node and can only be (securely) computed for any block by starting from the genesis state and sequentially applying every transaction in every block. Additionally, note that the order in which the miner includes transactions into the block matters; if there are two transactions A and B in a block such that B spends a UTXO created by A, then the block will be valid if A comes before B but not otherwise.
The interesting part of the block validation algorithm is the concept of “proof of work”: the condition is that the SHA256 hash of every block, treated as a 256-bit number, must be less than a dynamically adjusted target, which as of the time of this writing is approximately 2190. The purpose of this is to make block creation computationally “hard”, thereby preventing sybil attackers from remaking the entire blockchain in their favor.
Because SHA256 is designed to be a completely unpredictable pseudorandom function, the only way to create a valid block is simply trial and error, repeatedly incrementing the nonce and seeing if the new hash matches. At the current target of 2192, this means an average of 264 tries; in general, the target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes. In order to compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a “transaction fee”. Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.
Bitcoin mining uses the hashcash proof of work function; the hashcash algorithm requires the following parameters a service string, a nonce, and a counter. In bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the Merkle tree of all transactions in the block, the current time, and the difficulty. Bitcoin stores the nonce in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the Merkle tree (the coinbase is the special first transaction in the block). The counter parameter is small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work. When mining bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter and extraNonce fields. Incrementing the extraNonce field entails recomputing the Merkle tree, as the coinbase transaction is the left most leaf node. The block is also occasionally updated as you are working on it.
A Block Header Contains these Fields:
The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions. The compact format of target is a special kind of floating-point encoding using 3 bytes mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256. Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. “Nonce” starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root. Moreover, it is extremely unlikely for two people to have the same Merkle root because the first transaction in your block is a generation “sent” to one of your unique Bitcoin addresses Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network. Bitcoin uses: SHA256(SHA256(Block_Header).
For example, the below Python code will calculate the hash of the block with the smallest hash as of June 2011, Block 125552. The header is built from the six fields described above, concatenated together as little-endian values in hex notation:
The output of blockexplorer displays the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right). Example code in PHP without optimization:
In order to better understand the purpose of mining, let us examine what happens in the event of a malicious attacker. Since Bitcoin's underlying cryptography is known to be secure, the attacker will target the one part of the Bitcoin system that is not protected by cryptography directly: the order of transactions. The attacker's strategy is simple:
Once step (1) has taken place, after a few minutes some miner will include the transaction in a block, say block number 270000. After about one hour, five more blocks will have been added to the chain after that block, with each of those blocks indirectly pointing to the transaction and thus “confirming” it. At this point, the merchant will accept the payment as finalized and deliver the product; since we are assuming this is a digital good, delivery is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If the attacker simply releases it into the wild, the transaction will not be processed; miners will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no longer in the state. So instead, the attacker creates a “fork” of the blockchain, starting by mining another version of block 270000 pointing to the same block 269999 as a parent but with the new transaction in place of the old one. Because the block data is different, this requires redoing the proof of work. Furthermore, the attacker's new version of block 270000 has a different hash, so the original blocks 270001 to 270005 do not “point” to it; thus, the original chain and the attacker's new chain are completely separate. The rule is that in a fork the longest blockchain (i.e., the one backed by the largest quantity of proof of work) is taken to be the truth, and so legitimate miners will work on the 270005 chain while the attacker alone is working on the 270000 chain. In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, “51% attack”).
An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The “hash” of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block.
A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the “top” of the tree. The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work). The Merkle tree protocol is arguably essential to long-term sustainability. A “full node” in the Bitcoin network, one that stores and processes the entirety of every block, takes over 200 GB of disk space in the Bitcoin network. A protocol known as “simplified payment verification” (SPV) allows for another class of nodes to exist, called “light nodes”, which download the block headers, verify the proof of work on the block headers, and then download only the “branches” associated with transactions that are relevant to them. This allows light nodes to determine with a strong guarantee of security what the status of any Bitcoin transaction, and their current balance, is while downloading only a very small portion of the entire blockchain.
The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of “secure property titles with owner authority”, a document describing how “new advances in replicated database technology” will allow for a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax. However, there was unfortunately no effective replicated database system available at the time, and so the protocol was never implemented in practice. After 2009, however, once Bitcoin's decentralized consensus was developed a number of alternative applications rapidly began to emerge:
Namecoin is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash. Ideally, one would like to be able to have an account with a name like “george”. However, the problem is that if one person can create an account named “george” then someone else can use the same process to register “george” for themselves as well and impersonate them. The only solution is a first-to-file paradigm, where the first registrant succeeds and the second fails-a problem perfectly suited for the Bitcoin consensus protocol. Namecoin is the oldest, and most successful, implementation of a name registration system using such an idea.
The purpose of colored coins is to serve as a protocol to allow people to create their own digital currencies—or, in the important trivial case of a currency with one unit, digital tokens, on the Bitcoin blockchain. In the colored coins protocol, one “issues” a new currency by publicly assigning a color to a specific Bitcoin UTXO, and the protocol recursively defines the color of other UTXO to be the same as the color of the inputs that the transaction creating them spent (some special rules apply in the case of mixed-color inputs). This allows users to maintain wallets containing only UTXO of a specific color and send them around much like regular bitcoins, backtracking through the blockchain to determine the color of any UTXO that they receive.
The idea behind a metacoin is to have a protocol that lives on top of Bitcoin, using Bitcoin transactions to store metacoin transactions but having a different state transition function. APPLY. Because the metacoin protocol cannot prevent invalid metacoin transactions from appearing in the Bitcoin blockchain, a rule is added that if APPLY″ (S,TX) returns an error, the protocol defaults to APPLY″(S,TX)=S. This provides an easy mechanism for creating an arbitrary cryptocurrency protocol, potentially with advanced features that cannot be implemented inside of Bitcoin itself, but with a very low development cost since the complexities of mining and networking are already handled by the Bitcoin protocol.
Thus in general, there are two approaches toward building a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The former approach, while reasonably successful in the case of applications like Namecoin, is difficult to implement; each individual implementation needs to bootstrap an independent blockchain, as well as building and testing all of the necessary state transition and networking code. Additionally, the set of applications for decentralized consensus technology is predicted to follow a power law distribution where the vast majority of applications would be too small to warrant their own blockchain, and there exist large classes of decentralized applications, particularly decentralized autonomous organizations, that need to interact with each other.
The Bitcoin-based approach, on the other hand, has the flaw that it does not inherit the simplified payment verification features of Bitcoin. SPV works for Bitcoin because it can use blockchain depth as a proxy for validity: at some point, once the ancestors of a transaction go far enough back, it is safe to say that they were legitimately part of the state. Blockchain-based meta-protocols, on the other hand, cannot force the blockchain not to include transactions that are not valid within the context of their own protocols. Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid. Currently, all “light” implementations of Bitcoin-based meta-protocols rely on a trusted server to provide the data, arguably a highly suboptimal result especially when one of the primary purposes of a cryptocurrency is to eliminate the need for trust.
Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of “smart contracts”. UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise. Other, more complicated, scripts exist for various additional use cases. For example, one can construct a script that requires signatures from two out of a given three private keys to validate (“multisig”), a setup useful for corporate accounts, secure savings accounts and some merchant escrow situations. Scripts can also be used to pay bounties for solutions to computational problems, and one can even construct a script that says something like “this Bitcoin UTXO is yours if you can provide an SPV proof that you sent a Dogecoin transaction of this denomination to me”, essentially allowing decentralized cross-cryptocurrency exchange.
However, the scripting language as implemented in Bitcoin has several important limitations Lack of Turing-completeness-that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code. Value—blindness—there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then, it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (e.g., one UTXO of 2k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B. Lack of state-UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex “stateful” contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible. Blockchain-blindness-UTXO are blind to blockchain data such as the nonce and previous hash. This severely limits applications in gambling, and several other categories by depriving the scripting language of a potentially valuable source of randomness.
Thus, there are at least three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin. Building a new blockchain allows for unlimited freedom in building a feature set, but at the cost of development time and bootstrapping effort. Ising scripting is easy to implement and standardize, but is very limited in its capabilities, and meta-protocols, while easy, suffer from faults in scalability. With Ethereum, we intend to build a generalized framework that can provide the advantages of all three paradigms at the same time.
The intent of Ethereum is to merge together and improve upon the concepts of scripting, altcoins and on-chain meta-protocols, and allow developers to create arbitrary consensus-based applications that have the scalability, standardization, feature-completeness, ease of development and interoperability offered by these different paradigms all at the same time. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic “boxes” that contain value and only unlock it if certain conditions are met, can also be built on top of our platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.
In Ethereum, the state is made up of objects called “accounts”, with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields. The nonce, a counter used to make sure each transaction can only be processed once; The account's current ether balance; The account's contract code, if present; and The account's storage (empty by default).
“Ether” is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn. “Messages” in Ethereum are somewhat similar to “transactions” in Bitcoin, but with three important differences. First, an Ethereum message can be created either by an external entity or a contract, whereas a Bitcoin transaction can only be created externally. Second, there is an explicit option for Ethereum messages to contain data. Finally, the recipient of an Ethereum message, if it is a contract account, has the option to return a response; this means that Ethereum messages also encompass the concept of functions. “Transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain the recipient of the message, a signature identifying the sender, the amount of ether and the data to send, as well as two values called STARTGAS and GASPRICE. In order to prevent exponential blowup and infinite loops in code, each transaction is required to set a limit to how many computational steps of code execution it can spawn, including both the initial message and any additional messages that get spawned during execution. STARTGAS is this limit, and GASPRICE is the fee to pay to the miner per computational step. If transaction execution “runs out of gas”, all state changes revert-except for the payment of the fees, and if transaction execution halts with some gas remaining then the remaining portion of the fees is refunded to the sender. There is also a separate transaction type, and corresponding message type, for creating a contract; the address of a contract is calculated based on the hash of the account nonce and transaction data.
An important consequence of the message mechanism is the “first class citizen” property of Ethereum—the idea that contracts have equivalent powers to external accounts, including the ability to send message and create other contracts. This allows contracts to simultaneously serve many different roles for example, one might have a member of a decentralized organization (a contract) be an escrow account (another contract) between a paranoid individual employing custom quantum-proof Lamport signatures (a third contract) and a co-signing entity which itself uses an account with five keys for security (a fourth contract). The strength of the Ethereum platform is that the decentralized organization and the escrow contract do not need to care about what kind of account each party to the contract is.
The Ethereum state transition function, APPLY(S,TX)→S′ can be defined as follows: 1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error. 2. Calculate the transaction fee as STARTGAS*GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error. 3. Initialize GAS=STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas. 5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas revert all state changes except the payment of the fees, and add the fees to the miner's account. 6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.
For example, suppose that the contract's code is
Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, a high-level language, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas 0.001 ether gasprice, and two data fields: [2. ‘CHARLIE’][3]. The process for the state transition function in this case is as follows: 1. Check that the transaction is valid and well formed. 2. Check that the transaction sender has at least 2000*0.001=2 ether. If it is, then subtract 2 ether from the sender's account. 3. Initialize gas=2000; assuming the transaction is 170 bytes long and the byte-fee is 5, subtract 850 so that there is 1150 gas left. 1. Subtract 10 more ether from the sender's account, and add it to the contract's account. 5. Run the code. In this case, this is simple: it checks if the contract's storage at index 2 is used, notices that it is not, and so it sets the storage at index 2 to the value CHARLIE. Suppose this takes 187 gas, so the remaining amount of gas is 1150−187=963. 6. Add 963*0.001-0.963 ether back to the sender's account, and return the resulting state.
If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided GASPRICE multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant. Additionally, note that contract-initiated messages can assign a gas limit to the computation that they spawn, and if the sub-computation runs out of gas it gets reverted only to the point. 3 of the message call. Hence, just like transactions, contracts can secure their limited computational resources by setting strict limits on the sub-computations that they spawn.
The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as “Ethereum virtual machine code” or “EVM code”. The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected. The operations have access to three types of space in which to store data: 1. The stack, a last-in-first-out container to which 32-byte values can be pushed and popped. 2. Memory, an infinitely expandable byte array. 3. The contract's long-term storage, a key/value store where keys and values are both 32 bytes. Unlike stack and memory, which reset after computation ends, storage persists for the long term. The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
The formal execution model of EVM code is simple. While the Ethereum virtual machine is running, its full computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all accounts and includes balances and storage. Every round of execution, the current instruction is found by taking the pcth byte of code, and each instruction has its own definition in terms of how it affects the tuple. For example, ADD pops two items of the stack and pushes their sum, reduces gas by 1 and increments pc by 1, and SST0 RE pushes the top two items of the stack and inserts the second item into the contract's storage at the index specified by the first item, as well as reducing gas by up to 200 and incrementing pc by 1. Although there are many ways to optimize Ethereum via just-in-time compilation, a basic implementation of Ethereum can be done in a few hundred lines of code.
The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The block validation algorithm in Ethereum is as follows
The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a “Patricia tree” is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history-a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20× savings in space.
On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization. Token systems can be implemented in Ethereum. A currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) X had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract. The basic code for implementing a token system in Serpent looks as follows:
This is essentially a literal implementation of the “banking system” state transition function. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. This could be implemented in a contract which maintains an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to “activate” their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.
Financial derivatives are the most common application of a “smart contract”, and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the ('S dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a “data feed” contract maintained by a specific party (e.g., an oracle that receives data from NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.
Given that critical ingredient, the hedging contract would look as follows:
Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they many not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (e.g., gold, (USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be “uplifted” into a cryptographic asset, provided that the issuer can be trusted. Because of its support for smart contracts and relatively low transaction cost and latency, it is preferred that the technology be implemented on an Etherium or Etherium-variant blockchain. However, the technology is not so limited.
In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.
The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DAS system, mapping domain names like “bitcoin.org” (or, in Namecoin's case, “bitcoin.bit”) to an IP address Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:
The contract is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a “function clause” allowing other contracts to query it, as well as a mechanism for the “owner” (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.
Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage. The key underpinning piece of such a device would be what we have termed the “decentralized Dropbox contract”. This contract works as follows. First, one splits the desired data up into blocks encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every \ blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (e.g., pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.
An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.
The general concept of a “decentralized organization” is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographie blockchain technology for enforcement. So far much of the talk around DAOs has been around the “capitalist” model of a “decentralized autonomous corporation” (DAC) with dividend-receiving shareholders and tradable shares: an alternative, perhaps described as a “decentralized autonomous community”, would have all members have an equal share in the decision making and require 67% of existing members to agree to add or remove a member. The requirement that one person can only have one membership would then need to be enforced collectively by the group.
A general outline for how to code a DO is as follows. The simplest design is simply a piece of self-modifying code that changes if two thirds of members agree on a change. Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction:
The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy-style vote delegation (i.e. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the “current system” specialists can easily pop in and out of existence over time as individual community members change their alignments.
An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a “board of directors”.
In the future, more advanced mechanisms for organizational governance may be implemented; it is at this point that a decentralized organization (DO) can start to be described as a decentralized autonomous organization (DAO). The difference between a DO and a DAO is fuzzy, but the general dividing line is whether the governance is generally carried out via a political-like process or an “automatic” process a good intuitive test is the “no common language” criterion: can the organization still function if no two members spoke the same language? Clearly, a simple traditional shareholder-style corporation would fail, whereas something like the Bitcoin protocol would be much more likely to succeed. Robin Hanson's futarchy, a mechanism for organizational governance via prediction markets, is a good example of what truly “autonomous” governance might look like. Note that one should not necessarily assume that all DAOs are superior to all DOs automation is simply a paradigm that is likely to have very large benefits in certain particular places and may not be practical in others, and many semi-DAOs are also likely to exist.
Savings wallets. Suppose that Alice wants to keep her funds safe, but is worried that she will lose or someone will hack her private key. She puts ether into a contract with Bob, a bank, as follows: Alice alone can withdraw a maximum of 1% of the funds per day. Bob alone can withdraw a maximum of 1% of the funds per day, but Alice has the ability to make a transaction with her key shutting of this ability. Alice and Bob together can withdraw anything.
Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.
One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa (Crop insurance), then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.
For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called “SchellingCoin”. SchellingCoin basically works as follows: \ parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.
Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds, i.e., multisignature escrow. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous-two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction.
The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks however, are much easier to parallelize: projects like SETI@home, folding @ home and genetic algorithms can easily be implemented on top of such a platform.
Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's Cyberdice, can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat.
Provided an oracle or SchellingCoin, prediction markets are also easy to implement, and prediction markets together with SchellingCoin may prove to be the first mainstream application of futarchy as a governance protocol for decentralized organizations.
On-chain decentralized marketplaces, using the identity and reputation system as a base: The “Greedy Heaviest Observed Subtree” (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate-because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security. Furthermore, there is a centralization issue: if miner A is a mining pool with 30% hashpower and B has 10% hashpower. A will have a risk of producing a stale block 50% of the time (since the other 30% of the time A produced the last block and so will get mining data immediately) whereas B will have a risk of producing a stale block 90% of the time. Thus, if the block interval is short enough for the stale rate to be high. A will be substantially more efficient simply by virtue of its size. With these two effects combined, blockchains which produce blocks quickly are very likely to lead to one mining pool having a large enough percentage of the network hashpower to have de facto control over the mining process. As described by Sompolinsky and Zohar, GHOST solves the first issue of network security loss by including stale blocks in the calculation of which chain is the “longest”; that is to say, not just the parent and further ancestors of a block, but also the stale children of the block's ancestors (in Ethereum jargon, “uncles”) are added to the calculation of which block has the largest total proof of work backing it. To solve the second issue of centralization bias we go beyond the protocol described by Sompolinsky and Zohar, and also allow stales to be registered into the main chain to receive a block reward: a stale block receives 93.75% of its base reward, and the nephew that includes the stale block receives the remaining 6.25%. Transaction fees, however, are not awarded to uncles.
Ethereum implements a simplified version of GHOST which only goes down five levels. Specifically, a stale block can only be included as an uncle by the 2nd to 5th generation child of its parent, and not any block with a more distant relation (e.g., 6th generation child of a parent, or 3rd generation child of a grandparent). This was done for several reasons. First, unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid. Second, unlimited GHOST with compensation as used in Ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker. Finally, calculations show that five-level GHOST with incentivization is over 95% efficient even with a 15 s block time, and miners with 25% hashpower show centralization gains of less than 3%.
Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees relying on miners to act as the gatekeepers and set dynamic minimums. This approach has been received very favorably in the Bitcoin community particularly because it is “market-based”, allowing supply and demand between miners and transaction senders determine the price. The problem with this line of reasoning is, however, that transaction processing is not a market; although it is intuitively attractive to construe transaction processing as a service that the miner is offering to the sender, in reality every transaction that a miner includes will need to be processed by every node in the network, so the vast majority of the cost of transaction processing is borne by third parties and not the miner that is making the decision of whether or not to include it. Hence, tragedy-of-the-commons problems are very likely to occur. However, when given a particular inaccurate simplifying assumption is made, this is cancelled out. The argument is as follows. Suppose that: 1. A transaction leads to k operations, offering the reward kR to any miner that includes it where R is set by the sender and k and R are (roughly) visible to the miner beforehand. 2. An operation has a processing cost of C to any node (i.e., all nodes have equal efficiency). 3. There are \ mining nodes, each with exactly equal processing power (ie. I/N of total). 1. No non-mining full nodes exist. A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is kR/N since the miner has a 1/N chance of processing the next block and the processing cost for the miner is simply kC. Hence, miners will include transactions where kR/N>kC, or R>NC. Note that R is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and NC is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost. However, there are several important deviations from those assumptions in reality: 1. The miner does pay a higher cost to process the transaction than the other verifying nodes, since the extra verification time delays block propagation and thus increases the chance the block will become a stale. 2. There do exist non-mining full nodes. 3. The mining power distribution may end up radically inegalitarian in practice. 4. Speculators political enemies and crazies whose utility function includes causing harm to the network do exist, and they can cleverly set up contracts whose cost is much lower than the cost paid by other verifying nodes Point 1 provides a tendency for the miner to include fewer transactions, and point 2 increases NG hence, these two effects at least partially cancel each other out. Points 3 and 4 are the major issue; to solve them we simply institute a floating cap: no block can have more operations than BLK_LIMIT_FACTOR times the long-term exponential moving average. BLK_LIMIT_FACTOR and E MA_FACTOR are constants that will be set to 65536 and 1.5 for the time being, but will likely be changed after further analysis. Specifically:
blk.oplimit=floor(blk.parent.oplimit*(EMAFACTOR−1)+floor(parent.opcount*BLK_LIMIT_FACTOR)/EMA_FACTOR)
The Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x<27: x=x*2. Second, contracts can call other contracts, potentially allowing for looping through recursion. This naturally leads to a problem: can malicious users essentially shut miners and full nodes down by forcing them to enter into an infinite loop? The issue arises because of a problem in computer science known as the halting problem: there is no way to tell, in the general case, whether or not a given program will ever halt.
As described in the state transition section, our solution works by requiring a transaction to set a maximum number of computational steps that it is allowed to take, and if execution takes longer computation is reverted but fees are still paid. Messages work in the same way. To show the motivation behind our solution, consider the following examples: 1. An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step. 2. An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for STARTGAS limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps. 3. An attacker sees a contract with code of some form like send(A,contract.storage[A]); contract.storage[A]=0, and sends a transaction with just enough gas to run the first step but not the second (i.e., making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks because if execution stops halfway through the changes get reverted. 4. A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem.
The alternative to Turing-completeness is Turing-incompleteness where JUMP and JUMPI do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of the Etherium solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Miners could try to detect logic bombs ahead of time by maintaining a value alongside each contract specifying the maximum number of computational steps that it can take, and calculating this for contracts calling other contracts recursively, but that would require miners to forbid contracts that create other contracts (since the creation and execution of all contracts above could easily be rolled into a single contract). Another problematic point is that the address field of a message is a variable, so in general it may not even be possible to tell which other contracts a given contract will call ahead of time.
The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees.
The present technology need not be implemented on a Turing complete platform, and need not employ any particular token implementation, though the protocols require consideration for the fact that a recipient must accept a liability, and an incentive is not achieved by transferring tokens to a recipient, and rather accepting tokens from a party is an incentive to the party. As such, various risks incurred by cryptocurrency systems are inverted, and therefore solutions to typical problems may require reconsideration and reimplementation.
The Bitcoin mining algorithm basically works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2190). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse, as it permits mining pools to indirectly control large portions of the processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack.
One common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. The problem with a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPY nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (e.g., change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification suggested by Peter Todd which will alleviate this issue. Ethereum includes an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state S[n] is incorrect. Since S[0] is known to be correct, there must be some first state S[i] that is incorrect where S[i−1] is correct. The verifying node would provide the index i, along with a “proof of invalidity” consisting of the subset of Patricia tree nodes needing to process APPLY(S[i−1],TX[i])→S[i]. Nodes would be able to use those nodes to run that part of the computation, and see that the S[i] generated does not match the S[i] provided. Another, more sophisticated, attack would involve the malicious miners publishing incomplete blocks so the full information does not even exist to determine whether or not blocks are valid. The solution to this is a challenge-response protocol: verification nodes issue “challenges” in the form of target transaction indices, and upon receiving, a light node treats the block as untrusted until another node, whether the miner or another verifier, provides a subset of Patricia nodes as a proof of validity.
The contract mechanism allows anyone to build what is essentially a command line application run on a virtual machine that is executed by consensus across the entire network, allowing it to modify a globally accessible state as its “hard drive”. However, for most people, the command line interface that is the transaction sending mechanism is not sufficiently user-friendly to make decentralization an attractive mainstream alternative. To this end, a complete “decentralized application” should consist of both low-level business-logic components, whether implemented entirely on Ethereum, using a combination of Ethereum and other systems (e.g., a P2P messaging layer, one of which is currently planned to be put into the Ethereum clients) or other systems entirely, and high-level graphical user interface components. The Ethereum client's design is to serve as a web browser, but include support for a “eth” Javascript API object, which specialized web pages viewed in the client will be able to use to interact with the Ethereum blockchain. From the point of view of the “traditional” web, these web pages are entirely static content, since the blockchain and other decentralized protocols will serve as a complete replacement for the server for the purpose of handling user-initiated requests. Eventually, decentralized protocols hopefully themselves in some fashion using Ethereum, may be used to store the web pages themselves.
The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits and financial contracts, gambling markets and the like via a highly generalized programming language. The Ethereum protocol would not “support” any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols and decentralized applications around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer. Finally, there is also a substantial array of applications that have nothing to do with money at all.
The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance. Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.
US 20170213287 provides a system and method for providing a cryptographic platform for exchanging debt securities denominated in virtual currencies. A web based system is provided for debt securities in a virtual currency, which may alternatively be referred to as “solidus bonds.” may be implemented so as to have the following defining characteristics A cryptographic platform for exchanging debt securities denominated in virtual currencies may be implemented within a computer or digital data processing system, so as to provide a securities exchange distributed across a plurality of spatially distributed computers or digital data processing systems (such as a peer-to-peer network of computers). Such a system may provide for distributed ownership of a bond ledger, and may protect the authenticity of data transferred to and from the bond ledger and the integrity of the bond ledger by the use of cryptography (such as a cryptographic blockchain). The system may provide for the use of cryptographic signatures to allow users to prove ownership of a particular security, and thereby ensure the integrity of transactions, for example transfers of a security from one user to another. The system may also rely on the use of cryptography, for example a cryptographic blockchain, to prevent double spending, a problem analogous to “check kiting” in a digital environment. In some embodiments, network participants may be responsible for validating the bond principal and the bond coupons. The principal and the coupons may then be automatically liquidated as virtual currency, such as SwiftCoin currency. In an embodiment, these and other transactions that have been validated by network participants may be irreversible.
A smart contract is an automatically-implemented transaction dependent on software whose execution is controlled by a decentralized system which thereby reliably ensures that once conditions for execution are met, the execution and resulting action are guaranteed according to the decentralized system reliability. See, Smart Investment Contracts Disruption of Private Equity by the Emergence of the Smart Contract Attorney, assure.co/smart-contracts-are-not-what-you-think-they-are-they-are-just-code/
A smart contract is a computer code protocol using blockchain distributed ledger technology to execute transactions based on pre-defined parameters. At its core, a smart contract is not an agreement between parties memorialized in a document drafted by a lawyer, but simply software code written by computer programmers. As such smart contracts are a software coding construct first and only peripherally refer to the legal construction of the underlying transaction relationship, that is a smart contract is not a legally binding contract. However, a legal obligation may be memorialized in a smart contract, and execution of a smart contract (or justifiable failure to execute) may fulfill or completely satisfy a binding legal obligation. The Smart Investment Contract workflow facilitated by blockchain distributed ledger technology would proceed along these lines:
(1) Issuers and investors agree on the terms of a sale with the offering deal terms acting as variables in the templates programmable smart investment contract. (This agreement would represent a contract, and all else being equal, could be enforced if required formalities of contracts are fulfilled).
(2) Once the final terms are settled the smart investment contract is cryptographically signed by all parties with the final agreement terms encoded into a block on the distributed ledger. Depending on the agreement, the signing may fulfill the legal requirements; that is the agreement of the parties may be to delegate the execution to the software, and abrogate responsibility for personal fulfillment.
(3) Upon the closing date the smart investment contract protocol initiates the exchange of cash and transfer of securities, each of which is recorded permanently on the blockchain or otherwise ensure that the terms of the agreement are fulfilled. While smart contracts at present are typically tied to blockchains, this is not definitional for a smart contract, at least as used herein. This leads to an issue which is typically incompletely resolved in existing paradigms if the blockchain forks, and the smartcontract thereafter exists on both chains, what happens when both seek to execute? For example, the redundant execution could be duplicative or inconsistent. (To the extent this is encompassed by the present invention, the resolution is direct: the smartcontract includes a term or code to pre-elect which fork of the blockchain to respect, and therefore no duplication or inconsistency would occur).
(1) Upon a conversion or liquidation event, the smart investment contract initiates the exchange of a promissory note for securities or facilitates the exchange of stock for cash for each investor, with an applicable recordation on the blockchain.
Each party entering into the smart contract would be responsible to ensure that the programmer/“attorney” properly translates dates, deal terms, share prices, and conversion/liquidation mechanics into effective building blocks of “if-then” while simultaneously generating an equivalent summary “term sheet” for establishing mutual assent to an offer.
The use of smart contracts in Initial Coin Offerings (“ICOs”) typically meets the standard definition of both an investment contract and a legally binding written contract. In this context a “smart investment contract” would be designed specifically to facilitate an investment agreement between a company and its investors. While there may be some variability between a traditional paper agreement and the representative digital code of the “smart investment contract,” the blackletter principles of mutual assent to a valid offer and acceptance would be met in equal measure for the following reasons:
Shuai Wang, Yong Yuan, Xiao Wang, Juanjuan Li, Rui Qin. Fei-Fue Wang, “An Overview of Smart Contract: Architecture, Applications, and Future Trends”, 2018 IEEE Intelligent Vehicles Symposium (IV) Changshu, Suzhou, China, Jun. 26-30, 2018, discusses a blockchain powered smart contract, using, e.g., parallel blockchain. Blockchain technology has enabled customizable programming logic to be stored in a decentralized way. This has revived the notion and facilitated the creation of smart contracts (also called blockchain contracts, digital contracts, or self-executing contracts) that were first proposed by Nick Szabo in 1994. Smart contracts are self-executing contracts with the terms of the agreement between interested parties. The contracts are written in the form of program codes that exist across a distributed, decentralized blockchain network. Smart contracts allow transactions to be conducted between anonymous or untrusted parties without the need for a central authority. Blockchain technology represented by Bitcoin and other cryptocurrencies has the typical features of decentralization, tamper-resistant, anonymity and auditability. However, writing contracts with complex logic is not possible due to the limitations of Bitcoin scripting language (Bitcoin scripting language has only 256 instructions, in which. 15 are currently disabled, and 75 are reserved). Due to limited functionality, Bitcoin can only be considered as the prototype of smart contracts. Newly emerging blockchain platforms such as Ethereum embrace the idea of running user-defined programs on the blockchain, thus creating an expressive customized smart contracts with the help of Turing-complete programming language. The codes of Ethereum smart contract are written in a stack-based bytecode language and executed in Ethereum Virtual Machine (EVM). Several high-level languages such as Solidity and Serpent can be used to write Ethereum smart contracts. The code of those languages can then be compiled into EVM bytecodes to be run. Ethereum is currently the most popular platform for developing smart contracts.
The correct implementation of smart contracts is enforced by the consensus protocols. The contracts can encode any pre-defined rules and execute the corresponding operations when trigger conditions are satisfied. Thus smart contracts can be applied in many fields, including intelligent assets and self-enforcing or autonomous governance applications (e.g., digital property management such as ujomusic, e-voting, and supply chain).
A typical blockchain system generally consists of six layers, namely, data layer, network layer, consensus layer, incentive layer, contract layer and application layer.
Data layer. This layer includes the underlying data blocks related encrypted messages, and timestamp, etc.
Network layer. The blockchain system usually adopts the P2P protocol that is completely distributed and can tolerate single point of failures (SPoF). Blockchain network nodes have the characteristics of equality, autonomy, and distribution. All the nodes are connected in a topological structure without any centralized authoritative nodes or hierarchy.
Consensus layer. The consensus layer encapsulates various types of consensus protocols. This is due to the decentralized blockchain is jointly managed and maintained by multiple parties. Some of the nodes may not be credible and therefore require support for the Byzantine Fault Tolerance (BFT). Common consensus algorithms include PoW (Proof of Work), PoS (Proof of Stake), PBFT (Practical Byzantine Fault Tolerance), etc. PoW consensus process (commonly known as mining, each node is called a miner) is as follows each node contributes their computing resources to compete solving a SHA256 mathematical puzzle (the difficulty of the puzzle could be adjusted dynamically), the winner miner broadcasts the mined block to other nodes, then other nodes confirm its validness. If the block is validated, other miners would append this new block to their own blockchains. However, PoW consumes large amounts of electricity resource, result in a huge waste of energy. Thus, researchers propose some alternative consensus protocols. For example, EOS adopts DPOS (Delegated Proof of Stake) consensus protocol which leverages the power of stakeholder approval voting to resolve consensus issues in a fair and democratic way \. Currently, Ethereum adopts PoW+PoS hybrid consensus mechanism and Hyperledger Fabric adopts PBFT mechanism.
Incentive layer. Consensus nodes in a decentralized system are self-interested, maximizing revenue is the fundamental goal of their participating in data verification and accounting. Therefore, incentive-compatible mechanisms should be designed, so that the individual rational behavior of the consensus nodes to maximize their own profits can be incentive-aligned with the overall goal of guaranteeing the safety and effectiveness of the decentralized blockchain ecosystem. Taking Bitcoin as an example, the economic incentive in Bitcoin s PoW consensus mechanism consists of two parts the newly issued Bitcoin rewards and the transaction fees. They are awarded to the node who can first solve the mathematical puzzle and record the block successfully.
Contract layer. The contract layer encapsulates various types of script codes, algorithms, and sophisticated smart contracts, and thus is the basis for flexible programming and manipulation of blockchain systems. Most of the cryptocurrencies, including Bitcoin and Litecoin, use non-Turing-complete scripting language which means they have no flow control, namely, no loops or conditionals Nowadays, more complex and flexible scripting languages for smart contracts have emerged, e.g., Solidity and Serpent, which enable blockchain to support a wider range of applications of finance and social systems.
Application layer. The main application in the Bitcoin system is digital currency transactions. For Ethereum platform, in addition to currency transactions, it also supports Decentralized Applications (Dapp). Dapp is an application that runs on a decentralized network such as Ethereum. Hyperledger Fabric mainly aimed at enterprise-level blockchain applications, its Dapps can be built on SDks using programming languages such as Go, Java, Python, and Node.js.
Smart contracts are a set of Scenario-Response procedural rules and logic. In other words, they are decentralized, trusted shared codes that deployed on blockchain. The parties signing a contract should agree on contractual details conditions of breach of contract, liability for breach of contract and the external verification data sources (oracles), then deploy it on the blockchain in the form of smart contract thus to automate the execution of contract on behalf of the signatories. The whole process is independent of any central agencies.
Normally, after the smart contracts are signed by all parties, they are attached to the blockchain in the form of program codes (e.g., a Bitcoin transaction), and are recorded in the blockchain after being propagated by the P2P network and verified by the nodes. Smart contract encapsulates a number of pre-defined states and transition rules, scenarios that trigger contract execution (such as at a given time or a particular event occurs), responses in a particular scenario, etc. The blockchain monitors the real-time status of smart contracts and executes the contract after certain trigger conditions have been met.
Smart contracts can be developed and deployed in different blockchain platforms. Different platforms have different characteristics. In this section, we will introduce two typical platforms, namely, Ethereum and Hyperledger Fabric.
Ethereum. Ethereum is a public blockchain platform on which applications run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference. A Turing-complete virtual machine called Ethereum Virtual Machine (EVM) is used to execute contract bytecode (the bytecode is compiled by Solidity as mentioned before). The applications on Ethereum are run on its platform-specific cryptographic token—Ether. Ether is used in two ways, one is traded as a digital currency like Bitcoin; another is used to compensate participant nodes for the computations they performed.
Hyperledger Fabric. Hyperledger Fabric is a blockchain framework implementation which is hosted by Linux Foundation. It is a platform for distributed ledger solutions, underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility and scalability. It is designed to support pluggable implementations of different components, and accommodate the complexity and intricacies that exist across the economic ecosystem. Hyperledger Fabric leverages container technology to host smart contracts called “chaincode” which comprise the application logic of the system. Besides that, “chaincode” is the only channel that interacts with the blockchain and the only source that generates the transactions.
The codes of Ethereum smart contracts are written in stack-based bytecode language and executed in EVM. Several high-level languages (e.g., Solidity, Serpent and LLL) can be used to write Ethereum smart contracts. The codes will then be compiled into EVM bytecodes to be run. Hyperledger Fabric develops smart contracts using Go and Java, etc. The essence of deploying smart contracts on Hyperledger Fabric is to realize the three functions—Init, Invoke and Query in the “chaincode” interface, which are respectively used to implement contract deployment, transaction processing and transaction inquiries.
Smart contracts have three characteristics, namely, autonomy, self-sufficiency, and decentralization. Autonomy means that after they are launched and executed, the contracts and the initiating agents need not be in further contact. Second, smart contract can be self-sufficient in their ability to marshal resources-that is, raising funds by providing services, and spending them when needed, e.g., gain processing power or storage. Third, smart contracts are decentralized as they do not subsist on a single centralized server, they are distributed and self-executed across network nodes.
Smart contracts have important implications for the blockchain. On one hand, smart contracts are the activators of blockchain that laying the foundation for the programmable financial and social systems. On the other hand, the automation and programmable features of smart contracts make it possible to encapsulate the complex behavior of nodes in a distributed blockchain system, which helps to promote the applications of blockchain technology in distributed artificial intelligence systems, and thus makes it possible to build various types of decentralized autonomous organization (DAO), decentralized autonomous corporation (DAC), and decentralized autonomous society (DAS) in the future.
There are various application scenarios where smart contract can be applied to. Some of these applications are as follows:
Financial transactions. Smart contract is particularly suitable to business models such as equity crowdfunding, peer-to-peer lending (P2P lending) and online insurance. Traditional financial trade need to be coordinated by central agencies such as central clearing institutions or exchanges, while the agility feature of smart contract can greatly reduce transaction costs and increase efficiency, thus avoiding cumbersome clearing and delivery.
Prediction markets. Prediction markets have been proven to be able to provide better future forecasts, more direct hedging and speculation mechanisms. Due to the distributed consensus verification and immutability, smart contract can be used in prediction markets. Two typical applications are Augur and Gnosis Augur manages to create a stunningly accurate forecasting tool with the help of blockchain. Gnosis provides participants with a playful environment to try out trading in markets and win GNO tokens as a reward for successful predictions. In addition, smart contract can also be used for voting or gambling.
Internet of Things (IoT). The combination of smart contracts and IoT can not only facilitate the sharing of information between devices, but also allow people to automate time-consuming workflows in a cryptographically veritable manner. Slock.it proposed the first autonomous lock that people can open with token. The owners of the lock only decide on two numbers—the deposit cost and the rental cost. The user of the lock scans it and sees what he or she has to pay in terms of deposit. When the deposit is received by the lock, control is granted. The users can then open and close the lock as often as they want to. When people no longer need the lock, they get back their deposit minus the cost of rental, which is transferred to the owner of the lock. Besides houses and apartments renting, the lock can be applied to cars, bikes, padlocks etc. Smart contract can also be used on smart grid that the renewable energy could be bought and sold in a P2P market, thus reducing intermediate costs.
There are also some possible application scenarios of smart contracts such as digital rights management, social media platforms, cloud storage, supply chain, intelligent transportation, etc.
Smart contracts have distinct characteristics compared with traditional distributed applications. On one hand, many smart contract platforms, such as Ethereum, operate on the public networks where arbitrary participants can join. One the other hand, due to the immutable nature of blockchain, contracts cannot be modified once they are deployed, so hackers can exploit this vulnerability to attack. In addition, since smart contract is generally used to transfer digital assets, security and privacy are of paramount importance. The issues include:
Reentrancy vulnerability. This problem occurs when an attacker utilizes a recursive call function to conduct multiple repetitive withdrawals while their balances are only deduced once. This may result in unexpected behaviors even eventually consuming all the gas.
Transaction-Ordering Dependence (TOD). This occurs when several dependent transactions that invoke the same contract are included in one block. We know that miners can set arbitrary order between transactions, namely, contract final state rest with how the miner sorts the transactions. Thus, an adversary can successfully launch an attack if those transitions were not executed in the right order.
Timestamp Dependence. Generally, the timestamp is set to the current time of the miner's local system. However, the miner can change this value while still having other miners accept the block. The security problem arises when the timestamp is used as a triggering condition to perform specific actions (e.g., sending money) because the attacker can use different block timestamps to manipulate the result of the contract. These are timestamp-dependent contracts.
Lacking of trustworthy data feeds Smart contracts sometimes require information from external resources, e.g., oracles. However, the reliability of the information cannot be guaranteed.
Privacy issues. Since all transaction history is stored on the blockchain and is visible to anyone, it is theoretically possible to obtain a user's private information by analyzing transaction graph structures, called a deanonymization attack.
Anonymous Zether is a private payment system, and is an anonymous extension of Binz, Agrawal, Zamani and Boneh's Zether protocol. The anonymous extension is sketched in Binz, Benedikt, Shashank Agrawal, Mahdi Zamani, and Dan Boneh. “Zether: Towards privacy in a smart contract world.” In International Conference on Financial Cryptography and Data Security, pp. 123-113. Springer, Cham, 2020. Agrawal, Shashank, Karl Benedikt Bunz, Mahdi Zamani, and Dan Boneh. See US 20190161153. Anonymous Zether is an private value-tracking system, in which an Ethereum smart contract maintains encrypted account balances. Each Zether Smart Contract (ZSC) must, upon deployment, “attach” to some already-deployed ERC-20 contract; once deployed, this contract establishes special “Zether” accounts into/out of which users may deposit or withdraw ERC-20 funds. Having credited funds to a Zether account, its owner may privately send these funds to other Zether accounts, confidentially (transferred amounts are private) and anonymously (identities of transactors are private). Only the owner of each account's secret key may spend its funds, and overdraws are impossible. The (anonymous) Zether Smart Contract operates roughly as follows. Each account consists of an ElGamal ciphertext, which encrypts the account's balance under its own public key. To send funds, Alice publishes an ordered list of public keys-which contains herself and the recipient, among other arbitrarily chosen parties-together with a corresponding list of ElGamal ciphertexts, which respectively encrypt (under the appropriate public keys) the amounts by which Alice intends to adjust these various accounts' balances. The ZSC applies these adjustments using the homomomorphic property of ElGamal encryption (with “message in the exponent”). Alice finally publishes a zero-knowledge proof which asserts that she knows her own secret key, that she owns enough to cover her deduction, that she deducted funds only from herself, and credited them only to Bob (and by the same amount she debited, no less); she of course also demonstrates that she did not alter those balances other than her own and Bob's. These adjustment ciphertexts-opaque to any outside observer-conceal who sent funds to whom, and how much was sent. Users need never interact directly with the ZSC rather, our front-end client streamlines its use. Anonymous Zether is feasible for mainnet use, as of EIP-1108. With that said, funding throwaway accounts (i.e., to pay for gas) represents a privacy challenge (as discussed in the original Zether paper). We don't yet endorse Anonymous Zether for use on the mainnet.
See: 7181017; 7869591; 8316237; 8419378; 8153219; 8193386; 8501762; 8522330; 8523657; 8566247; 8572207; 8621368; 8632193; 8671112; 8688525; 8719131; 8726379; 8727893; 8756151; 8756156; 8769643; 8777735; 8862506; 8904181; 8905303; 8909517; 8915781; 8918794; 8938534; 8947427; 8950004; 8961300; 8961301; 8962964; 8968082; 8968104; 8972612; 8974284; 8985442; 8986096; 8992311; 8992312; 9014661; 9015847; 9020110; 9027007; 9039508; 9046994; 9047600; 9056253; 9070252; 9070253; 9071444; 9076294; 9076295; 9087399; 9092939; 9092940; 9104873; 9135787; 9138652; 9160764; 9171299; 9177156; 9185161; 9210472; 9213949; 9214063; 9218470; 9219824; 9224262; 9232476; 9256769; 9258307; 9270534; 9275389; 9280792; 9294365; 9298806; 9299071; 9299218; 9300724; 9305428; 9305437; 9307047; 9311639; 9311640; 9317997; 9317998; 9317999; 9324062; 9330261; 9332302; 9338499; 9338500; 9344754; 9350753; 9350762; 9351032; 9351124; 9364950; 9373223; 9374280; 9386022; 9397985; 9398018; 9401850; 9406195; 9411976; 9413735; 9413780; 9418213; 9419951; 9425954; 9426151; 9426167; 9430905; 9436455; 9436811; 9436935; 9440152; 9443383; 9451010; 9452353; 9454365; 9454656; 9460322; 9463388; 9465488; 9466051; 9473503; 9473524; 9485736; 9489502; 9489522; 9489762; 9489798; 9495668; 9495679; 9501791; 9509699; 9514264; 9514293; 9514497; 9514609; 9514644; 9516035; 9519925; 9521045; 9531724; 9532222; 9533413; 9536385; 9542683; 9544143; 9548957; 9552580; 9552615; 9552694; 9552696; 9553882; 9553888; 9553982; 9558623; 9558624; 9559920; 9563470; 9569262; 9569771; 9576426; 9582182; 9595031; 9595034; 9596787; 9607156; 9607330; 9607461; 9608814; 9608829; 9619967; 9633513; 9635000; 9641338; 9641341; 9645604; 9646029; 9648015; 9648029; 9659104; 9659123; 9659439; 9660627; 9660803; 9665239; 9667427; 9667600; 9667809; 9672499; 9672509; 9672518; 9673979; 9674584; 9679275; 9679276; 9686247; 9697342; 9697362; 9704143; 9704190; 9710808; 9712500; 9712556; 9720649; 9721239; 9722790; 9728037; 9729318; 9734491; 9735958; 9740873; 9740906; 9741337; 9742744; 9747077; 9747586; 9747753; 9749140; 9749297; 9749860; 9754131; 9754490; 9762562; 9762590; 9763271; 9767520; 9767651; 9769189; 9772820; 9773232; 9773351; 9774448; 9774578; 9774579; 9781494; 9785369; 9785912; 9786127; 9787545; 9792600; 9792742; 9794074; 9800514; 9800517; 9807106; 9811981; 9813770; 9815191; 9818092; 9818098; 9818109; 9818116; 9820120; 9824222; 9824408; 9824540; 9825765; 9825931; 9830580; 9830593; 9836790; 9836908; 9842216; 9846856; 9849364; 9852305; 9852417; 9852426; 9852427; 9853819; 9853977; 9858546; 9858766; 9858781; 9862092; 9864970; 9866393; 9870562; 9872050; 9875489; 9875510; 9876646; 9876775; 9881176; 9882715; 9885672; 9886685; 9887975; 9887995; 9888007; 9888026; 9889382; 9892141; 9892400; 9892460; 9892597; 9894101; 9898739; 9898781; 9898782; 9900841; 9904544; 9904830; 9906513; 9906525; 9911102; 9911150; 9916290; 9916432; 9917754; 9917802; 9922380; 9922381; 9922498; 9930043; 9933790; 9934138; 9934502; 9935772; 9935948; 9940663; 9940779; 9942046; 9942048; 9942217; 9942231; 9942250; 9947033; 9948468; 9948682; 9949697; 9952908; 9953347; 9958840; 9959065; 9959080; 9960909; 9960920; 9961050; 9965628; 9965804; 9965805; 9967088; 9967091; 9967096; 9967102; 9967238; 9967333; 9967334; 9967747; 9973341; 9979718; 9979719; 9984243; 9985699; 9985937; 9985964; 9986305; 9987743; 9990418; 9990504; 9992022; 9992028; 9992194; 9992620; 9994339; 9996325; 9997023; 9998150; 9998282; 9998286; 9998539; D759073; D820859; D824404; 10002277; 10002362; 10002389; 10002396; 10003507; 10004429; 10007405; 10007826; 10007893; 10007913; 10012398; 10013548; 10013836; 10019696; 10019874; 10021113; 10022613; 10022614; 10025797; 10025887; 10025941; 10026082; 10026118; 10031775; 10035065; 10037527; 10037533; 10042782; 10043174; 10046228; 10046521; 10049017; 10050779; 10050959; 10055446; 10055554; 10055715; 10055720; 10055768; 10055926; 10055935; 10057065; 10057205; 10057222; 10057238; 10061668; 10063529; 10063531; 10063548; 10063572; 10067994; 10068228; 10068397; 10069672; 10075298; 10079682; 10079881; 10084607; 10084816; 10087783; 10089176; 10089489; 10089492; 10089819; 10089830; 10091180; 10095253; 10095549; 10097344; 10097345; 10097356; 10097362; 10097558; 10102065; 10102265; 10102510; 10102526; 10103885; 10103893; 10103953; 10104198; 10108589; 10108812; 10108819; 10108938; 10108954; 10110385; 10110576; 10114854; 10114963; 10114970; 10114980; 10115068; 10116453; 10116657; 10116667; 10116765; 10121019; 10121025; 10121126; 10121143; 10121172; 10121186; 10121215; 10121339; 10127105; 10127368; 10127378; 10127528; 10127552; 10127647; 10129032; 10129238; 10129250; 10130013; 10130195; 10134201; 10135607; 10135609; 10135616; 10135793; 10135834; 10135870; 10135921; 10136098; 10140470; 10140602; 10140658; 10142098; 10142312; 10142333; 10142347; 10146792; 10146947; 10147264; 10147428; 10148441; 10152756; 10153905; 10153939; 10153983; 10154029; 10157078; 10157294; 10157295; 10157380; 10158480; 10158492; 10158527; 10158703; 10158737; 10162519; 10162704; 10162954; 10163079; 10163080; 10163297; 10164773; 10164779; 10164952; 10166675; 10168693; 10169433; 10169586; 10169614; 10169770; 10169937; 10171245; 10171555; 10171967; 10176308; 10176309; 10176352; 10176481; 10176671; 10177908; 10178069; 10178105; 10180912; 10181113; 10182051; 10183214; 10185550; 10185759; 10185917; 10185928; 10186115; 10187203; 10187214; 10187369; 10187373; 10192073; 10193695; 10193696; 10193884; 10194320; 10195513; 10198311; 10198325; 10198905; 10198908; 10198949; 10200196; 10200197; 10200198; 10200199; 10200834; 10204148; 10204339; 10204341; 10204378; 10204472; 10206082; 10210502; 10217037; 10219744; 10223096; 10223520; 10223685; 10223873; 10225076; 10225078; 10225289; 10225614; 10229275; 10229396; 10229400; 10230526; 10230530; 10231077; 10231652; 10235402; 10235529; 10235538; 10235726; 10236006; 10237062; 10237064; 10237259; 10237583; 10238288; 10241842; 10242219; 10242538; 10243731; 10243738; 10243743; 10243748; 10243934; 10248119; 10248793; 10248813; 10249114; 10250381; 10250522; 10250535; 10250583; 10250694; 10252145; 10255001; 10255108; 10255342; 10255442; 10255460; 10255600; 10255625; 10255635; 10256829; 10256974; 10257268; 10257270; 10257496; 10257819; 10257960; 10261726; 10262138; 10262140; 10262163; 10262164; 10262311; 10262318; 10262321; 10262351; 10262377; 10268782; 10268829; 10268994; 10269004; 10269009; 10269012; 10269073; 10269110; 10270475; 10270476; 10270599; 10270600; 10275363; 10275627; 10275772; 10275902; 10277400; 10277561; 10282554; 10282741; 10282798; 10282938; 10284379; 10285133; 10289631; 10289716; 10289816; 10289915; 10289987; 10289989; 10291408; 10291413; 10291627; 10293263; 10296248; 10296729; 10296764; 10296794; 10296865; 10296894; 10297094; 10297106; 10298259; 10298396; 10298405; 10298571; 10298572; 10298585; 10303877; 10303887; 10304078; 10304143; 10304147; 10304280; 10304283; 10304295; 10305694; 10305833; 10305875; 10311240; 10311250; 10311406; 10311515; 10311668; 10313108; 10313360; 10313376; 10313385; 10313510; 10318505; 10318738; 10318747; 10318753; 10318938; 10320569; 10320768; 10320843; 10320969; 10321603; 10324790; 10325156; 10325257; 10325596; 10326766; 10331123; 10331412; 10332169; 10332205; 10332335; 10332336; 10333696; 10333705; 10333706; 10333721; 10333910; 10334050; 10335063; 10335064; 10338558; 10338913; 10339014; 10339506; 10339523; 10339750; 10339754; 10340038; 10341105; 10341121; 10341123; 10341309; 10341431; 10346406; 10346428; 10346814; 10346815; 10346826; 10346845; 10346846; 10346848; 10346869; 10347026; 10348368; 10348484; 10348707; 10348756; 10352797; 10354236; 10354301; 10354325; 10354494; 10355869; 10356066; 10356094; 10356099; 10361849; 10361859; 10361870; 10362010; 10362058; 10362278; 10362517; 10365981; 10366062; 10366204; 10366247; 10366388; 10366419; 10367353; 10367645; 10367803; 10367905; 10372942; 10372943; 10373129; 10373158; 10373426; 10373438; 10373441; 10375037; 10375105; 10380359; 10380373; 10380574; 10380589; 10380594; 10380613; 10380682; 10380685; 10380702; 10380812; 10380842; 10381758; 10382196; 10382205; 10382208; 10382388; 10386988; 10387850; 10387878; 10387881; 10387950; 10388097; 10388106; 10389518; 10389535; 10389713; 10389749; 10390458; 10391628; 10394762; 10394789; 10394845; 10395053; 10395058; 10395062; 10396988; 10396992; 10396997; 10396999; 10397328; 10401411; 10402594; 10402792; 10402793; 10402796; 10402808; 10402823; 10402829; 10402845; 10403093; 10404454; 10404455; 10404463; 10404469; 10404471; 10404523; 10404703; 10405215; 10406422; 10409783; 10409827; 10410209; 10410211; 10410232; 10410604; 10411897; 10411905; 10412086; 10412113; 10412185; 10412536; 10417188; 10417217; 10417615; 10419152; 10419209; 10419225; 10419454; 10423921; 10423938; 10423947; 10423961; 10423993; 10424125; 10424140; 10424149; 10424164; 10425230; 10425426; 10425428; 10425436; 10425698; 10430162; 10430499; 10430563; 10430574; 10430751; 10430771; 10430789; 10430874; 10430898; 10432402; 10432411; 10433112; 10435185; 10437328; 10437630; 10437790; 10438106; 10438170; 10438174; 10438197; 10438198; 10438207; 10438209; 10438249; 10438290; 10440101; 10444818; 10445643; 10445698; 10445708; 10445709; 10445732; 10445754; 10445836; 10445963; 10445965; 10446037; 10447478; 10447480; 10447664; 10447696; 10448064; 10448251; 10452127; 10452863; 10453065; 10453319; 10454878; 10454927; 10454933; 10454970; 10455742; 10459946; 10459990; 10460118; 10460283; 10460312; 10460313; 10460394; 10461940; 10462153; 10462174; 10462185; 10466277; 10467353; 10467391; 10467506; 10467586; 10467694; 10467861; 10469248; 10469250; 10469264; 10469487; 10469507; 10469525; 10474640; 10474836; 10474945; 10475002; 10475030; 10475062; 10475092; 10475115; 10475272; 10475273; 10475275; 10475287; 10476665; 10476847; 10476879; 10476907; 10482288; 10482446; 10482470; 10482538; 10484168; 10484178; 10484341; 10484346; 10484376; 10484413; 10484415; 10489385; 10489485; 10489709; 10489757; 10489780; 10489834; 10489837; 10491375; 10491378; 10491396; 10491402; 10491404; 10491414; 10491608; 10492337; 10493996; 10496327; 10496633; 10496914; 10496923; 10496963; 10496976; 10496989; 10496994; 10497037; 10497209; 10497325; 10498535; 10498541; 10498542; 10499525; 10503614; 10503750; 10503933; 10504080; 10504163; 10504178; 10504179; 10504193; 10504314; 10504843; 10505708; 10505717; 10505720; 10505723; 10505726; 10505740; 10505949; 10507787; 10509919; 10509932; 10510034; 10510053; 10510079; 10510441; 10511447; 10511580; 10511686; 10511827; 10512839; 10512843; 10515333; 10515409; 10515516; 10518178; 10518409; 10521593; 10521604; 10521623; 10521775; 10521814; 10521973; 10522006; 10522016; 10522112; 10523421; 10523443; 10523447; 10523526; 10523643; 10526142; 10528377; 10528551; 10528722; 10528776; 10528868; 10528924; 10528947; 10529015; 10529041; 10529042; 10529190; 10530577; 10530585; 10530734; 10530756; 10530834; 10530859; 10531230; 10532268; 10534634; 10534913; 10535063; 10535065; 10535111; 10535207; 10536265; 10536430; 10536434; 10536445; 10536482; 10538034; 10540209; 10540344; 10540514; 10540619; 10540639; 10540640; 10540653; 10540654; 10540671; 10541806; 10541820; 10541821; 10542030; 10542046; 10542060; 10542800; 10545491; 10545794; 10546296; 10546326; 10547401; 10547441; 10547446; 10547457; 10547594; 10547643; 10547981; 10572684; 10581805; 10581869; 10592985; 10593157; 10594484; 10614661; 10615960; 10621164; 10630468; 10630477; 10637645; 10650313; 10652014; 10664353; 10664591; 10664835; 10678931; 10680800; 10681033; 10692085; 10700850; 10708039; 10708250; 10713731; 10715317; 10715326; 10715500; 10719623; 10721217; 10721240; 10726657; 10728283; 10740455; 10747905; 10748370; 10749687; 10749848; 10755276; 10761877; 10762228; 10762506; 10778410; 10789590; 10790964; 10790987; 10790990; 10797887; 10803205; 10803451; 10810583; 10812274; 10817872; 10819505; 10824763; 10825024; 10825295; 10831903; 10832522; 10833858; 10839107; 10839411; 10841100; 10846372; 10853592; 10855455; 10861016; 10868865; 10872487; 10878108; 10878429; 10880089; 10885735; 10887100; 10887104; 10892888; 20010034640; 20020007457; 20020026345; 20020049601; 20020073202; 20020073318; 20020103999; 20020128978; 20020131600; 20020152252; 20030028423; 20030059041; 20030074330; 20030085997; 20030191956; 20040003278; 20040062399; 20040215828; 20040246960; 20040264927; 20050005266; 20050008152; 20050021479; 20050028009; 20050039034; 20050099960; 20050108391; 20050138364; 20050144468; 20050152596; 20050153624; 20050182937; 20050193048; 20060015737; 20060052962; 20060059333; 20060063205; 20060071951; 20060071981; 20060082609; 20060085647; 20060085651; 20060098814; 20060136728; 20060137006; 20060140401; 20060156392; 20060156416; 20060190378; 20060205011; 20060242699; 20060248334; 20070005594; 20070006150; 20070016528; 20070044139; 20070053506; 20070053507; 20070074036; 20070079342; 20070087756; 20070095909; 20070106908; 20070116283; 20070118746; 20070150404; 20070150596; 20070156553; 20070156586; 20070171050; 20070171851; 20070185878; 20070189519; 20070192864; 20070219933; 20070220279; 20070233602; 20070233606; 20070234431; 20070248232; 20070250718; 20070280482; 20070299952; 20080000969; 20080002578; 20080006615; 20080034203; 20080037785; 20080059791; 20080063210; 20080065882; 20080065903; 20080086757; 20080114681; 20080114682; 20080126801; 20080130902; 20080137863; 20080140577; 20080159294; 20080165956; 20080172233; 20080172333; 20080201398; 20080208560; 20080212780; 20080215897; 20080216051; 20080273696; 20080273697; 20080280559; 20080292104; 20080294909; 20080301448; 20080304657; 20080313264; 20080313691; 20080320300; 20090006855; 20090028322; 20090028336; 20090028339; 20090062942; 20090074006; 20090077444; 20090083279; 20090083546; 20090089789; 20090094464; 20090097642; 20090109916; 20090119518; 20090136033; 20090138486; 20090150982; 20090158054; 20090177591; 20090182667; 20090182997; 20090187757; 20090196304; 20090207819; 20090216970; 20090221439; 20090238365; 20090252327; 20090259843; 20090265547; 20090265548; 20090265737; 20090268908; 20090276841; 20090279694; 20090282039; 20090287924; 20090310582; 20090319802; 20090325575; 20090327141; 20100005309; 20100005310; 20100027784; 20100042828; 20100067462; 20100080152; 20100093364; 20100111296; 20100119069; 20100138671; 20100138882; 20100142704; 20100146299; 20100153714; 20100161998; 20100174904; 20100185863; 20100199090; 20100205430; 20100217613; 20100218037; 20100220643; 20100223057; 20100234022; 20100246812; 20100267386; 20100278221; 20100281267; 20100281269; 20100287370; 20100290617; 20100293293; 20100329448; 20100329454; 20110026781; 20110039589; 20110040820; 20110041178; 20110041180; 20110051931; 20110055300; 20110060901; 20110060917; 20110060918; 20110067012; 20110069630; 20110074850; 20110085658; 20110087885; 20110090879; 20110103253; 20110103374; 20110107105; 20110107364; 20110107379; 20110110525; 20110135096; 20110154016; 20110202766; 20110211692; 20110213962; 20110219067; 20110231555; 20110243320; 20110243324; 20110255687; 20110264920; 20110283099; 20110289311; 20110295752; 20110296438; 20110296481; 20120002811; 20120005719; 20120009939; 20120009949; 20120009950; 20120030468; 20120039463; 20120039465; 20120039473; 20120045056; 20120063593; 20120072737; 20120089494; 20120102335; 20120114123; 20120121080; 20120124393; 20120127890; 20120129550; 20120129551; 20120143922; 20120144186; 20120144459; 20120163222; 20120163584; 20120172050; 20120185437; 20120198560; 20120201378; 20120204026; 20120207299; 20120209790; 20120213359; 20120215845; 20120224474; 20120224688; 20120226900; 20120233460; 20120239932; 20120239944; 20120240062; 20120260092; 20120260348; 20120269348; 20120275592; 20120278622; 20120284530; 20120297198; 20120297201; 20120317034; 20120317656; 20120323981; 20130010686; 20130010950; 20130011215; 20130014270; 20130024689; 20130024693; 20130024933; 20130024936; 20130028415; 20130035979; 20130039489; 20130051551; 20130061263; 20130085916; 20130086378; 20130096943; 20130097431; 20130111205; 20130114811; 20130148551; 20130148868; 20130152160; 20130156188; 20130170640; 20130173917; 20130173929; 20130182848; 20130191650; 20130195267; 20130198522; 20130198854; 20130202109; 20130205331; 20130216044; 20130227283; 20130232567; 20130238897; 20130246813; 20130247230; 20130254532; 20130268772; 20130275743; 20130275752; 20130279690; 20130283393; 20130315390; 20130318351; 20130318360; 20130318560; 20130322627; 20130324155; 20130326224; 20130329883; 20130336474; 20130339743; 20130339754; 20130339814; 20140041039; 20140047544; 20140056426; 20140059345; 20140059347; 20140075183; 20140090023; 20140090036; 20140093077; 20140095860; 20140095865; 20140098960; 20140101765; 20140108020; 20140115090; 20140115321; 20140115322; 20140121990; 20140123301; 20140139608; 20140140514; 20140142958; 20140143369; 20140143764; 20140143878; 20140143879; 20140153717; 20140164760; 20140177828; 20140185797; 20140185803; 20140189361; 20140189792; 20140195818; 20140211943; 20140215217; 20140215222; 20140228049; 20140233726; 20140233731; 20140233740; 20140237253; 20140237254; 20140247939; 20140250301; 20140258396; 20140270159; 20140273958; 20140281511; 20140281567; 20140289536; 20140298028; 20140310527; 20140314232; 20140321642; 20140321644; 20140324447; 20140325217; 20140325230; 20140328279; 20140331059; 20140334622; 20140344575; 20140348326; 20140351104; 20140372769; 20140379991; 20150006908; 20150010147; 20150033033; 20150033120; 20150039586; 20150039912; 20150046450; 20150046708; 20150063563; 20150067336; 20150067874; 20150067875; 20150074803; 20150082425; 20150089243; 20150089589; 20150092667; 20150098566; 20150100785; 20150100794; 20150121062; 20150124962; 20150135329; 20150143111; 20150149767; 20150149773; 20150154357; 20150161398; 20150169889; 20150170197; 20150172049; 20150172258; 20150172260; 20150181308; 20150186683; 20150188949; 20150193628; 20150193633; 20150195083; 20150200840; 20150205967; 20150207630; 20150207846; 20150213239; 20150215123; 20150215669; 20150222422; 20150222648; 20150222938; 20150227930; 20150229472; 20150229480; 20150229619; 20150236849; 20150237519; 20150244517; 20150244710; 20150264626; 20150264627; 20150270952; 20150270967; 20150271541; 20150288519; 20150288662; 20150288665; 20150294117; 20150295712; 20150304329; 20150304851; 20150309863; 20150310228; 20150312031; 20150317362; 20150326389; 20150326392; 20150333905; 20150341173; 20150341174; 20150341326; 20150341335; 20150347435; 20150348087; 20150356281; 20150358153; 20150358167; 20150365227; 20150365435; 20150365440; 20150372809; 20150379301; 20150381348; 20150381349; 20150381350; 20150381588; 20160004874; 20160004879; 20160012238; 20160012240; 20160013930; 20160014456; 20160019279; 20160020898; 20160020904; 20160026807; 20160028698; 20160029076; 20160036584; 20160044003; 20160063189; 20160066027; 20160072623; 20160072800; 20160098198; 20160099872; 20160105400; 20160105402; 20160105414; 20160110403; 20160110500; 20160112197; 20160112396; 20160119119; 20160125141; 20160127125; 20160127128; 20160127335; 20160132317; 20160132692; 20160133164; 20160140348; 20160142750; 20160149866; 20160154971; 20160156595; 20160164670; 20160164671; 20160164676; 20160165268; 20160167164; 20160170996; 20160171212; 20160173275; 20160182222; 20160182226; 20160189461; 20160191233; 20160197726; 20160204917; 20160204936; 20160205074; 20160210131; 20160212103; 20160224735; 20160224964; 20160232553; 20160234010; 20160234686; 20160239647; 20160239653; 20160239657; 20160239658; 20160241531; 20160241532; 20160254911; 20160254914; 20160255498; 20160261404; 20160261592; 20160269174; 20160269775; 20160275308; 20160285836; 20160292430; 20160293172; 20160300252; 20160315761; 20160321654; 20160323098; 20160330018; 20160330026; 20160330034; 20160330209; 20160335440; 20160335450; 20160337319; 20160337464; 20160344557; 20160350552; 20160350648; 20160352510; 20160352710; 20160357791; 20160357869; 20160358165; 20160359617; 20160365973; 20160371064; 20160373440; 20160381405; 20170005787; 20170012970; 20170012996; 20170019248; 20170024585; 20170039377; 20170039386; 20170041132; 20170041298; 20170041300; 20170041395; 20170048208; 20170053249; 20170053282; 20170061833; 20170063526; 20170070340; 20170070351; 20170077950; 20170078438; 20170085382; 20170089291; 20170099133; 20170099262; 20170099263; 20170103217; 20170103227; 20170103391; 20170104582; 20170104583; 20170104752; 20170111165; 20170116396; 20170116410; 20170124348; 20170132279; 20170132537; 20170133022; 20170134158; 20170142109; 20170147835; 20170149558; 20170149796; 20170155515; 20170155628; 20170161314; 20170161829; 20170169241; 20170169425; 20170170960; 20170173262; 20170177899; 20170186255; 20170199818; 20170207919; 20170208043; 20170213287; 20170214666; 20170220617; 20170222800; 20170223008; 20170228559; 20170230171; 20170230344; 20170235736; 20170235969; 20170237551; 20170237725; 20170242961; 20170243028; 20170243284; 20170244553; 20170244988; 20170249460; 20170250796; 20170250799; 20170250819; 20170255769; 20170262651; 20170264426; 20170277773; 20170277774; 20170277775; 20170277906; 20170288856; 20170289008; 20170289111; 20170293913; 20170295143; 20170295226; 20170301052; 20170308580; 20170316391; 20170322800; 20170322977; 20170323118; 20170329980; 20170346627; 20170353296; 20170353310; 20170357826; 20170358161; 20170359321; 20170359323; 20170366338; 20170372201; 20170372226; 20180004743; 20180011801; 20180011996; 20180013748; 20180013828; 20180014241; 20180019983; 20180025435; 20180041345; 20180041481; 20180046812; 20180048459; 20180048467; 20180048628; 20180060604; 20180076956; 20180082043; 20180089419; 20180091306; 20180096166; 20180101697; 20180109376; 20180109541; 20180109831; 20180115412; 20180117446; 20180117447; 20180123802; 20180131507; 20180131512; 20180137549; 20180139190; 20180139481; 20180145825; 20180150642; 20180152299; 20180152300; 20180152426; 20180157558; 20180157854; 20180159680; 20180165470; 20180165781; 20180167197; 20180173890; 20180173906; 20180176017; 20180176216; 20180181964; 20180182036; 20180183570; 20180183571; 20180183572; 20180183768; 20180191692; 20180198601; 20180198613; 20180198630; 20180198632; 20180203808; 20180204284; 20180211673; 20180212750; 20180212751; 20180212752; 20180212753; 20180212755; 20180212764; 20180212775; 20180212933; 20180219913; 20180227121; 20180227278; 20180232381; 20180234253; 20180234254; 20180248684; 20180254893; 20180260576; 20180262485; 20180264347; 20180267981; 20180268062; 20180276400; 20180276409; 20180276417; 20180278410; 20180278421; 20180285576; 20180288023; 20180288039; 20180294951; 20180294952; 20180300497; 20180302380; 20180302382; 20180303420; 20180303421; 20180303422; 20180303423; 20180303424; 20180307859; 20180316495; 20180316676; 20180326291; 20180329783; 20180330077; 20180330078; 20180330079; 20180330125; 20180330179; 20180330343; 20180331821; 20180332011; 20180337775; 20180337860; 20180337899; 20180343109; 20180349577; 20180349632; 20180349636; 20180349637; 20180349638; 20180349740; 20180351745; 20180351922; 20180357434; 20180359078; 20180359079; 20180359084; 20180359097; 20180365201; 20180366036; 20180367294; 20180373834; 20180373849; 20180373882; 20180375639; 20180375640; 20190004999; 20190005254; 20190007059; 20190007197; 20190007212; 20190013943; 20190013950; 20190019183; 20190020470; 20190020651; 20190020712; 20190026146; 20190026730; 20190036678; 20190044697; 20190050589; 20190050591; 20190052458; 20190058580; 20190068374; 20190080392; 20190081783; 20190087600; 20190089372; 20190089526; 20190089537; 20190089547; 20190097787; 20190097985; 20190102163; 20190108350; 20190109701; 20190109712; 20190109828; 20190114706; 20190116035; 20190116174; 20190116180; 20190118767; 20190124051; 20190130125; 20190130698; 20190130701; 20190132295; 20190140818; 20190141051; 20190141568; 20190146917; 20190147143; 20190147415; 20190149317; 20190152435; 20190155643; 20190156078; 20190158272; 20190158594; 20190158906; 20190164153; 20190166113; 20190171847; 20190182027; 20190182035; 20190182216; 20190183255; 20190188708; 20190188711; 20190188712; 20190188732; 20190188787; 20190188790; 20190188793; 20190188806; 20190188941; 20190190261; 20190190694; 20190190695; 20190190698; 20190190701; 20190190713; 20190190714; 20190190719; 20190190742; 20190190987; 20190197094; 20190197249; 20190197378; 20190197534; 20190197589; 20190197600; 20190197622; 20190197635; 20190197831; 20190197835; 20190198144; 20190199511; 20190199514; 20190199516; 20190199518; 20190199531; 20190199535; 20190199693; 20190199695; 20190199700; 20190204881; 20190205066; 20190205115; 20190205317; 20190205486; 20190205547; 20190205558; 20190205563; 20190205568; 20190205773; 20190205832; 20190205844; 20190205849; 20190205853; 20190205870; 20190205873; 20190205875; 20190205881; 20190205886; 20190205894; 20190205932; 20190205943; 20190205970; 20190205980; 20190206182; 20190206183; 20190206191; 20190206272; 20190207757; 20190207760; 20190207763; 20190207767; 20190207770; 20190207781; 20190207951; 20190207955; 20190207969; 20190207995; 20190208354; 20190208414; 20190208422; 20190212159; 20190213311; 20190213312; 20190213333; 20190213335; 20190213371; 20190213462; 20190213573; 20190213584; 20190213586; 20190213590; 20190213633; 20190213699; 20190213751; 20190213840; 20190214848; 20190215159; 20190215311; 20190215404; 20190215670; 20190217022; 20190220010; 20190220324; 20190220603; 20190220624; 20190220768; 20190220813; 20190220836; 20190220851; 20190220852; 20190220854; 20190220856; 20190220857; 20190220858; 20190220859; 20190220860; 20190220861; 20190220886; 20190220919; 20190220922; 20190221076; 20190222424; 20190222567; 20190222575; 20190222586; 20190226850; 20190227515; 20190227553; 20190228019; 20190228133; 20190228174; 20190228178; 20190228386; 20190228387; 20190228397; 20190228407; 20190228409; 20190228413; 20190228461; 20190228484; 20190228612; 20190229887; 20190229889; 20190229891; 20190229892; 20190229909; 20190229911; 20190229914; 20190229918; 20190229920; 20190229921; 20190229927; 20190229930; 20190230054; 20190230070; 20190230073; 20190230092; 20190230114; 20190232161; 20190233060; 20190235933; 20190235946; 20190236214; 20190236286; 20190236298; 20190236300; 20190236559; 20190236561; 20190236562; 20190236563; 20190236564; 20190236591; 20190236593; 20190236594; 20190236598; 20190236606; 20190236627; 20190236665; 20190236698; 20190236699; 20190236716; 20190236879; 20190236880; 20190236881; 20190236893; 20190237095; 20190237171; 20190238316; 20190238319; 20190238327; 20190238337; 20190238344; 20190238487; 20190238525; 20190243611; 20190243820; 20190243912; 20190243988; 20190244138; 20190244195; 20190244215; 20190244227; 20190244255; 20190244287; 20190244290; 20190244294; 20190244298; 20190244483; 20190244531; 20190245680; 20190245917; 20190251018; 20190251075; 20190251077; 20190251078; 20190251079; 20190251080; 20190251124; 20190251187; 20190251199; 20190251249; 20190251262; 20190251270; 20190251271; 20190251284; 20190251296; 20190251489; 20190251523; 20190251524; 20190251526; 20190251527; 20190251551; 20190251552; 20190251553; 20190251554; 20190251557; 20190251558; 20190251563; 20190251566; 20190251573; 20190251575; 20190251576; 20190251603; 20190251624; 20190251627; 20190251629; 20190251648; 20190253235; 20190253239; 20190253244; 20190253245; 20190253250; 20190253252; 20190253254; 20190253256; 20190253257; 20190253258; 20190253259; 20190253260; 20190253261; 20190253263; 20190253265; 20190253523; 20190253524; 20190258523; 20190258610; 20190258687; 20190258807; 20190258828; 20190258953; 20190258971; 20190259008; 20190259013; 20190259025; 20190259029; 20190259093; 20190259095; 20190259099; 20190259114; 20190259120; 20190260574; 20190260579; 20190260585; 20190260715; 20190260761; 20190260788; 20190260829; 20190266128; 20190266146; 20190266178; 20190266235; 20190266263; 20190266327; 20190266576; 20190266577; 20190266597; 20190266601; 20190266612; 20190266897; 20190267119; 20190268138; 20190268141; 20190268147; 20190268163; 20190268165; 20190268284; 20190268312; 20190268466; 20190271959; 20190272393; 20190272512; 20190272534; 20190272537; 20190272538; 20190272721; 20190273610; 20190273616; 20190273619; 20190273725; 20190273739; 20190275894; 20190278765; 20190278907; 20190278918; 20190278920; 20190278921; 20190279143; 20190279160; 20190279172; 20190279181; 20190279197; 20190279204; 20190279206; 20190279210; 20190279215; 20190279247; 20190279257; 20190279321; 20190280856; 20190280861; 20190280864; 20190280872; 20190280873; 20190280880; 20190281026; 20190281028; 20190281030; 20190281066; 20190281259; 20190281465; 20190281857; 20190282906; 20190283239; 20190283240; 20190283252; 20190283648; 20190283962; 20190286102; 20190286138; 20190286139; 20190286152; 20190286164; 20190286490; 20190286532; 20190286805; 20190287046; 20190287047; 20190287059; 20190287062; 20190287063; 20190287069; 20190287102; 20190287105; 20190287107; 20190287149; 20190287174; 20190287175; 20190287199; 20190287200; 20190288832; 20190288850; 20190288853; 20190289068; 20190289454; 20190290964; 20190290965; 20190290991; 20190294513; 20190294689; 20190294805; 20190294817; 20190294822; 20190294956; 20190295038; 20190295045; 20190295049; 20190295050; 20190295069; 20190295073; 20190295078; 20190295079; 20190295114; 20190295126; 20190295159; 20190295176; 20190295177; 20190295182; 20190295193; 20190295350; 20190295371; 20190295415; 20190295547; 20190295722; 20190296895; 20190296896; 20190296897; 20190296902; 20190296903; 20190296904; 20190296907; 20190296910; 20190296915; 20190296916; 20190296920; 20190296958; 20190297031; 20190297062; 20190297064; 20190297101; 20190297109; 20190297134; 20190297442; 20190297544; 20190299105; 20190301875; 20190301883; 20190302249; 20190302717; 20190302993; 20190303111; 20190303121; 20190303250; 20190303296; 20190303349; 20190303353; 20190303362; 20190303363; 20190303413; 20190303441; 20190303445; 20190303448; 20190303463; 20190303540; 20190303541; 20190303543; 20190303550; 20190303551; 20190303552; 20190303559; 20190303579; 20190303587; 20190303590; 20190303600; 20190303603; 20190303620; 20190303621; 20190303622; 20190303623; 20190303670; 20190303781; 20190303790; 20190303805; 20190303807; 20190303834; 20190303843; 20190303853; 20190303854; 20190303867; 20190303879; 20190303882; 20190303886; 20190303887; 20190303888; 20190303892; 20190303893; 20190303913; 20190303920; 20190303921; 20190303922; 20190303926; 20190303927; 20190303929; 20190303931; 20190303932; 20190303933; 20190303935; 20190303939; 20190303942; 20190303951; 20190303960; 20190304005; 20190304012; 20190304027; 20190304038; 20190304165; 20190304253; 20190304259; 20190304260; 20190304578; 20190304582; 20190305931; 20190305932; 20190305933; 20190305934; 20190305935; 20190305936; 20190305937; 20190305938; 20190305943; 20190305949; 20190305950; 20190305952; 20190305954; 20190305956; 20190305957; 20190305958; 20190305959; 20190305960; 20190305964; 20190305965; 20190305966; 20190305967; 20190305968; 20190306124; 20190306128; 20190306137; 20190306143; 20190306147; 20190306148; 20190306150; 20190306151; 20190306173; 20190306176; 20190306190; 20190306230; 20190306232; 20190306235; 20190306463; 20190306549; 20190306552; 20190306574; 20190306647; 20190306757; 20190307388; 20190308806; 20190310137; 20190310695; 20190310878; 20190310900; 20190310943; 20190310980; 20190311006; 20190311033; 20190311054; 20190311090; 20190311096; 20190311100; 20190311102; 20190311108; 20190311116; 20190311125; 20190311147; 20190311148; 20190311153; 20190311196; 20190311296; 20190311336; 20190311337; 20190311341; 20190311343; 20190311351; 20190311352; 20190311353; 20190311357; 20190311358; 20190311359; 20190311392; 20190311417; 20190311428; 20190311429; 20190311431; 20190311437; 20190311443; 20190311447; 20190311571; 20190312440; 20190312719; 20190312727; 20190312728; 20190312731; 20190312734; 20190312736; 20190312792; 20190312831; 20190312848; 20190312852; 20190312855; 20190312863; 20190312869; 20190312875; 20190312877; 20190312878; 20190312879; 20190312886; 20190312915; 20190312928; 20190312939; 20190312941; 20190313576; 20190314726; 20190315314; 20190316912; 20190317220; 20190317651; 20190317677; 20190317810; 20190317924; 20190317934; 20190317935; 20190317936; 20190317961; 20190317964; 20190317968; 20190318012; 20190318043; 20190318066; 20190318109; 20190318117; 20190318122; 20190318128; 20190318129; 20190318243; 20190318257; 20190318265; 20190318286; 20190318291; 20190318302; 20190318326; 20190318327; 20190318328; 20190318329; 20190318332; 20190318333; 20190318338; 20190318346; 20190318348; 20190318349; 20190318350; 20190318351; 20190318353; 20190318356; 20190318358; 20190318359; 20190318367; 20190318377; 20190318399; 20190318408; 20190318423; 20190318424; 20190318425; 20190318427; 20190318433; 20190318631; 20190318807; 20190318814; 20190318816; 20190319780; 20190319791; 20190319792; 20190319794; 20190319798; 20190319806; 20190319808; 20190319809; 20190319861; 20190319927; 20190319928; 20190319932; 20190319938; 20190319939; 20190319940; 20190319945; 20190319948; 20190319961; 20190319964; 20190319968; 20190319971; 20190319980; 20190319987; 20190319993; 20190320004; 20190320006; 20190320014; 20190320037; 20190320061; 20190320070; 20190320210; 20190320242; 20190320580; 20190320898; 20190321132; 20190322187; 20190322426; 20190323858; 20190324431; 20190324432; 20190324433; 20190324434; 20190324435; 20190324436; 20190324437; 20190324438; 20190324439; 20190324440; 20190324441; 20190324442; 20190324443; 20190324444; 20190324772; 20190324867; 20190324958; 20190324989; 20190324995; 20190325038; 20190325044; 20190325048; 20190325082; 20190325085; 20190325115; 20190325148; 20190325161; 20190325162; 20190325165; 20190325227; 20190325258; 20190325262; 20190325367; 20190325402; 20190325403; 20190325405; 20190325406; 20190325407; 20190325408; 20190325420; 20190325430; 20190325431; 20190325432; 20190325433; 20190325436; 20190325447; 20190325452; 20190325468; 20190325473; 20190325478; 20190325495; 20190325498; 20190325502; 20190325507; 20190325512; 20190325515; 20190325517; 20190325522; 20190325523; 20190325526; 20190325528; 20190325532; 20190325541; 20190325642; 20190325684; 20190325691; 20190325692; 20190325700; 20190325719; 20190325794; 20190327077; 20190327078; 20190327079; 20190327080; 20190327081; 20190327082; 20190327083; 20190327084; 20190327088; 20190327090; 20190327094; 20190327097; 20190327102; 20190327180; 20190327200; 20190327216; 20190327218; 20190327234; 20190327239; 20190327259; 20190327292; 20190327299; 20190327328; 20190327329; 20190328227; 20190328457; 20190329669; 20190331505; 20190331702; 20190332430; 20190332431; 20190332552; 20190332586; 20190332608; 20190332691; 20190332702; 20190332718; 20190332719; 20190332729; 20190332783; 20190332791; 20190332807; 20190332809; 20190332810; 20190332817; 20190332818; 20190332821; 20190332921; 20190332931; 20190332955; 20190332966; 20190332974; 20190332995; 20190333029; 20190333030; 20190333031; 20190333032; 20190333033; 20190333048; 20190333051; 20190333054; 20190333056; 20190333057; 20190333058; 20190333059; 20190333066; 20190333096; 20190333097; 20190333116; 20190333142; 20190333143; 20190333146; 20190333147; 20190333148; 20190333149; 20190333166; 20190333169; 20190333171; 20190333181; 20190333214; 20190333304; 20190334694; 20190334695; 20190334697; 20190334698; 20190334699; 20190334700; 20190334703; 20190334704; 20190334708; 20190334711; 20190334715; 20190334716; 20190334717; 20190334719; 20190334723; 20190334724; 20190334725; 20190334726; 20190334728; 20190334730; 20190334859; 20190334886; 20190334904; 20190334905; 20190334912; 20190334920; 20190334954; 20190334957; 20190334997; 20190335551; 20190335715; 20190336401; 20190338962; 20190339668; 20190339678; 20190339684; 20190339685; 20190339686; 20190339687; 20190339688; 20190339712; 20190339756; 20190339974; 20190339975; 20190339977; 20190339978; 20190340013; 20190340042; 20190340110; 20190340136; 20190340169; 20190340170; 20190340216; 20190340264; 20190340266; 20190340267; 20190340269; 20190340306; 20190340350; 20190340352; 20190340361; 20190340362; 20190340369; 20190340371; 20190340379; 20190340467; 20190340575; 20190340584; 20190340586; 20190340587; 20190340588; 20190340594; 20190340597; 20190340600; 20190340605; 20190340607; 20190340608; 20190340609; 20190340619; 20190340623; 20190340627; 20190340645; 20190340673; 20190340683; 20190340685; 20190340686; 20190340689; 20190340703; 20190340707; 20190340715; 20190340716; 20190340885; 20190340888; 20190340906; 20190340946; 20190341134; 20190342073; 20190342074; 20190342076; 20190342077; 20190342078; 20190342084; 20190342085; 20190342087; 20190342094; 20190342095; 20190342099; 20190342143; 20190342149; 20190342270; 20190342290; 20190342295; 20190342336; 20190342344; 20190342382; 20190342407; 20190342415; 20190342422; 20190342528; 20190342731; 20190343317; 20190343429; 20190347105; 20190347243; 20190347268; 20190347290; 20190347347; 20190347368; 20190347397; 20190347398; 20190347399; 20190347420; 20190347433; 20190347442; 20190347444; 20190347601; 20190347605; 20190347624; 20190347625; 20190347626; 20190347627; 20190347628; 20190347651; 20190347652; 20190347653; 20190347654; 20190347655; 20190347656; 20190347657; 20190347658; 20190347660; 20190347661; 20190347663; 20190347685; 20190347699; 20190347724; 20190347725; 20190347738; 20190348158; 20190348174; 20190349185; 20190349188; 20190349190; 20190349191; 20190349195; 20190349199; 20190349200; 20190349201; 20190349203; 20190349205; 20190349254; 20190349261; 20190349321; 20190349343; 20190349346; 20190349347; 20190349356; 20190349361; 20190349371; 20190349372; 20190349426; 20190349433; 20190349628; 20190349680; 20190349708; 20190349733; 20190349794; 20190351694; 20190353139; 20190353629; 20190353685; 20190353709; 20190354076; 20190354170; 20190354189; 20190354191; 20190354374; 20190354397; 20190354398; 20190354450; 20190354518; 20190354523; 20190354606; 20190354607; 20190354611; 20190354614; 20190354628; 20190354693; 20190354694; 20190354708; 20190354723; 20190354724; 20190354725; 20190354771; 20190354829; 20190354887; 20190354922; 20190354943; 20190354944; 20190354945; 20190354962; 20190354963; 20190354964; 20190354966; 20190354967; 20190354968; 20190354969; 20190354970; 20190354971; 20190354972; 20190354975; 20190354976; 20190354977; 20190354989; 20190355005; 20190355025; 20190355031; 20190355053; 20190355057; 20190355059; 20190355060; 20190355076; 20190355113; 20190355450; 20190355460; 20190355472; 20190355483; 20190356164; 20190356467; 20190356469; 20190356470; 20190356471; 20190356472; 20190356473; 20190356475; 20190356481; 20190356484; 20190356491; 20190356493; 20190356539; 20190356609; 20190356638; 20190356641; 20190356657; 20190356658; 20190356662; 20190356672; 20190356674; 20190356680; 20190356733; 20190356736; 20190356745; 20190356775; 20190356945; 20190357049; 20190358428; 20190358515; 20190358543; 20190359056; 20190361626; 20190361663; 20190361697; 20190361731; 20190361842; 20190361867; 20190361869; 20190361874; 20190361891; 20190361917; 20190361992; 20190362054; 20190362068; 20190362287; 20190362305; 20190362323; 20190362340; 20190362348; 20190362352; 20190362361; 20190362376; 20190362388; 20190362389; 20190362392; 20190362400; 20190362430; 20190362443; 20190362446; 20190362457; 20190362616; 20190362716; 20190362826; 20190362828; 20190363854; 20190363870; 20190363871; 20190363872; 20190363873; 20190363874; 20190363875; 20190363877; 20190363878; 20190363881; 20190363882; 20190363883; 20190363884; 20190363889; 20190363890; 20190363892; 20190363896; 20190363905; 20190363938; 20190364021; 20190364045; 20190364046; 20190364055; 20190364056; 20190364057; 20190364426; 20190364698; 20190365014; 20190365016; 20190365063; 20190365282; 20190365592; 20190366475; 20190368233; 20190369644; 20190369721; 20190370012; 20190370058; 20190370223; 20190370241; 20190370250; 20190370286; 20190370330; 20190370334; 20190370358; 20190370366; 20190370446; 20190370479; 20190370484; 20190370486; 20190370500; 20190370504; 20190370624; 20190370634; 20190370652; 20190370732; 20190370740; 20190370760; 20190370761; 20190370762; 20190370788; 20190370789; 20190370791; 20190370792; 20190370793; 20190370797; 20190370798; 20190370799; 20190370806; 20190370807; 20190370808; 20190370809; 20190370810; 20190370811; 20190370813; 20190370816; 20190370839; 20190370842; 20190370847; 20190370855; 20190370857; 20190370866; 20190370905; 20190370919; 20190370925; 20190371102; 20190371106; 20190371117; 20190371129; 20190371176; 20190371335; 20190371457; 20190372345; 20190372754; 20190372755; 20190372756; 20190372759; 20190372760; 20190372762; 20190372763; 20190372765; 20190372768; 20190372769; 20190372770; 20190372772; 20190372773; 20190372776; 20190372778; 20190372779; 20190372781; 20190372786; 20190372825; 20190372834; 20190372882; 20190372931; 20190372938; 20190372950; 20190372956; 20190372965; 20190372985; 20190372987; 20190373015; 20190373047; 20190373051; 20190373134; 20190373136; 20190373137; 20190373339; 20190373459; 20190373472; 20190373521; 20190373862; 20190375373; 20190377029; 20190377336; 20190377394; 20190377461; 20190377617; 20190377645; 20190377648; 20190377660; 20190377712; 20190377722; 20190377724; 20190377805; 20190377806; 20190377811; 20190377889; 20190377899; 20190377904; 20190378024; 20190378069; 20190378073; 20190378080; 20190378081; 20190378092; 20190378094; 20190378096; 20190378098; 20190378106; 20190378119; 20190378121; 20190378122; 20190378127; 20190378128; 20190378133; 20190378134; 20190378136; 20190378137; 20190378139; 20190378140; 20190378142; 20190378152; 20190378153; 20190378162; 20190378164; 20190378165; 20190378166; 20190378176; 20190378192; 20190378207; 20190378220; 20190378224; 20190378227; 20190378230; 20190378352; 20190378386; 20190378418; 20190378619; 20190379529; 20190379530; 20190379531; 20190379538; 20190379543; 20190379544; 20190379545; 20190379546; 20190379619; 20190379639; 20190379642; 20190379646; 20190379649; 20190379653; 20190379660; 20190379664; 20190379673; 20190379699; 20190379724; 20190379727; 20190379754; 20190379761; 20190379768; 20190379797; 20190379925; 20190380030; 20190380031; 20190380032; 20190381242; 20190381654; 20190384250; 20190384263; 20190384385; 20190384587; 20190384593; 20190384594; 20190384595; 20190384627; 20190384639; 20190384686; 20190384748; 20190384832; 20190384833; 20190384834; 20190384839; 20190384842; 20190384892; 20190384895; 20190384927; 20190384932; 20190384933; 20190384935; 20190384968; 20190385096; 20190385100; 20190385115; 20190385120; 20190385130; 20190385136; 20190385153; 20190385154; 20190385156; 20190385157; 20190385160; 20190385162; 20190385165; 20190385167; 20190385170; 20190385172; 20190385175; 20190385182; 20190385183; 20190385215; 20190385223; 20190385229; 20190385236; 20190385240; 20190385244; 20190385256; 20190385269; 20190385407; 20190385711; 20190385748; 20190386814; 20190386817; 20190386818; 20190386829; 20190386832; 20190386833; 20190386834; 20190386940; 20190386951; 20190386968; 20190386969; 20190386970; 20190386975; 20190386986; 20190386990; 20190386995; 20190387000; 20190387058; 20190387060; 20190387281; 20190387341; 20190387356; 20190387832; 20190389323; 20190391268; 20190391540; 20190391550; 20190391551; 20190391552; 20190391663; 20190391829; 20190391845; 20190391971; 20190391972; 20190391973; 20190391979; 20190391980; 20190392019; 20190392049; 20190392064; 20190392088; 20190392118; 20190392119; 20190392123; 20190392138; 20190392159; 20190392162; 20190392164; 20190392178; 20190392361; 20190392386; 20190392392; 20190392403; 20190392406; 20190392407; 20190392429; 20190392432; 20190392434; 20190392437; 20190392438; 20190392439; 20190392457; 20190392468; 20190392470; 20190392489; 20190392511; 20190392530; 20190392536; 20190392659; 20190392677; 20190392683; 20190392684; 20190392928; 20190393627; 20190393699; 20190393701; 20190393721; 20190393722; 20190394018; 20190394019; 20190394023; 20190394025; 20190394026; 20190394027; 20190394039; 20190394044; 20190394046; 20190394047; 20190394048; 20190394050; 20190394052; 20190394091; 20190394100; 20190394113; 20190394175; 20190394176; 20190394179; 20190394203; 20190394222; 20190394242; 20190394243; 20190394257; 20190394267; 20190394302; 20190394511; 20190394637; 20190394648; 20200000366; 20200001185; 20200001836; 20200004016; 20200004500; 20200004611; 20200004643; 20200004732; 20200004737; 20200004771; 20200004788; 20200004846; 20200004854; 20200004855; 20200004932; 20200004945; 20200004946; 20200004951; 20200004962; 20200004969; 20200004973; 20200004981; 20200004986; 20200004987; 20200004988; 20200004995; 20200004996; 20200004997; 20200004998; 20200004999; 20200005031; 20200005107; 20200005168; 20200005173; 20200005180; 20200005189; 20200005207; 20200005212; 20200005213; 20200005219; 20200005224; 20200005253; 20200005254; 20200005255; 20200005264; 20200005267; 20200005271; 20200005281; 20200005282; 20200005283; 20200005284; 20200005285; 20200005286; 20200005290; 20200005292; 20200005293; 20200005295; 20200005296; 20200005299; 20200005302; 20200005307; 20200005308; 20200005316; 20200005332; 20200005349; 20200005388; 20200005390; 20200005398; 20200005403; 20200005404; 20200005410; 20200005415; 20200005559; 20200005587; 20200005589; 20200005590; 20200005591; 20200005597; 20200005767; 20200005777; 20200005912; 20200007311; 20200007312; 20200007313; 20200007314; 20200007315; 20200007316; 20200007317; 20200007318; 20200007322; 20200007331; 20200007333; 20200007336; 20200007338; 20200007342; 20200007343; 20200007344; 20200007345; 20200007346; 20200007393; 20200007414; 20200007464; 20200007511; 20200007513; 20200007514; 20200007525; 20200007540; 20200007544; 20200007558; 20200007581; 20200007918; 20200008299; 20200008320; 20200009983; 20200009990; 20200010080; 20200011557; 20200011683; 20200012248; 20200012527; 20200012579; 20200012625; 20200012634; 20200012676; 20200012703; 20200012731; 20200012763; 20200012765; 20200012767; 20200012768; 20200012779; 20200012805; 20200012806; 20200012809; 20200012810; 20200013025; 20200013026; 20200013027; 20200013028; 20200013029; 20200013045; 20200013046; 20200013047; 20200013048; 20200013049; 20200013050; 20200013053; 20200013055; 20200013062; 20200013063; 20200013073; 20200013083; 20200013093; 20200013118; 20200013229; 20200013250; 20200013251; 20200013268; 20200013302; 20200014527; 20200014528; 20200014529; 20200014531; 20200014536; 20200014537; 20200014542; 20200014546; 20200014632; 20200014664; 20200014668; 20200014671; 20200014691; 20200014720; 20200014745; 20200014759; 20200014816; 20200015034; 20200015078; 20200016363; 20200017117; 20200018800; 20200019154; 20200019155; 20200019288; 20200019397; 20200019421; 20200019450; 20200019538; 20200019545; 20200019613; 20200019616; 20200019626; 20200019677; 20200019680; 20200019706; 20200019707; 20200019723; 20200019821; 20200019864; 20200019865; 20200019867; 20200019894; 20200019898; 20200019923; 20200019931; 20200019936; 20200019937; 20200019938; 20200019946; 20200019959; 20200019961; 20200019963; 20200019966; 20200019967; 20200019980; 20200020032; 20200020037; 20200020038; 20200020064; 20200020091; 20200020174; 20200020175; 20200020176; 20200020187; 20200020319; 20200020398; 20200020424; 20200020425; 20200020440; 20200020454; 20200021429; 20200021439; 20200021443; 20200021444; 20200021446; 20200021546; 20200021568; 20200021569; 20200021570; 20200021588; 20200021589; 20200021590; 20200021598; 20200021600; 20200021602; 20200021643; 20200021649; 20200021714; 20200022201; 20200022416; 20200023273; 20200023846; 20200026076; 20200026253; 20200026270; 20200026289; 20200026444; 20200026510; 20200026548; 20200026552; 20200026613; 20200026619; 20200026691; 20200026699; 20200026700; 20200026712; 20200026741; 20200026785; 20200026787; 20200026800; 20200026834; 20200026862; 20200026867; 20200026973; 20200027005; 20200027010; 20200027050; 20200027066; 20200027067; 20200027079; 20200027080; 20200027082; 20200027084; 20200027085; 20200027089; 20200027091; 20200027093; 20200027096; 20200027106; 20200027117; 20200027120; 20200027125; 20200027132; 20200027133; 20200027162; 20200027169; 20200027179; 20200027183; 20200027303; 20200027314; 20200027315; 20200027565; 20200028360; 20200028667; 20200028668; 20200028675; 20200028681; 20200028688; 20200028691; 20200028692; 20200028693; 20200028697; 20200028775; 20200028797; 20200028800; 20200028804; 20200028834; 20200028844; 20200028885; 20200028908; 20200028926; 20200028947; 20200029128; 20200029139; 20200029190; 20200029250; 20200030172; 20200030971; 20200033821; 20200033834; 20200033837; 20200033887; 20200033931; 20200034311; 20200034334; 20200034338; 20200034343; 20200034352; 20200034353; 20200034356; 20200034395; 20200034411; 20200034448; 20200034453; 20200034454; 20200034456; 20200034457; 20200034469; 20200034501; 20200034536; 20200034548; 20200034550; 20200034551; 20200034552; 20200034553; 20200034571; 20200034610; 20200034712; 20200034766; 20200034788; 20200034792; 20200034804; 20200034813; 20200034818; 20200034828; 20200034833; 20200034834; 20200034836; 20200034839; 20200034841; 20200034868; 20200034869; 20200034876; 20200034888; 20200034919; 20200034925; 20200034928; 20200034944; 20200034945; 20200035059; 20200035337; 20200035339; 20200035340; 20200035341; 20200036225; 20200036511; 20200036514; 20200036515; 20200036517; 20200036519; 20200036520; 20200036523; 20200036530; 20200036531; 20200036533; 20200036549; 20200036585; 20200036687; 20200036695; 20200036707; 20200036712; 20200036728; 20200036729; 20200036740; 20200036743; 20200037034; 20200037158; 20200037381; 20200044837; 20200044863; 20200051361; 20200052890; 20200052898; 20200052903; 20200053054; 20200053124; 20200057755; 20200057920; 20200058022; 20200059495; 20200065480; 20200067699; 20200067707; 20200068404; 20200073560; 20200074110; 20200074112; 20200074456; 20200074457; 20200074459; 20200074548; 20200076570; 20200076614; 20200076829; 20200082113; 20200082126; 20200082259; 20200082433; 20200082738; 20200084017; 20200084039; 20200084191; 20200084288; 20200084483; 20200086828; 20200089872; 20200089906; 20200089919; 20200092094; 20200097256; 20200098011; 20200099666; 20200104636; 20200104705; 20200111022; 20200111093; 20200112424; 20200112429; 20200112442; 20200112545; 20200117690; 20200119921; 20200119969; 20200120070; 20200120074; 20200125739; 20200125744; 20200126070; 20200126075; 20200126660; 20200127810; 20200134207; 20200136797; 20200136798; 20200136799; 20200142986; 20200143066; 20200143076; 20200145195; 20200145384; 20200151356; 20200151992; 20200153624; 20200153627; 20200153628; 20200153801; 20200153803; 20200160290; 20200160388; 20200160641; 20200162235; 20200162251; 20200162268; 20200162451; 20200167503; 20200167512; 20200174949; 20200174990; 20200175180; 20200175183; 20200175611; 20200184036; 20200184093; 20200184465; 20200184471; 20200186325; 20200186350; 20200186352; 20200186528; 20200193042; 20200193066; 20200195419; 20200195437; 20200201679; 20200201910; 20200202018; 20200202171; 20200202345; 20200202376; 20200204340; 20200204375; 20200204524; 20200204563; 20200210392; 20200210404; 20200210405; 20200213079; 20200213130; 20200213134; 20200213329; 20200213331; 20200213839; 20200218825; 20200219362; 20200220851; 20200220870; 20200226470; 20200226867; 20200228307; 20200228309; 20200228313; 20200228314; 20200228317; 20200228325; 20200228339; 20200228340; 20200228341; 20200234719; 20200234794; 20200235908; 20200241960; 20200242102; 20200242466; 20200242557; 20200243176; 20200244435; 20200244437; 20200250318; 20200250320; 20200250679; 20200252198; 20200252199; 20200258339; 20200258340; 20200259638; 20200259639; 20200259896; 20200265159; 20200266974; 20200267144; 20200267553; 20200272475; 20200272744; 20200273028; 20200274693; 20200279045; 20200279253; 20200280430; 20200280431; 20200280553; 20200293643; 20200294158; 20200295926; 20200296128; 20200304284; 20200304290; 20200304293; 20200310767; 20200311300; 20200311566; 20200311695; 20200313886; 20200319853; 20200320206; 20200320340; 20200320825; 20200322125; 20200322127; 20200326937; 20200327250; 20200327252; 20200327546; 20200335107; 20200336292; 20200336468; 20200336470; 20200342118; 20200342331; 20200342452; 20200344049; 20200349054; 20200349274; 20200349435; 20200351078; 20200351083; 20200351089; 20200351098; 20200351253; 20200351258; 20200351657; 20200356085; 20200357031; 20200358187; 20200358594; 20200358595; 20200358599; 20200358601; 20200358610; 20200358611; 20200358746; 20200359207; 20200359222; 20200359550; 20200359582; 20200364456; 20200366459; 20200366487; 20200366503; 20200372145; 20200374100; 20200374103; 20200374118; 20200374270; 20200382274; 20200382288; 20200382299; 20200382325; 20200382478; 20200382510; 20200387777; 20200387893; 20200387896; 20200389292; 20200389298; 20200389303; 20200394287; 20200394518; 20200402073; 20200402171; 20200402625; 20200403772; 20200403781; 20200404023; 20200410134; 20200410399; 20200412550; 20200412702; 20200412715; 20210004493; 20210004502; 20210005112; 20210012029; 20210012282; 20210014047; 20210014063; 20210014071; 20210018953; 20210019143; 20210019893; and 20210021606.
Szabo, N. (1997). The Idea of Smart Contracts www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html
The present technology provides a cryptographic tokenized economic value which represents a liability; i.e., having a negative demand function. The tokenized economic value may have one or more of the following features: transferability; public anonymity (pseudonomy) of the transferor; public anonymity of transferee; non-repudiation of transfer and/or receipt; avoidance of duplicate transfer, and lack of required trusted party in transaction or maintenance (but not excluding information oracles).
In another expression of an embodiment, the characteristics are: anonymity (pseudonomy) of the holder, non-repudiation of transfer, avoidance of duplicate transfer, and avoidance of failure of transfer (one and only one transfer); proof of transfer; and lack of required trusted party in transaction or maintenance (but not excluding information oracles).
In a further expression of an embodiment, a decentralized architecture and its elements are provided to issue/create, transfer, and extinguish tokens which include tokens that have a net negative utility value or have a contingent liability with respect to another party, such that no rational (objective) intrinsic existing incentive exists at the time of at least one transaction to accept such a token. The negative utility value at the time of a transaction means generally that the acceptance is one of involuntary, based on irrationality or altruism, or that the recipient intends to rely on the availability of anonymity to strategically hold the token. The embodiment provides that the current holder of the token is anonymous, meaning that no mandatory or network-intrinsic forensically reliable public record demonstrates ownership or possession of the token by any particular party, and that transfers of the token are also blinded, such that disclosure of a holder at a prior point in time, does not demonstrate current ownership. The anonymous transfer, however, is managed by a preferably decentralized network to allow parties to a respective transfer to demonstrate the existence of a transfer, to ensure that a holder can transfer can transfer once and only once, to ensure non-repudiation of transfer to the single recipient. In the preferred decentralized network, there is preferably no required trusted single party, or consortium of entities acting as a unit.
As noted above, known transactions employ cryptographic tokens to represent liabilities, and blockchain mechanisms may be used to manage and transact such liabilities. However, such transactions do not meet all of these respective criteria. For example, according to typical prior tokenized liabilities, the debt remains personal, and can be transferred only by satisfying the debt (with possible new transaction with new debtor).
According to the prior theories of liability, the basic alternates for ensuring payment were security and reputation. The reputation required linkage to an identity, which could be relatively anonymous, but tied to a unique individual, and not transferrable as a result. Thus, the transaction has the effect of a smart contract, with satisfaction of the debt according to the terms as the basic mechanism to close the record.
The present technology of course can make use of security, personal linkages of the debt, and reputational damage due to default, but also provides other options and enhancements.
When one possesses or is subject to a tokenized liability, that means that the owner of the token (“hot potato”) at the time of the transaction, must provide the corresponding consideration defined by the tokenized terms. Thus, in contrast to a typical cryptocurrency in which consideration for the transaction to transfer the token comes from the transferee, in this case, it is the transferor that must compensate the transferee for acceptance of the tokenized liability. Such an obligation is typically associated with a term or conditions of payment, or other contingency, such that the liability is not ripe immediately upon creation. This creates opportunities for arbitrage, speculation, and risk transfer.
This type of economic system thus permits speculation on the supply and demand for the tokens, as well as the (optional) contingency and the underlying consideration.
The system preferably has no restriction on transferability of particular assets of the debtor, or on transfer of the liability token to another debtor who meets the security requirements, though according to a set of rules, presumably enforced within the distributed ledger and a smart-contract style implementation. To provide an incentive to a token-holder, an existing token could be burned, i.e., transferred to an irretrievable address. Since this extinguishes the obligation of the debtor to the creditor, and in the case of fungible tokens, to the system, the authority to burn tokens must be part of the consensus protocol itself, and not a unilateral option of a token holder. That is, a debt token should not be extinguished unless (a) it is paired with an asset token, or (b) consensus permits the loss of token. It is possible to split tokens, similar to the fractional bitcoins.
The liability token may be unsecured. This use case requires an incentive for avoiding breach by the debtor. In some cases, a debtor willingly incurs and resolves a debt. For example, the debt itself may have tax advantages and defaulting on the debt would have adverse tax consequences. The debt may be a contingent liability, and take the form of insurance or an indemnity; in such cases, regardless of regulation, failure to honor the debt would damage the reputation of the debtor, which is the basis for its business operations. Note that the liability token is transferrable, and need not be held by the original debtor at the time of proposed settlement. Tracking down the debtor in an anonymous system may prove difficult, and therefore the various forms of incentives for adopting the debt (avoiding default on the obligation by the current token-holder) may be a source of speculation. A secured-type token is discussed in US20200394652.
While anonymity is preferably a default attribute, that may be waived, and anonymity may represent a contingency that changes the value of the token. A secured debt with a disclosed debtor may have the highest value, followed by secured debt with an anonymous debtor, followed by an unsecured debt with a disclosed debtor, followed by an unsecured debt with an anonymous debtor. One can therefore gain value by either disclosing the debtor's identity, securing the debt, or both. When a liability is transferred from a disclosed debtor to another debtor, disclosed or undisclosed, the prior disclosed debtor may remain secondarily liable, and as such, pay a lower price to the acquirer of the liability than if the acquirer is disclosed or the liability secured.
In order to avoid escape of a debtor from the liability, the system may thus anonymously encumber distinct assets associated with the debtor's wallet or key, or otherwise secure the liability in some form. Depending on the nature of the security, that may also be a basis for speculation. In this case, the security is not an integral part of a smart contract, and, for example, foreclosure of a security interest may be outside of the blockchain. The security may be substitutable, or other terms applied that are independent of the blockchain transaction. Further, the security need not be of economic form, and, for example, may be reputational, for example in the form of reputational announcements. Thus, for example, an anonymous wallet address may build a reputation as being credit-worthy, and the extension of credit may be based on the credit of the wallet. This score, or use of the underlying data, may represent analysis of the duration of the account, amounts at risk, compliance with terms, etc.
Another example of unlinked security is an asset within the same wallet. A holder of a defaulted obligation may be able to impose a lien on other transactions of the same wallet, and thus limit, without freezing all transactions of the wallet. Therefore, the lien may prevent withdrawals from the wallet, while permitting other transactions within the wallet to remain pending. Liens may be satisfied pro rata, in first-in, first-out order, or otherwise.
A still further example of an enforcement mechanism for the liability relates to tax benefits resulting from a claimed loss. In that case, the claim of a loss represents a partial benefit, and given that there is a legal reporting obligation, and risk of eventual disclosure with waiver of the benefit, there may be sufficient incentive to ensure lack of default. Further, while the identity of the party may be anonymous from the public, a regulated reporting entity may have sufficient identifying information to make a tax filing without public disclosure. For example, as part of the blockchain enforcement mechanism, a report to government may be encoded, separate from the parties to a transaction.
In some cases, the value of cryptographic tokens fluctuates, and a token with negative value may later have a positive value. When there is sufficient risk of this future state, possession of the token, even if a current nominal liability, may still have value and thus have associated incentive for claiming at the appropriate or required time. For example, the holder of a token may apply an implied interest rate of 8% to the token liability, while at the same time deploying the freed resources to a project with an implied internal rate of return of 30%. If the token is then secured by the project, the holder would generally claim and be responsible for the token liability so long as the project remains viable. When and if the project becomes non-viable, then the security for the transaction may be lost; however, even if the tokenized liability becomes unsecured, the default may trigger other loss of credit, reputational damage, and other impairments.
In an anonymous infrastructure, a party may determine that the non-economic costs of default are lower that then economic value of the liability. In that case, there would be incentive to repudiate the liability by the actual token holder to remain anonymous with respect to the creditor. The token holder may, for example, adopt a new wallet and abandon the prior anonymous identity. One way to curtail this is to used an assigned individual identifier, such as a social security number, to obtain a wallet, and prevent reuse of the same identifier to obtain a new wallet. The public information from the wallet does not reveal the user identifier, and thus preserves anonymity. Therefore, the token-holder would be forced to forego all future use of the network. This network and the wallet may be shared with other systems, and therefore greater incentives are maintained to avoid default.
Note that the one-sided transaction does not necessarily pair the liability with a corresponding asset, or encumber specific assets, or force a situation where the token state represents a neutral or affirmative value for the debtor. For example, if one secured the liability token with a hard asset at a discount, the token would therefore represent a net asset having the value of the discount for the debtor.
In another embodiment, the token itself represents a value which may be either an asset or a liability, depending on external circumstances. The present value may be considered according to a variant of Black Scholes option pricing theory (prediction of future value based on statistical properties of past valuation, subject to specific presumptions) depending on the contingencies relating to valuation. In such a case, the liability may be acquired with an expectation that in the future it will become an asset. However, during the period that it is underwater, the above discussion of debtor disclosure incentives would be applicable. Given the possibility that disclosure incentives could be weak over the term of the liability, this will influence the present value calculations.
In a further embodiment, the tokenized liability has a required periodic payment from the debtor. Globally, this may be generally analyzed assuming that the tokenized liability represents a bundle of different term liabilities, that periodically mature. This results if the token rights are severable. However, if the token itself is non-divisible, then if the token itself has a probability of having a positive future value, there will be an incentive to maintain the token against default for at least the present value of the token considering both present value of future liabilities, offset by possible appreciation.
In the pure liability case, the processing of transactions on the distributed ledger, especially if there are mining incentives, need to present inverted incentives with respect to positive asset value tokens. In the case where the value of the token can assume negative states or positive states with respect to a subjective norm, the incentives governing system operation must also provide stable operation regardless of the external economic conditions and contingencies.
The present technology also provides coupled transactions in which the distributed ledger operates as an automated escrow agent, assuring both sides (or all sides, in a transaction that involves more than 2 parties) receive the benefit or their bargain. In order to achieve fault tolerance, this escrow technology provides that the paired (or multiplexed) tokenized transactions be executed simultaneously, with both sides of the transaction verified and settled concurrently. Further, if the transaction is not settled, each party receives back its proffered tokens or consideration. Further, both parties to the transaction may collaborate to reverse the transaction on the distributed ledger, in contradistinction to performing a subsequent reverse transaction. This reversibility of a transaction and essentially expungement from a blockchain, permits correction of mistakes, a feature typically missing from prior systems. This has particular value if an escrow agent is corrupt.
If the counterparty has engaged in misconduct, and refuses to reverse the transaction, then limited recourse is available, which differs little from typical blockchain implementations. That is the transaction is non-reputable, and typically anonymous, leaving the parties in a careat emptor status. This is not a problem that the present technology seeks to solve, and in fact, prefers to incur the risk while ensuring non-reputability.
Therefore, the present technology expends cryptocurrency technologies to negative asset value scenarios of tokenized liabilities, increasing the flexibility of tokenized transactions.
One formulation of a debt that may be implemented according to the present technology is a guaranty. In this scenario, the debtor undertakes a future contingent liability in consideration of a single or periodic payments. In the periodic payment case, the debtor must remain “available” to receive the payments, and to the extent that the payments (in either case) as associated with a wallet address the default of one transaction may result in loss of future revenues. Thus, the basis for the debtor remaining responsible for the debt is because it has a business reason for doing so. The debt is not isolated from other transactions and the game theoretic analysis by the debtor regarding the costs of default are part of a sequential game paradigm.
It is noted that periodic payments or continuous activity are not the sole motivations for avoiding default. In addition to those discussed herein, other motivations may be a probability of a payoff, e.g., a lottery. That is, if there is a potential future payoff from the system (even after extinction of the debt), there will be motivation to treat the token as one having a potential future value, even if its short term value is objectively negative.
The infrastructure of the tokenized liabilities system preferably comprises a set of decentralized nodes. The tokens may be centrally generated or generated ad hoc by nodes. The tokens are, for example, generated in sets of at least two, and perhaps more components. Typically, in a pair, the two tokens have or are associated with at least one complementary property, such that the token have inverse correlated utility value. Note that, when the set of tokens are unseparated, there is no net value as a result of the complementary property. However, when paired (or the complete set aggregated), the tokens may also assume the properties of traditional cryptocurrency tokens, i.e., Bitcoin, Ethereum, etc. See, coinmarketcap.com/all/views/all/.
One implementation of the present technology provides a node that generates a set of tokens, that are together recorded on a blockchain, and representing a smart contract. The smart contract provides that one token represents a liability, and the other token represents an asset. The liability is extinguished when the liability token is paired with the asset token. The asset tokens are fungible, and standardized. While fungibility is not required, this eases liquidity within the system, and standardizes the value of the obligation. The smartcontract may also establish a cash equivalent maximum for the liability. In order to secure the tokens against physical or logical loss, they may be stored in a trusted platform module (“TPM”), which cryptographically secures information. Further, the information may be encrypted and stored on a blockchain. For example, a reliable blockchain may be provided which is accessible with biometric-key authentication. Therefore, the risk of loss before death is low. In case of death, an oracle may trigger a transfer-on-death rule, or a cancel debt-on-death rule (life insurance). See, U.S. Pat. Nos. 7,380,119; 10621366; 8505103; and 20140007087. The hardware may be similar to that disclosed in US 20190041703, and may include a microprocessor, a cryptoprocessor (cryptographic processing accelerator, with storage registers resistant to key extraction), memory, power supply, user interface, data communication interface to digital data communication network. Internet protocol communications, etc.
As noted above, the debt token is objectively undesirable, that is a rational actor would not accept the debt except for an accompanying benefit. Award of such a token provides no rational incentive, and for example, a mining (i.e., transaction processing) incentive would require consumption (marked as redeemed on the blockchain) of the debt tokens. Since this is an “unpaired” transaction without monetary transfer, it means that the corresponding asset must be fungible, and that the inflation if assets over debt in the cryptocurrency economy must be less than the increased value of the cryptocurrency economy as a result of an efficient transaction processing system. Alternately, transactions may be processed for a fee, with the transaction processing node receiving the fee.
The paradigm invites a proof of stake consensus, since the transactions rarely involve any individual creditor. Meanwhile, large creditors have a strong interest in maintaining the blockchain, and maintaining the value of the stake. Further, the perverse incentive is that a creditor will seek to redeem its own debt before redeeming the debt of others i.e., front running. However, core transactions on the blockchain will be generation/issuance of tokens, and redeeming of tokens Since the respective token represents a liability, the initial creation may be self-certified. However, if the token is created along with a positive valued token, then the creation must be authenticated, especially since the negative-valued token is anonymous/pseudonymous. Tokens may be transferred, and the transfers recorded on the blockchain. The redemption transaction is critical to the network. The transaction involves extinguishing a debt token upon authorization of the creditor, and in the case of fungible debt-coins, on behalf of an authorized creditor. The transfer of value in order to incentivize the creditor to authorize cancellation, may be on, or off, the blockchain. Likewise, the initial transaction to incentivize acceptance of the negative-valued token may also be on, or off, the blockchain. Therefore, from the perspective of the system, what differentiates the positive-valued token from a negative-valued token, is that for a positive-valued token, the holder's authority is critical to effect a valid transfer, while for a negative-valued token, the recipient's authority is critical to effect the valid transfer.
While distinct from the transaction, it is important to consider the game theoretic elements that provide incentives for stable operation of the network Why would someone voluntarily accept a liability? Typically for compensation. Why would someone voluntarily pay a debt? Typically to avoid a penalty. When the debt is anonymous/pseudonymous, what penalty could be imposed? This remains a difficult question. However, the answer to that question is a point of innovation, outside of the technology to provide an infrastructure surrounding it.
Various use cases in fact demonstrate the utility of the paradigm, without limiting the kinds of incentives that might exist.
For example, the token may represent an form of insurance (liability contingent on a condition subsequent), wherein the recipient of the token receives payment for undertaking the contingent liability, i.e., acceptance of the liability token. The token may in fact be defined by a smart contract. In fact, absent the token, blockchain and oracle-based insurance instruments exist and are prior art. However, the known obligation itself is tethered to a single entity (cryptocurrency wallet), and is not freely transferrable. On the other hand, in the case of a transferrable obligation, brokers, insurance companies, and reinsurers may all be linked on the blockchain, with recorded transfers of responsibility. Indeed, entities which engage in a business have a reputation, and that may be important to the use case. Customers (i.e., the insured) will naturally gravitate to insurance providers that have a reputation for good service and payment of obligations while those who fail to make good on obligations (especially where there is objective evidence of a failure, since the parties to the original transaction may well be known to each other). While the liability may be contingent, at any time prior to expiration, there remains a risk, and therefore a potential liability, thus driving the value below zero.
An insurance contract may be renewable. In that case, in order to collect the premium, the token holder must reveal him or herself. At that time, the token-holder receives the premium, but also deanonymizes itself and thus would then be subject to a direct claim by the insured if the contingent liability has matured.
Another use case is a simple loan. In this case, the question remains, why would one admit to indebtedness when not compelled? However, there are many instances of voluntary payments or donations, and therefore in such cases, the acceptance of the token may be similar to a charitable pledge. However, in a business context, there is also reputation, as discussed above. Further, there are many advantages to properly accounting for assets and liabilities. For example, income taxes are assessed against net income, which includes deductions for liabilities. money laundering regulations may require proof of source of funds, and thus a determination of where gross assets derive from. Failure to account for and admit such liabilities may incur excess tax liability. Also, distinct from reputation is credit-worthiness. Admission and repayment of debt may substantially increase credit score and availability of credit. One risk is that a great Ponzi scheme will emerge, until a large debt is defaulted. This raises the issue of counterparty risk. The amount of credit extended to a cryptocurrency wallet address may be monitored, to assess the risk. However, this does not address a party that has multiple anonymous/pseudonymous wallets, or a set of colluding parties each with a separate wallet address.
A way to address this is to have a third party credit rating agency assess the credit-worthiness of a party. This information may be available to an oracle, and may be implemented in a way to ensure that the debtor remains pseudonymous. For example, a party presents itself to a credit rating authority, and receives a rating. That rating may be associated with an anonymous/pseudonymous wallet address and e.g., an atomic key, proxy key, or homomorphic encryption technique may be used to transfer the rating to the wallet, without even the rating agency or authority knowing which wallet inherited the rating. While the existence of credibly deniable debt may itself impair credit rating, for ratable entities, the existence of token debt, though anonymous/pseudonymous, may nevertheless be audited by certified public accountants, and thus subject to oversight. Indeed, in one embodiment, the acquisition of debt tokens may be limited to regulated entities which are subject to oversight. Further, while the existence of regulation does not preclude risk of default, an entity may further be audited with respect to its actual defaults, and this fact used by an oracle to further restrict permitted recipients of the debt token.
“Homomorphic encryption” is a form of encryption where a specific algebraic operation performed on the plaintext is equivalent to another (possibly different) algebraic operation performed on the ciphertext. Homomorphic encryption schemes are malleable by design. The homomorphic property of various cryptosystems is used with cloud computing by ensuring the confidentiality of processed data. The “homomorphic” part of a fully homomorphic encryption scheme can also be described in terms of category theory. If C is the category whose objects are integers (i.e., finite streams of data) and whose morphisms are computable functions, then (ideally) a fully homomorphic encryption scheme elevates an encryption function to a function from Cto itself.
Proxy key cryptography is a public key proxy encryption system provides a way of converting ciphertext intended for Alice into ciphertext that is decryptable by Bob without modifying the underlying plaintext. The proxy principal authorized to convert the ciphertexts cannot learn the underlying plaintext. A proxy re-encryption is generally used when one party, say Bob, wants to reveal the contents of messages sent to him and encrypted with his public key to a third party, Charlie, without revealing his private key to Charlie. Bob does not want the proxy to be able to read the contents of his messages. Bob could designate a proxy to re-encrypt one of his messages that is to be sent to Charlie. This generates a new key that Charlie can use to decrypt the message. Now if Bob sends Charlie a message that was encrypted under Bob's key, the proxy will alter the message, allowing Charlie to decrypt it. This method allows for a number of applications such as e-mail forwarding, law-enforcement monitoring, and content distribution. See, U.S. Pat. Nos. 9,419,951; 8,904,181; 8,566,247; 8,316,237; 7,869,591; and 7,181,017.
Homomorphic cryptographic algorithms and atomic proxy key cryptography may also be used to provide a remedy for digital wallet key loss. Essentially, an aggrieved party may seek a consensus authorization for execution of an unmasking or wallet contents transfer transaction, without transcending the normal operation of the network (i.e., forcing a fork), or special relief. The transaction, especially for debt coins, is of lower risk to the network, though essentially the same effect to remedy lost tokens may also be applied for positive valued tokens, and indeed for arbitrary information stored on the blockchain. That is, the private key is cryptographically masked and posted to the blockchain. A smart contract is triggered which then releases the “escrowed” information to the requesting and authenticated party, according to business or legal rules that are not themselves critical to this disclosure. The homomorphic or atomic proxy key algorithm permits the extraction of the information privately, while posting the public encrypted form. For example, the authorized requestor provides session keys to the algorithm, which then publicly masks the secret information during smart contract processing and communications, so that only the authorized recipient is privy to the result.
Encryption technologies, particularly public key encryption systems, seek to share secrets amongst participants to a secure or private communication. Typical public key encryption technologies, presume that a pair of communications partners seek to communicate directly between each other, without the optional or mandatory participation of a third party, and, in fact, are designed specifically to exclude third party monitoring or “man in the middle” attacks. Third parties, however, may offer valuable services to the participants in a communication, but existing protocols for involvement of more than two parties are either inefficient or insecure.
Traditional encryption algorithms rely on use of one or more finite keys which are provided to an algorithm which generates a data string which is apparently random, called pseudorandom, but which can be predicted based on a knowledge of both the algorithm and the key(s), allowing extraction of a superimposed data message. Optimality of an algorithm for a given set of circumstances is based on a number of factors, and therefore many different cryptographic schemes coexist. Essentially, the key should be sufficiently long and stochastic that an extraordinarily long period of time would be necessary to attempt a brute force attack on the algorithm, while only a reasonable amount of time is required to generate keys, encrypt and decrypt messages. In addition, the key should be sufficiently long that observation of pseudorandom (encrypted) datastreams does not permit one to determine the key to the algorithm.
Public Key Encryption is a concept wherein sets of keys are provided. The keys may form a pair, such that a message encrypted with the first key of the pair may be decrypted only by the corresponding second key, but knowledge of one does not impart effective knowledge of the other. One of the keys may be maintained as a secret (private key) and the other published (public key) according to various implementations, to allow use for both secure communications and authentication. Communications may include use of multiple key pairs, to provide bilateral security. The public key pair may be self-generated, and therefore a user need not transmit the private key. It must, however, be stored. The basis for Diffie Hellman and RSA-type public key encryption methods is the large disparity in computational complexity between decrypting the public key created cipher text with the public key encryption private key, which is very rapid and simple to do, and working through the possibilities without the key, which takes a very long time through all known means A typical asymmetric function pair is multiplication and division, with the former being more computationally efficiently implement than the later with a Boolean logic processor. Modern public-key data encryption was originally suggested by Diffie and Hellman. “New Directions In Cryptography.” I.E.E.E. Transactions on Information Theory (November 1976) (the disclosure of which is hereby incorporated by reference), and was further developed by Ronald L. Rivest. Adi Shamir, and Leonard M. Adleman: “A Method for Obtaining Digital Signatures and Public-key Cryptosystems.” Communications of the ACM 21(2):120-126 (February 1978). See also, U.S. Pat. No. 1,351,982, expressly incorporated herein by reference.
The basic reason for public-key encryption system is to ensure both the security of the information transferred along a data line, and to guarantee the identity of the transmitter and to ensure the inability of a receiver to “forge” a transmission as being one from a subscriber on the data line. Both of these desired results can be accomplished with public-key data encryption without the need to maintain a list of secret keys specific to each subscriber on the data line, and without requiring the periodic physical delivery or the secure electronic transmission of secret keys to the various subscribers on the data line. According to the Diffie Hellman scheme, two hosts can create and share a secret key without ever communicating the key. Each host receives the “Diffie-Hellman parameters”. A prime number, ‘p’ (larger than 2) and “base”, ‘g’, an integer that is smaller than ‘p’. The hosts each secretly generate their own private number, called ‘x’, which is less than ‘p−1’. The hosts next generate a respective public key, ‘y’. They are created with the function: y=gx mod p. The two hosts now exchange their respective public keys (‘y’) and the exchanged numbers are converted into a secret key, ‘z’ by the following function: z=yx Mod p. ‘z’ can now be used as an encryption key in a symmetric encryption scheme. Mathematically, the two hosts should have generated the same value for ‘z’, since according to mathematical identity theory, z=(gx Mod p)x′ mod p=(gx′ Mod p)x Mod p.
A method of public-key encryption developed by Rivest, Shamir & Adelman (“RSA”), is based upon the use of two extremely large prime numbers which fulfill the criteria for the “trap-door, one-way permutation.” Such a permutation function enables the sender to encrypt the message using a non-secret encryption key, but does not permit an eavesdropper to decrypt the message by crypto-analytic techniques within an acceptably long period of time. This is due to the fact that for a composite number composed of the product of two very large prime numbers, the computational time necessary to factor this composite number is unacceptably long. A brute force attack requires a sequence of putative keys to be tested to determine which, if any, is appropriate. Therefore a brute force attack requires a very large number of iterations. The number of iterations increases geometrically with the key bit size, while the normal decryption generally suffers only an arithmetic-type increase in computational complexity. In the RSA encryption algorithm, the message (represented by a number M) is multiplied by itself (e) times (called “raising (M) to the power (e)”), and the product is then divided by a modulus (n), leaving the remainder as a ciphertext (C): C=Me mod n. In the decryption operation, a different exponent, (d) is used to convert the ciphertext back into the plain text: M=Cd mod n. The modulus (n) is a composite number, constructed by multiplying two prime numbers (p) and (q), together: n=p*q. The encryption and decryption exponents, (d) and (e), are related to each other and the modulus (n) in the following way: d=e−1 mod (p−1) (q−1), or equivalently, d+e=1 mod (p−1) (q−1). The RSA ciphertext is thus represented by the expression C=Me mod n. The associated decryption function is M=Cd mod n. Therefore, M=Cd mod n=(Me mod n)d mod n, indicating that the original message, encrypted with one key, is retrieved as plain text using the other key. To calculate the decryption key, one must know the numbers (p) and (q) (called the factors) used to calculate the modulus (n).
The RSA Algorithm may be divided, then, into three steps: (1) key generation: in which the factors of the modulus (n) (the prime numbers (P) and (q) are chosen and multiplied together to form (n), an encryption exponent (e) is chosen, and the decryption exponent (d) is calculated using (e). (p), and (q). (2) encryption: in which the message (M) is raised to the power (e), and then reduced modulo (n). (3) decryption: in which the ciphertext (C) is raised to the power (d), and then reduced modulo (n).
Micali, U.S. Pat. Nos. 6,026,163 and 5,315,658, teach a number of split key or so-called fair cryptosystems designed to allow a secret key to be distributed to a plurality of trusted entities such that the encrypted message is protected unless the key portions are divulged by all of the trusted entities. Thus, a secret key may be recovered, through cooperation of a plurality of parties. These methods were applied in three particular fields law enforcement, business auctions, and financial transactions. Essentially, the Micali systems provide that the decryption key is split between a number (n) of trusted entities, meeting the following functional criteria: (1) The private key can be reconstructed given knowledge of all n of the pieces held by the plurality of trusted entities: (2) The private key cannot be guessed at all if one only knows less than all (<n−1) of the special pieces and (3) For i−1 , . . . n, the ith special piece can be individually verified to be correct. The special pieces are defined by a simple public algorithm which itself exploits the difficulty in factoring large numbers as a basis for asymmetric security.
Micropayments are often preferred where the amount of the transaction does not justify the costs of complete financial security. In the micropayment scheme, typically a direct communication between creditor and debtor is not required; rather, the transaction produces a result which eventually results in an economic transfer, but which may remain outstanding subsequent to transfer of the underlying goods or services. The theory underlying this micropayment scheme is that the monetary units are small enough such that risks of failure in transaction closure is relatively insignificant for both parties, but that a user gets few chances to default before credit is withdrawn. On the other hand, the transaction costs of non-real time transactions of small monetary units are substantially less than those of secure, unlimited or potentially high value, real time verified transactions, allowing and facilitating such types of commerce. Thus the rights management system may employ applets local to the client system, which communicate with other applets and/or the server and/or a vendor/rights-holder to validate a transaction, at low transactional costs. Often, a micropayment involves a cryptographic function which provides a portable, self-authenticating cryptographic data structure, and may involve asymmetric cryptography. As will be clear from the discussion below, such characteristics may permit micropayments to be integrated as a component of the present invention, or permit aspects of the invention to operate as micropayments. The following U.S. Patents, expressly incorporated herein by reference, define aspects of micropayment, digital certificate, and on-line payment systems: 5,999,919; 5,930,777; 5,857,023; 5,815,657; 5,793,868; 5,717,757; 5,677,955; 5,839,119; 5,915,093; 5,937,391; 5,933,198; 5,903,880; 5,903,651; 5,881.277; 5,960,083; 5,963,921; 5,996,076; 6,016, 181; 6,018,724; 6,035,102; 6,049,786; 6,019,787; 6,058,381; 6,061,418; 5,987,132; 6,057,872; 6,061,665; 1,977,595 5,224,162; 5,237.159; 5,392,353; 5,621,201; 5,623,547; 5,679,910; 5,696,908; 5,751.939; 5,768.385; 5,799,087; 5,812.668; 5,828,810; 5,832.089; 5,850, 416; 5,889,862; 5,889,863; 5,898,151; 5,901.229; 5,920,629; 5,926,518; 5,943,121; 5,949,015; 5,952,638; 5,963,648; 5,978,840; 5,983,208; 5,987,140; 6,002,767; 6,003,765; 6,021,399; 6,026,379; 6,029,150; 6,029,151; 6,047,067; 6,047,887; 6,055,508; 6,065,675; and 6,072,870. See also, Rivest and Shamir, “PayWord and MicroMint: Two Simple Micropayment Schemes” (May 7, 1996); Micro PAYMENT transfer Protocol (MPTP) Version 0.1 (22-Nov.-95) et seq., www.w3.org/pub/WWW/TR/WD-mptp: Common Markup for web Micropayment Systems, www.w3.org/TR/WD-Micropayment-Markup (09-Jun.-99).
A type of cryptographic algorithm is known, called “proxy key cryptography”, which provides means for converting a cryptographic transform between a first transform associated with a first set of keys, and a second cryptographic transform associated with a second set of keys, without requiring an intermediate decryption of the information. Therefore, for example, such an algorithm could be used to convert the decryption key of a secret record from an original format to a distribution format. See, U.S. Pat. Nos. 7,181,017; 6,937,726; 6,859,533; 6,779,111; 6,687,822; 6,587,946; 20020073202; See also:
In typical proxy key systems, a proxy receives a private key from a sender of an asymmetrically encrypted message, and a public key from a recipient of the transformed encrypted message, and computes a transform key (e.g., a product of p and q in an RSA type PKI algorithm) which is applied to the asymmetrically encrypted message. The application of the transform key allows the recipient to use its private key to decrypt the message. As discussed in U.S. 6,937,726, other types of algorithms and cryptographic schemes may also be applied with similar function. In these architectures, the proxy is provided with the decryption key for the original message, and thus is in a position to delegate its right and authority to decrypt the message to the recipient.
Asymmetric key encryption may be employed to provide the establishment of secure communications channels involving an intermediary, without making the intermediary privy to the decryption key or the message. Thus by transmitting only relatively unprivileged information, such as respective public keys, the information and integrity of the system remains fairly secure. In order to provide a three-party transaction in which the intermediary is a necessary party, the information sought to be transmitted is subjected to a secret comprehension function (e.g., a cryptographic or steganographie function) with the key known only to the intermediary. In establishing the communication channel, the information is transcoded between a first comprehension function and a second comprehension function without ever being publicly available. Modulo arithmetic is both additive and multiplicative, thus, using the same modulo n:
(Ax mod n-Ay mod n)mod n=Ax+y mod n;
((A)mod n+(B)mod n)mod n=(A+B)mod n.
((A)mod n·(B)mod n)mod n=(A·B)mod n.
(Ax mod n)y mod n=(Ay mod n)x mod n=Axy mod n
An algorithm that permits a blockchain and its associated processing to serve as a reliable, yet untrusted intermediary relies on, e.g., the multiplicative property of modulo arithmetic; in other words, A mod B*C mod B=(A*C) mod B. However, this property is not “reversible”, in that knowledge of (A*C) mod B and either A or C does not yield the other, unless the product A*C is less than B, since the modulo function always limits the operand to be less than the modulus value. Thus, it is seen that in an RSA scheme, M=Cd mod n=(Me mod n)d mod n. Therefore, in order to communicate the intermediary private information to the intended recipient, the recipient public key ‘e1’ and intermediary private key ‘d2’ are defined using the same modulus n, multiplied, and provided to the sender. At the sender, the ciphertext C2=Me2 Mod n, previously encrypted with the intermediary's public key e2, is subjected to the function: C1=C2d2e1 mod n=Me1 mod n. The recipient may then apply its private key d1 to decrypt the message: M=C1d1 mod n. It should be understood that the algorithm described herein represents merely a portion of an RSA-type public key infrastructure, and that generally all known techniques for preparing the message, maintaining a public key directory, and the like, may be employed in conjunction therewith, to the extent not inconsistent. Thus, the transcoding algorithm should be considered as a generally interchangeable part of the entire cryptographic system, which may be substituted in various known techniques, to achieve the advantages recited herein. In general, only small changes will be necessary to the systems, for example, accommodating the larger composite key length. It is also particularly noted that there are a number of known barriers to exploits that are advantageously employed to improve and maintain the security of the present system and method. Similarly, other transitive functions may also be employed in analogous fashion to build partially homomorphic cryptographic processing, which may be implemented using distributed consensus technologies, such as proof of work, or proof of stake, distributed blockchain transaction processing. Of course, the implementation need not be distributed. See, David Chaum, “Blind Signatures for Untraceable Payments”, Proceedings of Crypto 82, August 1982, p. 199-203. According to the Chaum scheme, a server assists a user in decrypting a message without releasing its secret key or gaining access to the encrypted message. The user communicates a symmetric function of the ciphertext to the server, which is then processed with the secret key, and the resulting modified ciphertext returned to the user for application of an inverse to the symmetric function. See, U.S. Pat. No. 6,192,472.
According to an embodiment of the present invention, a source privy to the communication employs a public key encryption paradigm to require that for comprehension of an encrypted message, at least two keys are required, with all of the predefined keys being required to decrypt the message, and with no apparent relation between the keys making prediction of one key part difficult or impossible based on the corresponding other key part(s) and the ciphertext message. Thus, at least three parties must cooperate to transmit a message, the sender, the recipient, and a third party holding a necessary key part. This results in an ability to audit and log communications without giving access to confidential information to the auditor. This also facilitates economic transactions, since the communication of the missing key information provides an opportunity for a mandatory third party accounting.
The transaction for conveying the information need not occur in real time or near real time, and therefore this technology may maintain a secret for a period of time, and then at a later time, when the required information becomes available, the secrecy is waived. In accordance with the present invention, the identity of the token holder (or original token holder) may be maintained as a cryptographically protected secret, which is revealed in certain circumstances. For example, so long as a debt is not in default, the debtor's identity remains unknown. However, a smart contract may execute based on a proven event of default, to release the identity of the debtor, or original debtor. In practice, this is in part a split key escrow, but with the possibility of chained algorithmic execution to provide layers of encryption.
Using this scheme, the original ciphertext encryption key and recipient private key need never be disclosed, and thus may each be retained for use over an extended period. The session encryption key, however, will vary with each message. It is noted that, since the intermediary holds the decryption key for the record, it may, in exceptional circumstances and in cooperation with the repository, decrypt the plaintext message. Therefore, it is seen that, even if a user fails to comply with the required access rules, desired information is not lost, locked or completely unavailable. Rather, the intermediary (or trustee) may be given the discretion to release the records or to request release of the records during an emergency. The scheme may be employed to securely communicate cryptographic codes between parties to a communication, for example a symmetric encryption key. For example, the Advanced Encryption Standard (AES) employs the Rijndael algorithm, which may provide highly efficient encryption and decryption. Thus, the asymmetric key encryption may be directed principally toward key exchange. According to another embodiment of the invention, an encrypted message (ciphertext) is “transcoded” from a first encryption type to a second encryption type, without ever passing through a state where it exists as a plaintext message. Thus, for example, an intermediary to the transaction who negotiates the transaction, need not be privileged to the information transferred during the transaction. In the case of medical records, therefore, this means that the intermediary need not be “trusted” with respect to this information. A preferred embodiment of the technology provides composite key asymmetric cryptographic algorithms to, among other advantages, avoid revealing a plaintext message during intermediate processing. However, it is also possible to employ symmetric key cryptography, especially since the remote key handler is a privileged environment, and may be provided with sufficient security to abate the risk of message disclosure. Further, in some embodiments, the system risks attendant in releasing both the permanent encryption key along with the ciphertext are insubstantial, and therefore a transcoding or transcription process is not required. These various embodiments are encompassed by the present invention.
The following identities characterize the known RSA algorithm: C=Me mod n and M=Cd mod n. For the complete transformation, the relationship is as follows: M=Cd mod n=(Me)d mod n. According to the present invention, it is desired to transform ciphertext 1 (C1) into ciphertext 2 (C2), in a secure manner without ever revealing the plaintext message during the process. In order to achieve this transformation from C1 to C2, the process is consolidated. Thus, the decryption according to a first decryption key M=C1d1 mod n and the reencryption according to a second decryption key C2=Me2 mod n are combined into a single transcription operation, C1d1−e2 mod n=We mod n=C2. So long as the factors of d1·e2 remain secret, it is infeasible to factor thus number, and thus this transformation inherits the advantages of the RSA encryption scheme. Thus, the plaintext message remains secure through this transformation. In fact, because the transformation is integral, relatively low security is required for the starting and transformed ciphertext, and the crypto-processor itself. This process also lends itself to three (or more) party transactions, wherein each party is a required participant (maintains secret information necessary for the communication) but only an intended recipient (user) has access to the plaintext message. Accordingly, if a transaction intermediary supplies a transcoding or transcription key to the message repository, comprising at least two secret components (so that the composite key may not be factored), an existing ciphertext may be transformed into a new ciphertext. While the components of the composite transcode key are secret, due to the nature of public key systems, these are insufficient for the intermediary to gain access to the message. The two secret components include a key specific for the user, and a key specific for the existing encryption of the message ciphertext. The resulting transformed ciphertext is therefore a public key encrypted message for the user, which can only be decrypted with the user's private key. In order to maintain the security of the original message against subsequent uses, it is preferred that the user's public key-private key pair be a session key, that is accounted for and used only for the single transmission and subsequently discarded. The “public” portion of the session key pair is transmitted by the user to the intermediary, which is held in secrecy and multiplied by the private key for the existing ciphertext message. In this way, the intermediary has no knowledge of the “private” session key, and cannot itself intercept the communication.
Consider encoding schemes of the following type. An encoding system consists of four components: (i) a message space X which is a collection of possible messages. (ii) a key space k which is a set of possible keys (iii) a computationally efficient encoding transformation E:K·K→X and (iv) a computationally efficient decoding transformation D: K·X→X. For each k & k, the encoding transformation Ek:X→X and decoding transformation Dk:X→X are injection (one-to-one) mappings on X. and they satisfy that, for every message xεX, Dk(Ek(x)=x. Certainly, such defined encoding schemes can be varied in several ways to cover a wider range of ones. One is to differentiate the space of encoded messages from the one of original messages and another is to consider that keys used for encoding and decoding are different. In terms of cryptography, the encoding schemes considered below are essentially private-key (or, more precisely, symmetric), endomorphic cryptosystems. Such defined encoding schemes have some advantageous properties. Given an encoding scheme (X, K, E, D), each encoding transformation and its corresponding decoding transformation are inverse transformation of each other; that is, for each kεK. Dk=(Ek)−1 and Ek=(Dk)−1. If X is a finite set, each encoding or decoding transformation is just a permutation on X.
In a multiplicative scheme M, a message in this scheme is an element in X=Zn={0, 1, . . . , n−1} for some integer n>0. A key is also an element a in Z, but satisfying gcd(a, n)=1, where the “gcd” function specifies the greatest common integer divisor of the two arguments. That is, the key space K consists of the elements in the multiplicative group Zn*={a∈Zn 1gcd(a, n)=1}. The encoding of a message x with a key a is y=Ed(x)=ax(mod n) and the decoding of a message y with a key a is x−Dd(y)=a−1y(mod n), where a is the multiplicative inverse of a modulo n; that is, a−1 is an element in Z such that a·a−1 (mod n)=a−1·a(mod n)=1. Note that the condition on a, gcd(a, n)=1, is used to guarantee that a has the inverse a−1. It is known that the number of such as is equal to the value of the Euler phi-function
where
is the prime decomposition of n. So the number of keys in the scheme M is φ(n).
Shift Scheme S. Messages and keys of the shift scheme, are all elements in Zn={0, 1, . . . , n−1} for some integer n>0; that is N=K=Zn. Thus, the number of messages and the number of keys in the shift scheme are all equal to n. To encode a message x with a key b, one calculates y=Eb(x)=x+b(mod n) and to decode a message y with b, one computes x=Db(y)=y−b(mod n).
Substitution Scheme P. This scheme is also defined over X=Z However, the key space K=II, consists of all permutations of elements in Zn. Thus, the total number of keys is n′. For each permutation pεΠn, the encoding is y=Eb(x)=p(x) while the decoding is x=Dp(y)=p−1(y), where p−1 is the inverse permutation of p. It should be noted that the multiplicative and shift schemes are special cases of the substitution scheme which include only φ(n) and n of the n! possible permutations of n elements, respectively.
New encoding schemes can be constructed by combining existing ones. One way is to form their “product.” Suppose S and S′ are two encoding schemes with the same message space X. The product of S and S′, denoted by S·S′, has the same message space X. A key of the product scheme has the form (k, k′), where k and k′ are keys of S and S′, respectively. The encoding and decoding transformations of the product scheme are defined as follows for each key (k·k′)εk, E(k,k′)=Ek′(Ek(x)) and D(k,k′)(x)=Dk(D′k(c)). That is the message x is first encoded with Ek, and the resulting message is then “re-encoded” with Ek′. Decoding is similar, but it is done in the reverse order. It is straightforward to check that the product construction is always associative: (S·S′)·S″=S·(S″·S″). If an encoding scheme S is taken to form the product with itself, one obtains the scheme S·S, denoted by S2. If the n-fold product is taken, the resulting scheme, denoted by Sn, is called an iterated encoding scheme. A simple example to illustrate the definition of product encoding schemes is as follows. Affine Scheme A. This scheme is also defined over K=Zn. A key of the affine scheme is a pair of integers (a, b) in Zn, where gcd(a, n)=1. The encoding transformation is y=E(a,b) (x)=(ax+b)(mod n) and the decoding transformation is x=D(a,b)(y)=a−1(y−b)(mod n), where a−1 is the modular inverse of a modulo n. These transformations of the type ax+b are usually called affine transformations, hence the name affine scheme. Note that the scheme A reduces to the multiplicative scheme M when b=0 and the shift scheme S when a=1. Thus, M and S are special cases of A. On the other hand, A is their product M·S. As seen before, a key in the multiplicative scheme M is an element aεZ*n; the corresponding encoding transformation is Ea (x)=ax (mod n). A key in the shift scheme is an element bεZ, and the corresponding encoding transformation is Eb(x)=x+b (mod n). Hence, a key in the product scheme M·S has the form (a,b)εZ*n·Zn, and its encoding is E(a,b)(x)=Eb(Ea(x))=ax+b(mod n). This is precisely the definition of the encoding transformation in the affine scheme. Similarly, the decoding transformation in the affine scheme is the composition of the decoding transformations of the shift and multiplicative schemes.
The objective of transferring the right to decode messages in any given encoding scheme (X, K, E, D) can be stated as follows: for any given message xεX and keys k,k′εk, convert in some efficient way the encoded message y=Ek(x) using the key k into the encoded message y′=Ek′(x) using the key k′ so that the new message y′ can be decoded correctly using the key k′. If this can be achieved, it is said that the right to decode the message y has been transferred or delegated from the key holder of k to the key holder of k′. In many cases, the key space K of an encoding scheme is not merely a set. Equipped with some operation “*”, K may possess some mathematical structure. For instance, the key spaces of all the example schemes given in the previous section can be equipped with some operations to become mathematical groups. Table 1, below, shows some of these operations, where ∘ stands for the composition operator of permutations and *: (Zn*×Zn)(Zn*×Zn)→Zn*×Zn is defined as (a,b)*(a′*b′)=(a′a)(mod n), a′b+b′(mod n)).
When the key space K of an encoding scheme (X, K, E, D) is a group with some operation “*”, the encoding and decoding transformations may be uniquely determined by the keys. This happens when the key space K is isomorphic, as a group, to the transformation groups E={Ek|kεK} and D={Dk|kεK} formed by the encoding and decoding transformations on the message space X; that is, for any k,k′εK. Dk=(Ek)−1=Ek
Key-determined encoding schemes permit a systematic way to transfer the right to decode messages from one key holder to another. With the isomorphism between the key space and the transformation groups, the composition of the decoding transformation with one key k and the encoding transformation with another key k′ can then be viewed as the encoding transformation determined by the composed key k−1·k. Let (X, K, E, D) be a key-determined encoding scheme. Suppose y=Ek(x) is the encoded version of the message xεX with the key kεK. The right to decode the encoded message of x can be transferred from the key holder of k to the key holder of k′ in a two-step algorithm. First, generate a transfer key t=k−1·k. Then encode the message with the transfer key t according to y′=Et(y). The algorithm is correct thanks to the property of the key space being isomorphic to the encoding and decoding transformation groups. The correctness can be verified as follows:
Dk′(y′)=Dk′(Ek(y))=Dk′(Ek
The generality of the algorithm makes it immediate to derive the transference steps for the example schemes set forth above. For the XOR Scheme X over Bn, to convert y=Ek(x) to y′=Ek′(x), first generate a transfer key t=k⊕k′. Then encode the message with the transfer key t according to y′=y⊕t. For the Multiplicative Scheme M over Z*n to convert y=Ea(x) to y′=Ea′ (x), first generate a transfer key t=a′a−1 (mod n). Then encode the message with the transfer key t according to y′=ty (mod n). For the Shift Scheme S over Zn, to convert y=Eb(x) to y′=Eb′(x), first generate a transfer key t=b′−b (mod n). Then encode the message with the transfer key t according to y′=y+t (mod n). For the Substitution Scheme P over πn, to convert y=Ep(x) to y′=Ep′ (x), first generate a transfer key t=p−1∘p′. Then encode the message with the transfer key t according to y′=t(y).
As will be described below, it is also possible to transfer the right to decode in product schemes of not only key-determined encoding but also commuting schemes. In order to define commuting schemes, it is necessary to characterize encoding schemes that are essentially equivalent. Suppose that S=(X, K, E, D) and S′=(X, K′, E′, D′) are two encoding schemes with the same message space X. S is said to be equivalent to S′, denoted by S≡S′, if there is a bijective (one-to-one and onto) mapping h:k→K′ such that for each message XεX and for each key kεK,
Ek(x)=Eh(k)′(x) and Dk(x)=Dh(k)′(x).
Clearly, the scheme equivalence relation ≡ is an equivalence relation; that is, it satisfies that, for any encoding schemes S, S′, S″, the following hold: (i) S≡S; (ii) S≡S′ implies S′≡S; and (iii) S≡S′ and S′≡S″ imply S≡S″. Thus, equivalent encoding schemes form an equivalence class in that each scheme in the class provides no more and no less functionality than any others in the class. The scheme equivalence relation allows one to characterize encoding schemes in several ways. An encoding scheme S is said to be idempotent if S2≡S. Many of the encoding schemes are idempotent, including the XOR, multiplicative, shift, substitution, and affine schemes. If a scheme Sis idempotent, then there is no point in using the product scheme S2, as it requires an extra key but provides no more functionality. Another characterization on encoding schemes using the scheme equivalence relation ≡ is that of commuting schemes. Two encoding schemes S and S′ are said to commute if S·S′≡S′·S. Trivially, any scheme commutes with itself. A not-so-trivial example is that of the multiplicative scheme M and the shift scheme S. To see that they commute, i.e., M·S≡S·M, one can compare the equations Eb(Ea(x))=ax+b(mod n) and Ea(Eb(x))=ax+ab(mod n) and find out that the mapping h:KS×KM→KM×KS defined by h(b,a)=(a, a−1b(mod n)) makes the product S·M isomorphic to the product M·S. Product schemes of key-determined and commuting encoding schemes enjoy a systematic way of transferring the right to decode messages. Let S1·S2 be the product scheme of two key-determined and commuting encoding schemes. Suppose that h=(h1, h2):K2·K1→K1·K2 is the mapping that makes S2·S1 isomorphic to S1·S2, where h1:K2K1→K1 and h2:K2K1→K2. First, observe that the product scheme is also key-determined; the product key space K1·K2 is a group with respect to the operation * defined by (k1, k2)*(k1, k2)=(k1·h1(k2, k1′), h2(k2, k1′)·k2′) This is because
E(k
Now, the right to decode the encoded message of x can be transferred from the key holder of k to the key holder of another key k′ in the two-step algorithm. First, generate a transfer key t=(h1(k2−1,k1−1·k′1), h2(k2−1,k1−1·k′)·k′2). Then encode the message with the transfer key t according to y′=Et(y). The correctness of the transference algorithm is verified by the following equality:
where the last entity can be readily decoded using the key k′=(k′1, k′2).
The method is best illustrated with the following example, applying the affine cipher A over Zn. Since A=M·S. and M and S are key-determined, commuting schemes, the method described above applies to the affine scheme. As seen before, it is the mapping h(b, a)=(a, ab) that makes S·M isomorphic to M·S. Thus, h1(b, a)=a and h2(a, b)=ab (mod n). The transfer key t from (a, b) to (a′, b′) can be derived as
t=(h1(b−1,a−1·a′),h2(b−1,a−1·a′)·b′)=(a′·a−1,h,(b−1,a−1·a′)·b′)=(a′a−1,−a′a−1(b+b′)
Then, to decode y using a second key (a′, b′), first generate a transfer key t=(a′a−1(mod n),−a′a−1b+b′(mod n)≙(t1,t2). Then encode the message using the transfer key t according to y′=t1 y+t2 (mod n). The methods presented herein for transferring the right to decode messages are transitive. This means that two sequential transfers from Alice to Bob and then from Bob to Carol are equivalent to a direct transfer from Alice to Carol. It is important to note that, in each of the example schemes, a transfer key is also a key of the scheme. Accordingly, two transfer keys used in the two sequential transfers can be combined to form a transfer key for the direct transfer. Take the affine scheme as an example. Let k=(a, b), k′=(a′, b′), and k″=(a″, b″) be the keys for Alice, Bob, and Carol, respectively. Then the transfer keys are t=(a′a−1, −a′a−1b+b′) from Alice to Bob, t′=(a″a′−1,−a″a′−1 b′+b″) from Bob to Carol, and t″=(a″a−1, −a″a−1b+b″) from Alice to Carol. It is straightforward to verify that the composition of t and t′ as keys in the affine scheme yields t″:
t·t′=(t′t1,t1′t2+t2′)=(a″a′−1)(a′a−1),(a″a′−1)(−a′a−1b+b′)+−a″a′−1b′+b″)=(a″a′−1,−a″a′−1b+b″)=t″
In other words, the composition of sequential transfers of the right to decode messages is memory-less; all the intermediate transfers will not be reflected in the overall transfer. It should be noted also that, for the schemes X, M, and S, the transfer key generation step is equivalent to “decoding” k′ with k. Thus, the computation needed in the transfer is the same as the one used in the decoding-and-re-encoding method for these schemes. One may think that the new method shows no improvement in this efficiency regard, but it has been found that the transfer key is message-independent and hence needs to be computed only once. When the number of messages m involved in the transfer increases, this feature will cut the computation required by the re-encoding method by half. Moreover, the transfer key t does not leak any useful information on the keys k and k′, and a transfer performed according to the methods set forth herein will not reveal the message x. These properties make the proposed method appealing when the security of the message x and the decoding keys k and k′ is an issue during a transfer.
The goal of proxy encryption is to delegate the decryption right from one to another in secure and efficient ways. For the discussion that follows, it is convenient to define the roles of parties that may be involved in proxy encryption. The two most important roles are those of grantor and grantee. A grantor is an original key holder of encrypted messages who wants to delegate the decryption right to someone else. A grantee is a key holder designated to perform decryption on behalf of a grantor and thus act as grantor's decryption proxy. In the motivating example in the introduction, Alice is the grantor while Bob is the grantee. Other roles may include an encryptor who is the one that originally encrypts messages for the grantor, and a facilitator who may help to perform some message processing tasks, such as transforming messages encrypted for the grantor into messages encrypted for the grantee. Certainly, it is not necessary that all these roles are played by different parties. For example, a party may play roles of the grantor and facilitator, as in the Mambo and Okamoto schemes discussed below. With these roles in place, a proxy encryption scheme is just a description of how a grantee, possibly with some aid from a facilitator, delegates a grantee the right to decrypt messages originally generated by an encryptor for the grantee. A proxy encryption scheme may consist of four generic steps message encryption, proxy key generation, proxy transformation and message decryption. These steps will be described in further detail below.
1. Message encryption E The encryptor generates an encrypted message using grantor's encryption key and delivers it to the grantor.
2. Proxy generation π: To delegate the decryption right to the grantee, the grantor generates a proxy key π as a commitment token that allows the grantee to decrypt the message encrypted for the grantor.
3. Proxy transformation π: When necessary, the facilitator performs a proxy transformation π, possibly using the proxy key π, to convert the message encrypted for the grantor to a message encrypted for the grantee.
4. Message decryption D: Upon receiving the transformed message and possibly the proxy key π, the grantee decrypts the message.
Accordingly, it should be observed that the generic scheme above covers the two straightforward solutions to proxy encryption mentioned in the introduction. The re-encryption scheme is a special case where the grantor (Alice) is also the facilitator who actually decrypts the message and then encrypts for the grantee (Bob), and the proxy π can be considered as a collection of grantor's decryption key and grantee's encryption key, which is used only by the grantor and not by the grantee. The scheme of passing grantor's decryption key to the grantee is another special case of the generic scheme, where the proxy key is the decryption key and the proxy transformation is the identity transformation. However, not all schemes that can be derived from the generic one above are qualified as proxy encryption schemes Intuitively, a proxy encryption scheme has to satisfy some basic requirements, namely delegation, security, transitivity and performance, as described below. To ensure that, at the end of the message decryption step, the grantee is able to recover the original message correctly, the following equation must hold for any message m: D(ΠE(m, eA), π), db, π)=m, where E(m,e) is an encryption function of message m under encryption key e, D(c,d,π) is a corresponding decryption function of encrypted message e under decryption key d and possibly proxy key π, Π(e,π) is the proxy function that converts encrypted message e according to proxy key π, and ea, eb, da, and db are the encryption and decryption keys of the grantor A and grantee B, respectively.
In addition to the correctness above, the functionality of delegation should be guaranteed. In one form, this means that, after the proxy key is issued and the proxy transformation is completed, the message decryption step should require no private information from the grantor, and it should be carried out solely by the grantee. In another form, this is equivalent to undeniability of the delegation from the grantor; that is, once the proxy key is created and proxy transformation is performed, the grantor should not be able to deny the delegation, without seeking other means such as preventing the grantee from obtaining the proxy key and receiving the transformed message. As a consequence of this functionality, the grantor's decryption key can be destroyed with grantee's decryption key and possibly the proxy key maintaining the ability to decrypt the message.
In essence, a proxy encryption scheme is also an encryption scheme at least from the grantee's point of view. The introduction of proxy keys and transformations must in no way com-promise security and privacy of the encryption. Thus, it should be at least computationally hard for any unauthorized third party to recover the original message and decryption keys of the grantor and grantee from publicly available information. Moreover, forging valid proxy keys by any untrusted party should be very hard. It must be clear, though, that generating the proxy key π requires knowledge of at least the decryption key of the grantor; otherwise the underlying encryption system is not secure. Naturally, the proxy relationship should be transitive. After the grantor delegates the decryption right, the grantee should be able to act as a new grantor to delegate the right further to another grantee, by just following the same scheme. Moreover, it should be possible for someone, say the first grantor, to delegate the right directly to a new grantee by combining all intermediate proxy keys into one proxy key and composing all consecutive proxy transformations into one transformation. As the re-encryption scheme is an intuitive, straightforward solution to proxy encryption and it satisfies the above delegation, security and transitivity requirements, any practically useful proxy encryption scheme should have no degradation in computational performance when compared with the re-encryption scheme. Proxy encryption schemes may vary according to their application requirements. They can be categorized according to many aspects. Obvious ones include whether they are public-key or private-key based, and whether their security measures are perfect in the information theoretical sense or rely on intractability of some computational problems. The following aspects are related to the proxy key and transformation. While secrecy of messages and decryption keys has to be enforced, secrecy of proxy keys and proxy transformations may not be a mandatory requirement. A scheme is called public if proxy keys it generates may be published without compromising its security and proxy transformations applied in untrusted environments; otherwise, the scheme is private. In a private scheme, when a proxy key is transferred from the grantor to the facilitator and grantee, care must be taken to protect the proxy key from disclosure. As a result, the proxy transformation which uses the proxy key must be performed in private as well.
In terms of messages, the grantee must be unconditionally trusted by the grantor, since proxy encryption by definition allows the former to decrypt on behalf of the latter. However, the trust model may be different for their private information. A proxy encryption scheme is commutative if the grantor and grantee have to trust each other with regard to their private keys otherwise, it is non-commutative. A commutative example is that the proxy key is such created that either one of the grantor and grantee can obtain other's decryption key from it. Whenever this is the case, the proxy encryption mechanism may be simplified to a key exchange protocol that allows the grantee to use grantor's decryption key to decrypt the encrypted messages directly. Generality. In many cases, the grantor wants to restrict the scope of the delegated decryption right. Often intended restrictions include that the proxy key may only be used by a designated grantee, that the proxy key may only be applicable to a specific message, or that the proxy transformation may only be applied by a specific facilitator. For example, when a proxy encryption scheme is used in some applications like key escrow, it would be ideal that proxy keys are independent of messages they will apply to. But for occasional delegation such as securely specifying inheritance in someone's will, it may be highly desirable that a proxy key can only be restricted to a designated party (e.g., a grandchild), applicable to a specific message (e.g., some portion of the will) and possibly used in the proxy transformation by a particular party (an attorney). When used in the extreme situation where the grantor and grantee are a same person with a same decryption key, a proxy encryption scheme should reduce to a regular encryption scheme, without introducing any complications (such as non-trivial proxy keys and transformations, and the requirement of an extra facilitator).
Encryption schemes based on discrete logarithms are particularly advantageous because of their technical advantages over RSA-type schemes and their natural generalizations to many finite groups such as elliptic curve groups over finite fields. For any natural number n, let Zn={0.1, . . . , n−1} denote the ring of integers modulo n, and let Z*n={mεZn|gcd(m,n)=1} denote the multiplicative group of Zn. Note that, when n is a prime. Z*n={1, . . . , n−1}. For a modulo n and a number a that is relatively prime to n, let a−1 denote the multiplicative inverse of a modulo n; that is, a−1 is the element that satisfies aa−1=1(mod n). An element a of Z*p is said to be of order m if the number of its powers modulo n is m. A generator g of Z*n, if it exists, is an element of order |Z*n| (the size of Z*n); in this case, Z*n is a cyclic group. When n is a prime, every element of Z*n except 1 is a generator of Z*n. Let Z*n be a cyclic group with a generator g. The discrete logarithm of an element x to the base g, denoted as log.sub.g x, is the unique integer a, 0<a<n−1, such that x=ga (mod n). The discrete logarithm problem is that, given a prime p, a generator g of Z*p, and an element X εZ*p, find the integer a. 0<a<p−2, such that ga=x(mod p).
A very closely related problem is the Diffie-Hellman problem: given a prime p, a generator g of Z*p, and elements ga(mod p) and gb(mod p), find gab(mod p). The discrete-logarithm problem is at least as hard as the Diffie-Hellman problem, because any solution to the former problem can be used to solve the latter problem. The ElGamal encryption scheme is a part of a discrete-logarithm based, public-key cryptosystem proposed by ElGamal for both encryption and digital signature. See T. ElGamal, “A public key cryptosystem and a signature scheme based on discrete logarithm,” IEEE Trans on Information Theory, Vol. 31, pp. 165-172 (1985). The ElGamal scheme is set up by establishing two public parameters p and g, where p is a prime (typically 512 bits in length), such that p−1 has a large (typically 160 bit) prime factor q (e.g., p=2q+1) and g is a generator in Z*p. A private key for a user is set by uniformly choosing a random number a εZ*p−1. Its related public key is calculated as a=ga(mod p). The user publishes a and keeps a secret. To encrypt a message m to be sent to user A with public key a, a random number kεZ*p−1; is uniformly chosen, and a pair of numbers (r,s), together representing the encrypted message to be sent to A, is calculated as follows r=gk (mod p) and s=mak (mod p). To decrypt the message (r,s), the recipient A recovers the message m by calculating m=s(ra)−1(mod p). Note that the selection of the public parameters is intended to establish equation gp−1 (mod p)=1 (Fermat's little theorem). These parameters should be authentically known to all users. They can be chosen, say, by some trusted authority. Also, the way that private key a is chosen ensures that the inverse a−1 of a modulo p−1 exists and is unique.
Unlike the RSA public-key encryption scheme, the ElGamal scheme is non-deterministic, since the encrypted message also depends on the random number k. Indeed, it is similar in nature to the Diffie-Hellman key exchange protocol; the key established between the sender and receiver for encrypting and decrypting the message m is gak (mod p) from r=gk(mod p) (part of the encrypted message) and a=ga(mod p) (the public key of A). Nevertheless, the security of the ElGamal encryption scheme relies on the intractability of the discrete logarithm problem and the Diffie-Hellman problem. To date, practice in seeking optimal algorithms for the discrete logarithm problem has not found any efficient (polynomial-time) solution. It is similar to the situation for the integer factorization problem upon which security of the RSA scheme is based. Moreover, it has also been shown that, for some primes p, solving the discrete logarithm problem is at least as hard as solving the factorization problem of a same size. This implies that for those p's the ElGamal scheme is at least as secure as the RSA scheme.
To delegate the decryption right to a grantee B, the grantor A creates a proxy key π by uniformly choosing a random number a′ εZ*p−1 and calculating π=aa′(mod(p−1). Then, A delivers the proxy key π to B in a secure manner (e.g., by encrypting it with B's public key) and keeps the value of a′ private. To allow B to decrypt the message, A calculates r′=ra′({circumflex over ( )}−1)(mod p), where a′−1 is the multiplicative inverse of a′ modulo p−1. The pair (r′, s) is the transformed, encrypted message to be sent to B. Upon receiving the transformed message (r′, s) and the proxy key T. B decrypts the message m by calculating m=s(r′π)−1 (mod p). This proxy encryption scheme uses the encryption and decryption components of the ElGamal scheme, except B's private key is replaced by the proxy key π. It is correct because, when using π to decrypt the transformed message (r′, s), the following hold s(r′)π)−1(mod p)=s(raa′a′
The security of this scheme is evaluated in two aspects. The complexity for anyone, including the grantee B, to discover grantor A's private key a based on all the available information is as same as the one for solving the discrete logarithm problem. The difficulty for anyone, even with the proxy key, to impersonate A to transform the encrypted message (i.e., to generate (r′, s) is the same as the one for solving the Diffie-Hellman problem.
This scheme has several very appealing features. First, its security implies that it is hard for B to recover A's private key. In this sense, there is no need for A to trust B, and hence the scheme is non-commutative. Second, the proxy key π generated is message-independent. B can use it to decrypt all the messages transformed by A. Third, this scheme satisfies the transitivity requirement. Upon receiving both the proxy key π and the transformed message (r′, s), the delegated user B can further delegate the proxy to another user C by treating π as the private key a and (r′, s) as (r, s) and repeating the proxy generation and transformation. Fourth, the scheme requires less computational efforts than the re-encryption scheme. However, implementing proxy encryption in the manner of this scheme has several shortcomings. First, the proxy key contains no information about the delegated grantee B; it is solely derived from grantor A's private key. Moreover, the message decryption performed by B does not need B's private decryption key either. Consequently, the message can be recovered by anyone that gets hold of the proxy key and encrypted message, not necessarily B. Thus, B can ask anyone to decrypt the message by directly passing the proxy information. In many cases, this is not desirable; A should be able to specify the key holder who is to act on A's behalf. Second, the proxy key π has to be a secret between A and B and needs to be transmitted from A to B in a secure manner: As a result of π containing no information of B and (r′, s) being possibly communicated in public, revealing π is essentially equal to disclosing the message. Third, the proxy transformation has to be conducted by A. The value a′ used in the transformation is a secret to A and it is vital to preventing B from knowing A's decryption key a. In short, the scheme is non-commutative and message-independent, but private and unable to specify the designated grantee.
Blaze and Strauss have described another public-key proxy encryption scheme, which is similar in structure to ElGamal encryption, but with the parameters used differently and the inverse of the secret used to recover the message. Given a message m that needs to be sent to a grantor A with public key a, the message m is encrypted by uniformly choosing a random number kεZ*p−1 and calculating a pair of numbers (r, s) representing the encrypted message as follows r=mgk(mod p) and s=ak(mod p). To delegate the decryption right to a grantee B, the grantor A creates a proxy key π by obtaining B's private decryption key b and computing π=a−1b(mod(p−1), where a−1 is the inverse of the private key a of A modulo p−1. The proxy key π can be made public. To use the proxy key π to convert a message (r, s) encrypted for A to a message encrypted for B, the facilitator (not necessarily A, since the proxy key π is public) computes s′=sπ (mod p). The pair (r, s′) represents the transformed encrypted message, which can then be transmitted to B. To decrypt the transformed message, B computes m=r(s′b({circumflex over ( )}−1))−1 (mod p), where b is B's private key and b−1 is the inverse of b modulo p−1. The scheme is correct, since in the message decryption s′b−1=gk(mod p) and m=r(gk)−1(mod p). The scheme is secure in that the message m and secret keys a and b cannot be recovered from the encrypted messages and public keys. Moreover, publishing the proxy key compromises neither the message m nor the secret keys a and b. More precisely, the problem of recovering m from the public information (a, ß, r, s, π, s′) is as hard as the Diffie-Hellman problem. In contrast to the previous scheme, the last security feature makes it unnecessary to keep the proxy key π private. Thus, the grantor A can publicly send π to whoever (facilitator) is to perform the proxy transformation, or can simply publish it. Moreover, the scheme does not require any secret from A in order to carry out the proxy transformation, and consequently it allows anyone, trusted or not, to perform the transformation and hence eliminates the necessity of A's, as well as B's presence in the transformation. Also unlike the previous scheme, there is no difference to the user B between decrypting a regular encrypted message and decrypting a proxy transformed message. This elegant feature allows the user B to treat all incoming encrypted messages uniformly. In fact, it is possible for an untrusted facilitator or server to perform the proxy transformation and then forward the message to the user B. In spite of these desirable features, this scheme is commutative; the involved key holders A and B must trust one another bilaterally. B can learn A's secret key a (by multiplying the proxy key by b−1). In addition, the proxy key is also message-independent, as it is in the previous scheme, which delegates B the right to decrypt all messages encrypted for A's private key a. Accordingly, this scheme is public and message-independent but commutative.
To understand how to adapt the ElGamal scheme into a proxy encryption scheme, it is helpful to examine some details of the ElGamal scheme. It should be noted that the r component of the encrypted message m is independent of the recipient A's private key a and public key a. As s=mak (mod p)=mgk a (mod p), a is only used in the s component, and a is implicitly embedded in s's exponent. Thus, it is sufficient for the proxy transformation to convert the message encrypted for A into the message encrypted for B by removing A's private key a from s and replacing it with B's private key b. In order to prevent B from obtaining A's private key a, the function to generate the proxy key must be somehow “one-way.” Indeed, this can be achieved with aid of the random number k as follows π=gk(b−a) (mod p). Consequently, the proxy transformation that completes the message conversion should look like the following: s′=sπ(mod p)=mgkagk(b−a)(mod p)=mgkb(mod p). It turns out that the proxy key and transformation satisfy the security requirement and provide desired being-public and non-commutativity features Given a message m that needs to be sent to a grantor A with public key a, the message m is encrypted by uniformly choosing a random number kεZ*p−1 and calculating a pair of numbers (r, s) representing the encrypted message as follows r=gk (mod p) and s=mak(mod p). To delegate the decryption right to a grantee B, grantor A creates a proxy key π by obtaining B's authentic decryption key b and calculating π=rb−a (mod p). The message is transformed from (r, s) to (r, s′) by calculating s′=sπ(mod p). The message m is then decrypted by B from (r, s′) by computing m=s′(rb)−1(mod p). Clearly, this scheme uses the message encryption and decryption steps of the ElGamal scheme. It is correct as the message m can be recovered from
s′(rb)−1(mod p)=sπ(rb)−1(mod p)=mgakgk(b−a)(gkb)−1(mod p)=m.
A nice feature of this scheme is that, not only do regular and proxy encrypted messages appear no different to the grantee B, but also the scheme coincides with the ElGamal scheme when A and B are the same user with the same key; in this case, the proxy value π is equal to 1 and the proxy transformation is the identity transformation. It is easy to see that the scheme is transitive. Upon receiving the proxy transformed message, the grantee B can act like the grantor A to further delegate the decryption right to, say, another grantee C by repeating the proxy generation step with the keys b and e in place of a and b. Also like the commutative scheme, the proxy generation step requires both A's and B's private keys in order to generate the proxy key π. As an alternative, this step can be carried out by anyone that is trusted by both A and B. As noted above, A's private key is definitely needed, as otherwise anyone can issue a proxy key to recover the message and the underlying encryption scheme is not secure. To establish and communicate B's private key b, many key-exchange protocols such as the Diffie-Hellman key exchange may be used. As shown in further detail below, in some practical applications the requirement of the key b either is not a problem or can be relaxed. But unlike the private and commutative schemes, this scheme does not make it easy for the grantee B to decrypt messages encrypted for A other than the intended one. Clearly, the proxy key TE contains a piece of information that is specific to the encrypted message m, namely, the random number k. In this sense, the proxy scheme is message-dependent. Moreover, the scheme is non-commutative in the sense that it is hard for B to discover A's private key a. This fact, together with the performance of the scheme will be established below. Note that, in the previous scheme, the proxy transformation only changes the s component of the encrypted message. Since s is the part that actually carries the information about the message m, the scheme may not be efficient when m is a very long message. For example, the proxy key generated would be as long as the message and the effort spent in the proxy transformation would be linear with regard to the length of the entire message. This scheme tends to improve this situation. It uses the message encryption step of the commutative scheme in which the message m is shifted from s to r. Its proxy key and transformation now have no direct dependence on the message m. Given a message m that needs to be sent to a grantor A with public key a, the message m is encrypted by uniformly choosing a random number kεZ*p−1 and calculating a pair of numbers (r, s) representing the encrypted message as follows r=mgk(mod p) and s=ak(mod p). To delegate the decryption right to a grantee B, grantor A creates a proxy key π by obtaining B's authentic decryption key b and calculating π=(sa({circumflex over ( )}−1))b−a (mod p), where a−1 is the inverse of a modulo p−1. The message is transformed from (r, s) to (r, s′) by calculating s′=sπ(mod p). The message m is then decrypted by B from (r, s′) by computing m=r(s′b( )−1)−1(mod p), where b−1 is the inverse of b modulo p−1. This scheme is correct since
Other properties of this scheme can be verified in the same way as the previous scheme.
Due to their similarity in nature, only the first of the two new schemes is analyzed in this section in regard to its security and non-commutativity. An almost same discussion can be carried out for the second scheme. In addition, though the first scheme (as well as the second scheme) is transitive and its security may involve more than two key holders, the analysis to be given only considers the two-key-holder case; the general case is also similar. For presentation clarity, the phrase “(mod p)” will be omitted in this subsection; its occurrence should be clear from context. Other than the scheme parameters (p, g), the public information available from the scheme includes a=ga, ß=gb, r=gk, s=mgak, π=gk(b−a), s′=mgbk. For the reasons set forth below, the scheme is computationally secure. It is hard to recover the message m and secret keys a and b from the public information, provided that the Diffie-Hellman and discrete-logarithm problems are hard to solve. Since the proxy key is part of the public information, this implies publishing it compromises neither the message nor the secret keys. A consequence of this is that it is also hard for anyone to forge a valid proxy key in a systematic manner. Beyond that, the scheme is shown to be non-commutative in the sense that even with B's private key, it is still hard to recover A's private key. If the proxy key is indeed generated by a third party trusted by both A and B, this fact implies that it is not necessary for B to trust A either. This is a significant improvement over the commutative scheme. Note that the total number of operations for re-encryption using the ElGamal scheme is twice the number of operations for a single ElGamal encryption and decryption, since the message must first be encrypted, then decrypted, then re-encrypted, then re-decrypted. Moreover, the computation in the second scheme can be optimized by (i) pre-computing the inverses a−1 and b−1 in the scheme setup step and (ii) multiplying the two exponential components (modulo (p−1) in the proxy generation step instead of using two exponentiations. The second set of numbers under the second scheme result from this optimization.
For example, the component r of the encrypted message can be generated using any private-key encryption scheme with k=g (mod p) as the secret session key. Accordingly, the message m can be recovered in the message decryption step by its corresponding private-key decryption using the secret session key K′=s′(b{circumflex over ( )}−1)(mod p)=K. In fact, the secret-key encryption scheme used in the scheme is r=Ek(m)=mK(mod p) for encryption and m=Dk′(r)=rK′−1 (mod p) for decryption. Another simple example is the encryption scheme based on bit-wise XOR (⊕). In this case, the computation of r and m can be replaced by r=Ek(m)=m⊕K and m=DK(r)=r⊕K. Certainly, more sophisticated private-key encryption schemes such as DES and triple-DES can be employed if stronger security is needed. The second observation is that, if the grantor A is the one who encrypts the message m, then A can keep the random number k private and use B's public key ß=gb(mod p), instead of B's private key b, to generate the proxy key: π=(ßa−1)k(mod p), where a is A's private key. This eliminates the requirement for B's private key b (or key exchange between A and B), and implies that B does not have to trust A, either. These two observations lead to a document distribution scheme, which is based on the second proxy encryption scheme discussed above. In the scheme, a private-key encryption scheme is used to encrypt the message just once for all recipients, while a less expedient proxy-key portion is used to encrypt a small amount of information—the session key-customized once for each recipient. A beneficial feature of this scheme is that the encrypted document can be stored in a publicly accessible repository, and the proxy transformation can be performed by the document owner A, the recipient B, or the repository where the document is physically stored, depending upon the needs of real document management and distribution systems. The scheme is set up the same way as a standard ElGamal scheme. In addition, a symmetric, private-key encryption scheme is selected. Its encryption function is m→Ek(m) and decryption function is r→Dk(r), where K is some private key. To encrypt a document m, owner A first chooses a uniformly random number kεZ*p−1 and calculates a session key k=gk(mod p). The encrypted document (r, s) is then calculated as follows r=EK(m) and s=Ka (mod p), where a is A's private key. A keeps the pair (s, k) private. Upon request from a recipient B for the encrypted document (r, s), A first obtains B's authentic public key B and retrieves k from the pair (s, k). A then computes πb=ßks−1 (mod p), where s−1 is the inverse of s modulo p, as the proxy key for B. The document is then transformed by computing s′=sπb (mod p); the pair (r, s′) represents the transformed document customized for B. To decrypt the customized document (r, s′) and retrieve the original document m. B first recovers the session key by calculating k=S′b({circumflex over ( )}−1) (mod p), where b−1 is the inverse of b modulo p−1. Then the document itself is decrypted by calculating m=Dk(r).
A file protection scheme may also be provided which uses a smart card to store and update decryption keys. It is again based on the second proxy encryption scheme presented herein. To encrypt a file m, a processor embedded in a smart card chooses a random number kεZ*p−1, and computes r=mgk(mod p) and s=(gk)a(mod p), where a is the smart card's private key. The pair (r, s) represents the file m in encrypted form. Whenever necessary or desired, for example every few weeks or after a predetermined number of document accesses, the smart card generates another uniform random number a′ εZ*p−1 and computes s′=(sa({circumflex over ( )}−1))a′ (mod p), where a−1 is the multiplicative inverse of a modulo p−1. The encrypted file (r, s) is then replaced with (r, s′), and the decryption key a is replaced with a new decryption key a′. These steps can be repeated as many times as desired. To recover the message m from its encrypted version (r, s), the processor on the smart card uses the latest decryption key a to compute m=ra({circumflex over ( )}−1) (mod p). Note that the file encryption step can start with any secret key it generates, not necessarily the smart card's private key. To keep encrypted files fresh by updating encryption data with a piece of smart-card-generated information helps to maintain single useful copies of protected files. This, in some sense, provides copy protection as well. Moreover, the non-commutativity of the scheme renders previous copies of the files useless as the corresponding secret information stored in the smart card has been changed (and preferably destroyed).
The Cramer-Shoup public-key cryptosystem is the first practical public-key system to be provably immune to the adaptive chosen ciphertext attack. See R. Cramer and V. Shoup, “A Practical Public key Cryptosystem Provably Secure against Adaptive Chosen Ciphertext Attack,” Proceedings of Crypto'98, Springer Verlag LNGS, vol. 1162, pp. 13-25 (1998). The adaptive chosen ciphertext attack assumes that the attacker can obtain decryptions of any chosen ciphertexts other than the target ciphertext. For example, if the target ciphertext for which the plaintext is wanted is c, then the attacker is assumed to have access to a “decryption oracle” which will decrypt any ciphertext except c, including for example c+1, 4c, etc. RSA and ElGamal fall easily to this kind of attack. A different, but equivalent, notion of security against active attacks is called non-malleability; however, known non-malleable systems are not practical. A hash-free version of the Cramer-Shoup cryptosystem, the security of which is based strictly on the Diffie-Hellman decision problem for an arbitrary group is provided. Thereafter, how to delegate the right to decrypt in a Cramer-Shoup scheme will be illustrated in two different situations. The system is set up by choosing G as a group of prime order q, where q is large. The system assumes that cleartext messages are (or can be encoded as) elements of G, and ciphertext messages are elements of G4=G·G·G·G; that is, a ciphertext message is four times as long as its corresponding plaintext message. A good example of the group G is the subgroup of order q in the multiplicative set Z*p for some large prime p=2q+1. In this case, a message m from the set {1, . . . , q} can be “encoded” by squaring it modulo p, resulting in an element in G, and the message m can be recovered from its encoding by computing the unique square root of its encoding modulo p, in the set {1, . . . , q}. A key is generated as follows. First, random elements g1, g2εG are chosen, and random elements x1, x2, y11, y12, y21, y22, y31, y32, zεZq are chosen. Next, the group elements c=g1x1 g2x2, d1=g1y11g2y12, d2=g1y21g2y22, d3=g1y31g2y32, and h=g1z are computed. The public key is then calculated to be (g1, g2, c, d1, d2, d3, h) and the private key is calculated to be (x1, x2, y11, y12, y21, y22, y31, y32, z). Given a message mεG, the encryption method begins by choosing rεZq at random. Then the ciphertext (u1, u2, e, v) is calculated as follows u1=g1′, u2=g2′, e=h′m, and v=c′d1u
The security of this cryptosystem relies upon the difficulty in solving the Diffie-Hellman decision problem. An algorithm that solves the Diffie-Hellman decision problem is a statistical test that can effectively distinguish the following two distributions: (2) random quadruples (g1, g2, u1, u2) εG4, and (b) random quadruples (g1, g2, u1, u2)εG4, where g1, g2, are random and u1=g1r and u2=g2r for some random rεZq. Related to the Diffie-Hellman decision problem are the Diffie-Hellman problem (given g, gx, and gy, compute gxy), and the discrete logarithm problem (given g and gx, compute x). Within polynomial time, the Diffie-Hellman decision problem can be reduced to the Diffie-Hellman problem which in turn can be reduced to the discrete logarithm problem. It is this relationship between the three problems that leads to the possibility of delegating the right to decrypt for the Cramer-Shoup system.
Assume that someone wants to delegate the right to decrypt from a delegator (Alice, A) to a delegatee (Bob, B). Suppose that Alice has the public key (g1, g2, c, d1, d2, d3, h) and the private key (x1, x2, y11, y12, y21, y22, y31, y32, z), and that Bob has the public key (g′1, g′2, c′, d′1, d′2, d'3, h′) and the private key (x′1, x′2, y′11, y′12, y′21, y′22, y′31, y'32, z′). Recall, that for a given plaintext message m εG, the ciphertext message for delegator A is M=(u1, u2, e, v), where u1=g1r, u2=g2r, e=hrm, and v=crd1u1rd2u2rd3er. Similarly, if the message m is directly encrypted for the delegatee B, the ciphertext message is M′=(u′1, u′2, e′, v′), where u′1=g′1r′, u′2=g′2r′, e′=h′r′m, and v′=c′r′d′1u′1r′d′2u′2r′d′3e′r′, where r′ is also a random number from Zq. Note further that v=(cd1u1d2u2d3e)r and v′=(c′d′1u′1d′2u′2d′3e′)r′. To delegate the right to decrypt from A to B involves generating a transfer key π, using that transfer key to transform M into M. In the following, it is assumed that the components g′1,g′2 of B's public key are identical to the components g1,g2 of A's public key (analogously to the ElGamal system parameters described above). Also, it is assumed that the random number r′ is the same as r. Under these two assumptions, elements u′1,u′2 of B's ciphertext message are the same as elements u1,u2 of A's ciphertext message.
A system may be set up by choosing G as a group of prime order q, where q is large. Then, as above, key is generated as follows. First, random elements g1,g2εG are chosen, and random elements x1, x2, y11, y12, y21, y22, y31, y32, zεZ are chosen. Next, the group elements c=g1x1g2x2, d1=g1y11g2y12, d2=g1y21g2y22, d3=g1y31 g2y32, and h=g1z are computed. The public key is then calculated to be (g1, g2, c, d1, d2, d3, h) and the private key is calculated to be (x1, x2, y11, y12, y21, y22, y31, y32, z). Given a message mεG, the encryption method begins by choosing rεZ at random. Then the ciphertext (u1, u2, e, v) is calculated as follows u1=g1r, u2=g2r, e=h′m and v=crd1u1rd2u2rd3er If B's private key is available for generating the transfer key Tt, that key is obtained and then scan be calculated as follows π=(ε, θ, δ1, δ2, δ3) where
The ciphertext transformation is then u1′=u1, u2′=u2, e′=eε, and v′=vθδ1u1δ2u2δ3e. This transforms the ciphertext (u1, u2, e, v) into (u1, u2, e′, v′). The recipient/delegatee is then able to decrypt the transformed cyphertext (u1, u2, e′, v′). As above, the decryption algorithm first tests if v′=u′1x′1+u′1 y′11+u′2y′21+e′y′31u′x2+u′1y′12+u′2y′22+e′y′32. If not, the decryption effort is rejected. Otherwise, the message m is calculated as m=e′/u′1z′. In the case where only the public key of the delegatee B can be used for delegating the right to decrypt the message from the delegator A to B, one needs to save and use the random number r used initially in encrypting the message for A. This may be a problem where the party to generate the transfer key is not A, and may not be a problem if the party is in fact, A. In any case, if it is available, the transfer key π can be generated using B's public key as follows: π=(ε,θ,δ1,δ2, δ3) where
The proxy transformation is then u1′=u1, u2′=u2, e′=eε, and v′=vθδ1u1δ2u2δ3e. It is straightforward to verify, in either case, that the delegatee B can use his own private key to decrypt the ciphertext (u′1, u′2, e′, v′) transformed by the methods set forth above. Since the mechanisms used herein on the Cramer-Shoup cryptosystem are the same as those used above on ElGamal-like cryptosystems, they are public and non-commutative, assuming the Diffie-Hellman problem and the discrete logarithm problem are difficult to solve.
US 20200387893, 20190013913 and WO201612082612, incorporated herein by reference, management of commitments and beneficiaries on a blockchain. They seek to enable a decentralized identification that meets the requirements of implementing “smart contract” type executable commitments [en.wikipedia.org/wiki/Smart_contract], now used in consensus protocols, particularly in a permissionless environment where anyone can join and leave dynamically, and where there is no prior knowledge of the consensus nodes, usually supported by computational puzzles [Dwork & Naor, 1992: www.hashcash.org/papers/pvp.pdf: Back, 2002: www.hashcash.org/papers/hashcash.pdf] to counter “sybil attacks” and with the theory that a major part of the calculation power is held by honest participants [Nakamoto, 2008: bitcoin.org/bitcoin.pdf]. The state of the art as regards smart contracts is mainly represented by the Ethereum system [github.com/ethereum/wiki/wiki/White-Paper]. A transactional system is proposed with peer-to-peer architecture, implementing unit of account transfer transactions between unit emitter nodes and unit receiver nodes, each incoming transaction having an input referring to an output of a previous transaction (or several inputs each referring to an output of a previous transaction) and itself having at least one new output specifying a number of units of account and a receiver node, each transaction capable of being validated in response to a broadcast, by insertion, in a blockchain stored in a distributed manner between at least some nodes, of at least one signature of the transaction, at least some nodes also being capable of exchanging units of account by transactions without compulsory broadcast via payment channels between nodes, each node having a channel (Ch(i,j) with another node possessing a ceiling (C(i,j) of units of account transferable through this channel without the need to broadcast, and a transfer of units of account between two nodes the transfer being capable of being performed via a node chain having in pairs a payment channel, characterized in that the nodes have connection weights (W(i,j) with respect to other nodes, representative of a degree of trust or proximity between the nodes or users associated with the nodes, and in that it comprises means of adjustment of the unit of account ceiling of a given node on a given channel based on a connection weight of said node with respect to the node with which it possesses said given channel.
According to the present technology, a special purpose cryptographic processing hardware module is provided, that is used to chain authentication based on primitives existing in, and/or executable on the hardware module. The module provides persistently stored, electrically erasable, non-interrogable storage of at least one cryptographic key. Because the eraseability and no-interrogability may make the bit error rate high, error correction and detection is implemented to an arbitrary high standard, e.g., no likely net errors in 10-100 years of normal use, e.g., 10 years 25 years, and 50 years. Indeed, the cryptographic functionality key may be dependent on weak bits or error likelihood as a result of stochastic manufacturing variations, with the electronically stored information interactive with functional variations in a particular module with respect to other modules. For example, a plurality of ring oscillators are implemented with a readout circuit responsive to variations between the oscillators. An electrically programmable memory layer stores empirical calibration data, which will be non-deterministic, and therefore truly random. A sufficient number of oscillators and calibration precision are provided to achieve a set of calibration data with a high net entropy, e.g., equivalent of 2048 or 4096 bits of uncorrelated data. An internal low drift crystal may also be provided as a timing, though self-reference of timing may alleviate need for a precision internal or external timebase. The output of the device is dependent on (a) stored information supplied externally: (b) internal stored calibration information; and (c) the oscillators which vary stochastically as a result of manufacturing tolerances. The oscillators may vary based on voltage and temperature, for example, and are compensated for these effects. The module may also be affected by cosmic radiation or X-ray exposure, and these effects may be residual; the module is intended to fail when subjected to various types of reverse engineering, and therefore residual fragility is a virtue in that regard. Because the module is fragile, the risk of loss of information is finite and non-infinitesimal. Therefore, a backup method is provided. Essentially, the function of the module is replicated virtually based on information in a blockchain or other distributed execution environment. Because a blockchain has discrete time execution and latency between blocks the recovery algorithm implemented as a smart contract on a blockchain may be computationally infeasible for an attacker. Further, a finite recovery cost may be charged in the smart contract, which is asymmetric based on information known to the authentic user versus an attacker, representing a real cost asymmetry in recovery. Thus, a smart contract may be implemented that chains results between successive execution in different blocks and dependent on information in, or accessible, to the different blocks of the blockchain. If blocks are processed every 10 minutes, and a fee of e.g., $1 in cryptocurrency is charged for each execution, and based on information provided by an authentic user, the recovery takes 100 executions (1000 minutes, ˜17 hours), while for a non-authentic user without the information, takes >1,000,000 times longer (>˜17,000 hours >$50,000.000), the asymmetry may make the process infeasible, especially where the attempts are visible to observers. A rule may be implemented to cease execution of recovery attempts where the probability that the recovery attempt is unauthorized is >99.9%.
According to another embodiment, the distributed ledger processing system is an permissioned system, wherein each authorized user platform has a trusted platform module (TPM), and as a distributed network stores the private information. The smart contracts execute on the authorized user platforms, and therefore may employ interaction between the TPM and smart contract processing to secure information while using that information.
According to another variant, fully or partially homomorphic cryptographic algorithms (which may be implemented within a customized TPM, or perhaps as a software executable algorithm), depending in security risks and breach risk tolerance. Advantageously, the input information is engineered to be efficiently processed using a homomorphic algorithm. en.wikipedia.org/wiki/Homomorphic_encryption. Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it first. The result of the computation is in an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data. Homomorphic encryption can be used for privacy-preserving outsourced storage and computation. Homomorphic encryption is a form of encryption with an additional evaluation capability for computing over encrypted data without access to the secret key. The result of such a computation remains encrypted. Homomorphic encryption can be viewed as an extension of either symmetric-key or public-key cryptography. Homomorphic refers to homomorphism in algebra: the encryption and decryption functions can be thought of as homomorphisms between plaintext and ciphertext spaces. en.wikipedia.org/wiki/Homomorphism
Homomorphic encryption includes multiple types of encryption schemes that can perform different classes of computations over encrypted data. Some common types of homomorphic encryption are partially homomorphic, somewhat homomorphic, leveled fully homomorphic, and fully homomorphic encryption. The computations are represented as either Boolean or arithmetic circuits. Partially homomorphic encryption encompasses schemes that support the evaluation of circuits consisting of only one type of gate, e.g., addition or multiplication. Somewhat homomorphic encryption schemes can evaluate two types of gates, but only for a subset of circuits. Leveled fully homomorphic encryption supports the evaluation of arbitrary circuits of bounded (pre-determined) depth. Fully homomorphic encryption (FHE) allows the evaluation of arbitrary circuits of unbounded depth, and is the strongest notion of homomorphic encryption. For the majority of homomorphic encryption schemes, the multiplicative depth of circuits is the main practical limitation in performing computations over encrypted data. Homomorphic encryption schemes are inherently malleable. In terms of malleability, homomorphic encryption schemes have weaker security properties than non-homomorphic schemes. However, the security level is arbitrary and may be high, up to the limit of feasibility. Various schemes include: RSA cryptosystem (unbounded number of modular multiplications); ElGamal cryptosystem (unbounded number of modular multiplications); Goldwasser-Micali cryptosystem (unbounded number of exclusive or operations); Benaloh cryptosystem (unbounded number of modular additions): Paillier cryptosystem (unbounded number of modular additions); Sander-Young-Yung system (after more than 20 years solved the problem for logarithmic depth circuits); and Boneh-Goh-Nissim cryptosystem (unlimited number of addition operations but at most one multiplication); Ishai-Paskin cryptosystem (polynomial-size branching programs).
Craig Gentry, using lattice-based cryptography, described the first plausible construction for a fully homomorphic encryption scheme. Gentry's scheme supports both addition and multiplication operations on ciphertexts, from which it is possible to construct circuits for performing arbitrary computation. The construction starts from a somewhat homomorphic encryption scheme, which is limited to evaluating low-degree polynomials over encrypted data. Gentry based the security of his scheme on the assumed hardness of two problems certain worst-case problems over ideal lattices and the sparse (or low-weight) subset sum problem. Marten van Dijk, Craig Gentry, Shai Halevi and Vinod Vaikuntanathan presented a second fully homomorphic encryption scheme, which uses many of the tools of Gentry's construction, but which does not require ideal lattices. Instead, they show that the somewhat homomorphic component of Gentry's ideal lattice-based scheme can be replaced with a very simple somewhat homomorphic scheme that uses integers. The scheme is therefore conceptually simpler than Gentry's ideal lattice scheme, but has similar properties with regards to homomorphic operations and efficiency. Newer homomorphic cryptosystems include: The Brakerski-Gentry-Vaikuntanathan (BGV, 2011) scheme, building on techniques of Brakerski-Vaikuntanathan: The NTRU-based scheme by Lopez-Alt, Tromer, and Vaikuntanathan (LTV, 2012); The Brakerski/Fan-Vercauteren (BFV, 2012) scheme, building on Brakerski's scale-invariant cryptosystem; and The NTRU-based scheme by Bos, Lauter, Loftus and Nachrig (BLLN, 2013), building on LTV and Brakerski's scale-invariant cryptosystem. The security of most of these schemes is based on the hardness of the (Ring) Learning With Errors (RLWE) problem, except for the LTV and BLIN schemes that rely on an overstretched variant of the NTRU computational problem. This NTRU variant was subsequently shown vulnerable to subfield lattice attacks, which is why these two schemes are no longer used in practice. All the second-generation cryptosystems still follow the basic blueprint of Gentry's original construction, namely they first construct a somewhat homomorphic cryptosystem and then convert it to a fully homomorphic cryptosystem using bootstrapping. Craig Gentry, Amit Sahai, and Brent Waters (GSW) proposed a new technique for building FHE schemes that avoids an expensive “relinearization” step in homomorphic multiplication. Zvika Brakerski and Vinod Vaikuntanathan observed that for certain types of circuits, the GSW cryptosystem features an even slower growth rate of noise, and hence better efficiency and stronger security. Jacob Alperin-Sheriff and Chris Peikert then described a very efficient bootstrapping technique based on this observation. These techniques were further improved to develop efficient ring variants of the GSW cryptosystem: FHEW (2014) and TFHE (2016). The FHEW scheme was the first to show that by refreshing the ciphertexts after every single operation, it is possible to reduce the bootstrapping time to a fraction of a second. FHEW introduced a new method to compute Boolean gates on encrypted data that greatly simplifies bootstrapping, and implemented a variant of the bootstrapping procedure. The efficiency of FHEW was further improved by the TFHE scheme, which implements a ring variant of the bootstrapping procedure using a method similar to the one in FHEW. The CKKS scheme supports efficient rounding operations in encrypted state. The rounding operation controls noise increase in encrypted multiplication, which reduces the number of bootstrapping in a circuit.
If the RSA public key has modulus n and encryption exponent e, then the encryption of a message m is given by ε(m)=me mod n. The homomorphic property is then
ε(m1)·Σ(m2)=m1em2e mod n=(m1m2)e mod n=ε(m1·m2)
In the ElGamal cryptosystem, in a cyclic group G of order q with generator g, if the public key is (G, q, g, h), where h=gx, and x is the secret key, then the encryption of a message m is ε(m)=(gr, m·hr) for some random rε={0, . . . , q−1}. The homomorphic property is then
ε(m1)·E(m2)=(gr
In the Goldwasser-Micali cryptosystem, if the public key is the modulus n and quadratic non-residue x, then the encryption of a bit b is ε(b)=xbr2 mod n, for some random r E {0, . . . , n−1}. The homomorphic property is then ε(b1)·E(b2)=xb
In the Benaloh cryptosystem, if the public key is the modulus n and the base g with a blocksize of c, then the encryption of a message m is ε(m)=gmrc mod n, for some random rε{0, . . . , n−1}. The homomorphic property is then ε(m1)·ε(m2)=(gm
In the Paillier cryptosystem, if the public key is the modulus n and the base g, then the encryption of a message m is ε(m)=gmrn mod n2, for some random rε{0, . . . , n−1}. The homomorphic property is then
ε(m1)·ε(m2)=(gm
A cryptosystem that supports arbitrary computation on ciphertexts is known as fully homomorphic encryption (FHE). Such a scheme enables the construction of programs for any desirable functionality, which can be run on encrypted inputs to produce an encryption of the result. Since such a program need never decrypt its inputs, it can be run by an untrusted party without revealing its inputs and internal state. Fully homomorphic cryptosystems have great practical implications in the outsourcing of private computations, for instance, in the context of cloud computing. There are several open-source implementations of second- and third-generation fully homomorphic encryption schemes. Second-generation FHE scheme implementations typically operate in the leveled FHE mode (though bootstrapping is still available in some libraries) and support efficient SIMD-like packing of data; they are typically used to compute on encrypted integers or real/complex numbers. Third-generation FHE scheme implementations often bootstrap after each Boolean gate operation but have limited support for packing and efficient arithmetic computations; they are typically used to compute Boolean circuits over encrypted bits. The choice of using a second-generation vs. third-generation scheme depends on the input data types and the desired computation. A community standard for homomorphic encryption is maintained by the HomomorphicEncryption.org group, an open industry/government/academia consortium co-founded in 2017 by Microsoft, IBM and Duality Technologies. The current standard document includes specifications of secure parameters for RLWE.
See, U.S. Pat. Nos. 9,569,771; 9,992,028; 10022613; 10046228; 10049017; 10050959; 10114969; 10195513; 10200197; 10219744; 10231652; 10236006; 10289816; 10291627; 10297106; 10320843; 10333696; 10335063; 10335064; 10341121; 10362058; 10388097; 10425426; 10445965; 10476701; 10476847; 10484168; 10504314; 10528722; 10532268; 10554394; 10554753; 10572679; 10572684; 10581869; 10592985; 10593157; 10600006; 10614661; 10615960; 10621164; 10630468; 10630477; 10637645; 10650313; 10652014; 10664353; 10664591; 10664835; 10678931; 10680800; 10681033; 10700850; 10708039; 10708250; 10713731; 10715317; 10715326; 10715500; 10719623; 10721058; 10721217; 10721240; 10726657; 10728283; 10740455; 10747905; 10748370; 10748644; 10749687; 10749848; 10755276; 10761877; 10762228; 10762506; 10778410; 10789590; 10790961; 10790964; 10790987; 10790990; 10797887; 10803205; 10803451; 10810583; 10812274; 10817872; 10819505; 10824763; 10825024; 10825295; 10831903; 10832522; 10833858; 10839107; 10839411; 10841100; 10846372; 10855455; 10861016; 10868865; 10872487; 10878108; 10878429; 10880089; 10885203; 10885735; 10887100; 10887104; 10892888; 10892894; 10904000; 20160072800; 20160170996; 20160224803; 20160300252; 20160321654; 20160330034; 20160358165; 20170155515; 20170161829; 20170173262; 20170243284; 20170250796; 20170287068; 20170289111; 20170316391; 20170329980; 20180025435; 20180041345; 20180082043; 20180109541; 20180117446; 20180117447; 20180157558; 20180183768; 20180198630; 20180264347; 20180303420; 20180303421; 20180303422; 20180303423; 20180303424; 20180307859; 20180326291; 20180329783; 20180330077; 20180330078; 20180330079; 20180330125; 20180330343; 20180331821; 20180332011; 20180365201; 20190013943; 20190014176; 20190019183; 20190020651; 20190026146; 20190036678; 20190052458; 20190058580; 20190089537; 20190102163; 20190116174; 20190130698; 20190130701; 20190132295; 20190147415; 20190158272; 20190158594; 20190164153; 20190166161; 20190166162; 20190182035; 20190183255; 20190188787; 20190190701; 20190205773; 20190221076; 20190236879; 20190236880; 20190236881; 20190238311; 20190244195; 20190244290; 20190251270; 20190251553; 20190251554; 20190251558; 20190253235; 20190268312; 20190280880; 20190281066; 20190288853; 20190294805; 20190294956; 20190295073; 20190295371; 20190296910; 20190303541; 20190303579; 20190303623; 20190303951; 20190305957; 20190305959; 20190305968; 20190306173; 20190306176; 20190311351; 20190312719; 20190312734; 20190318367; 20190325044; 20190327078; 20190332807; 20190334694; 20190334695; 20190334715; 20190334716; 20190342074; 20190358515; 20190361917; 20190362054; 20190363877; 20190371106; 20190372762; 20190385162; 20190385711; 20190386814; 20190394019; 20200004973; 20200007331; 20200013073; 20200013118; 20200013251; 20200019864; 20200021569; 20200021600; 20200028693; 20200034550; 20200036519; 20200036707; 20200042994; 20200042999; 20200044863; 20200050774; 20200051077; 20200051361; 20200052898; 20200052903; 20200053054; 20200057920; 20200058022; 20200073560; 20200074456; 20200074457; 20200074459; 20200074548; 20200076829; 20200082126; 20200082433; 20200084483; 20200089872; 20200104636; 20200111022; 20200111093; 20200112442; 20200112545; 20200117690; 20200118458; 20200119969; 20200120074; 20200126070; 20200126075; 20200128075; 20200134624; 20200134625; 20200136799; 20200142986; 20200143368; 20200145195; 20200150885; 20200151992; 20200153627; 20200153628; 20200153801; 20200153803; 20200160290; 20200160641; 20200162251; 20200162268; 20200167503; 20200167512; 20200174990; 20200175180; 20200175502; 20200175509; 20200175611; 20200177366; 20200184093; 20200184465; 20200184471; 20200186350; 20200193292; 20200193419; 20200193434; 20200195419; 20200195437; 20200201679; 20200201910; 20200202018; 20200202345; 20200202376; 20200204375; 20200204563; 20200210392; 20200210404; 20200210405; 20200211018; 20200213130; 20200213134; 20200213329; 20200213331; 20200219362; 20200226867; 20200228317; 20200242102; 20200250320; 20200258339; 20200258340; 20200259638; 20200273028; 20200274693; 20200279253; 20200279260; 20200280431; 20200280553; 20200286083; 20200286092; 20200294158; 20200295926; 20200296128; 20200304290; 20200311566; 20200311695; 20200311720; 20200320340; 20200320825; 20200327250; 20200327546; 20200336470; 20200342452; 20200349054; 20200349274; 20200349563; 20200351083; 20200351089; 20200351098; 20200351253; 20200351258; 20200351657; 20200356085; 20200356689; 20200358595; 20200359550; 20200359582; 20200364456; 20200364700; 20200364704; 20200366459; 20200366460; 20200366503; 20200374118; 20200374135; 20200382478; 20200387777; 20200387893; 20200387896; 20200389292; 20200402171; 20200404023; 20200412550; 20210012282; 20210014071; and 20210018953.
Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. The TPM makes use of cryptographic hash operations, and currently uses the SHA-1 hash algorithm. This hash algorithm is used to “extend” the values in the Platform Configuration Registers (PCRs), to detect and prevent data modification, identify keys and to create “capabilities” used to improve the efficiency of command chaining. Capabilities are created by hashing particular command parameters together with the secret value TPM Proof in order to create a 160-bit capability string which cannot be forged by an adversary. This is useful in improving the performance of (for example) third-party approved migration, where the third-party produces an authorization certificate processed by the TPM. The TPM has Facilities for the secure generation of cryptographic keys for limited uses: Remote attestation (Creates a nearly unforgeable hash key summary of the hardware and software configuration. The software in charge of hashing the configuration data determines the extent of the summary. This allows a third party to verify that the software has not been changed); Binding (Encrypts data using the TPM bind key, a unique RSA key descended from a storage key); and Sealing (Similar to binding, but in addition, specifies the TPM state for the data to be decrypted (unsealed). Computer programs can use a TPM to authenticate hardware devices, since each TPM chip has a unique and secret Endorsement key (EK) burned in as it is produced. Pushing the security down to the hardware level provides more protection than a software-only solution. The responsibility of assuring said integrity using TPM is with the firmware and the operating system. For example, Unified Extensible Firmware Interface (UEFI) can use TPM to form a root of trust: The TPM contains several Platform Configuration Registers (PCRs) that allow secure storage and reporting of security relevant metrics. These metrics can be used to detect changes to previous configurations and decide how to proceed.
The endorsement key is a 2018-bit RSA public and private key pair that is created randomly on the chip at manufacture time and cannot be changed. The private key never leaves the chip, while the public key is used for attestation and for encryption of sensitive data sent to the chip, as occurs during the TPM_TakeOwnership command. This key is used to allow the execution of secure transactions: every Trusted Platform Module (TPM) is required to be able to sign a random number (in order to allow the owner to show that he has a genuine trusted computer), using a particular protocol created by the Trusted Computing Group (the direct anonymous attestation protocol) in order to ensure its compliance of the TOG standard and to prove its identity; this makes it impossible for a software TPM emulator with an untrusted endorsement key (for example, a self-generated one) to start a secure transaction with a trusted entity. The TPM should be designed to make the extraction of this key by hardware analysis hard, but tamper resistance is not a strong requirement. Memory curtaining extends common memory protection techniques to provide full isolation of sensitive areas of memory—for example, locations containing cryptographic keys. Even the operating system does not have full access to curtained memory. The exact implementation details are vendor specific. Sealed storage protects private information by binding it to platform configuration information including the software and hardware being used. This means the data can be released only to a particular combination of software and hardware. Sealed storage can be used for DRM enforcing. Remote attestation allows changes to the user's computer to be detected by authorized parties. For example, software companies can identify unauthorized changes to software, including users circumventing technological protection measures. It works by having the hardware generate a certificate stating what software is currently running. The computer can then present this certificate to a remote party to show that unaltered software is currently executing. Remote attestation is usually combined with public-key encryption so that the information sent can only be read by the programs that presented and requested the attestation, and not by an eavesdropper.
When a user requires an AIk (Attestation Identity key) the user wants its key to be certified by a CA (Certification Authority). The user through a TPM (Trusted Platform Module) sends three credentials a public key credential, a platform credential, and a conformance credential. This set of certificates and cryptographic keys will in short be referred to as “EK”. The EK can be split into two main parts, the private part “EKpr” and the public part “EKpub”. The EKpr never leaves the TPM. Disclosure of the EKpub is however necessary (version 1.1). The EKpub will uniquely identify the endorser of the platform, model, what kind of software is currently being used on the platform, details of the TPM, and that the platform (PC) complies with the TOG specifications. If this information is communicated directly to another party as a process of getting trusted status it would at the same time be impossible to obtain an anonymous identity. Therefore, this information is sent to the privacy certification authority. (trusted third party). When the CA (Privacy certification Authority) receives the EKpub sent by the TPM, the CA verifies the information. If the information can be verified it will create a certified secondary key pair AIk, and sends this credential back to the requestor. This is intended to provide the user with anonymity. When the user has this certified AIk, he or she can use it to communicate with other trusted platforms. In version 1.2, the TOG have developed a new method of obtaining a certified AIk. This process is called DAA Direct anonymous attestation. This method does not require the user to disclose his/her EKpub with the TTP. The unique new feature of the DAA is that it has the ability to convince the remote entity that a particular TPM (trusted platform module) is a valid TPM without disclosing the EKpub or any other unique identifier. Before the TPM can send a certification request for an AIk to the remote entity, the TPM has to generate a set of DAA credentials. This can only be done by interacting with an issuer. The DAA credentials are created by the TPM sending a TPM-unique secret that remains within the TPM. The TPM secret is similar but not analogous to the EK. When the TPM has obtained a set of DAA credentials, it can send these to the Verifier. When the Verifier receives the DAA credentials from the TTP, it will verify them and send a certified AIk back to the user. The user will then be able to communicate with other trusted parties using the certified AIk. The Verifier may or may not be a trusted third party (TTP). The Verifier can determine whether the DAA credentials are valid, but the DAA credentials do not contain any unique information that discloses the TPM platform.
Gideon Greenspan, “Why Many Smart Contract Use Cases Are Simply Impossible” [www.coindesk.com/three-smart-contract-misconceptions/] describes the limitations of Ethereum (and other blockchains more generally) regarding interactions with the world. However, using proxy key cryptography and/or homomorphic cryptography, some of these issues, especially relating to secret sharing, are alleviated. In fact, the trusted oracle issue is not as extreme as insinuated, and the need for consensus is also inherent in the platform. With respect to the high computational demands of homomorphic cryptographic processing, these could be substituted for some or all of the hash-processing algorithms to demonstrate proof or work, and thus add no additional computational burdens on the mining process. As intimated distributed consensus processing may be used to process encrypted information without revealing the underlying secrets, according to underlying known and demonstrated cryptographic primitives.
In this aspect of the invention, it is noted that complete and/or permanent anonymity or pseudonymity may be waived, and therefore a more traditional underlying debtor-creditor relationship established. In event of default, mechanisms are provided to unmask the debtor, and compel to some degree satisfaction of the creditor's claim. This in turn, permits recordation of security interests and the like.
When the debt token is fungible, that means that the debt may be satisfied against any token holder. In an economy, that suggests a market process in which debtors compete to offer the highest amount to satisfy the token, and to the extent that the corresponding asset is fungible, the creditors compete to agree to the lowest satisfaction threshold. The tokens are typically linked macroeconomically, for example through an exchange, but the tokens may also have an asset securitization. The efficiency of a smart contract executed through a blockchain, versus a legal process or security interest foreclosure, may provide a significant arbitrage to compel value through the use of tokenized debt. Note that the present technology does not require automatic payment of a debt; while that could be implemented according to known proposals, it is not the particular problem to be solved herein. Rather, the present technology establishes a transferrable debt-representing token, that has sufficient attributes to establish a negative value, such that relinquishing the token rationally requires a compensatory transfer to the recipient. The incentive and markets for satisfaction of the debt establishes a statistical value of the debt. The incentive is in a sense arbitrary with respect to the technology, though technological incentives (or penalties) are supported herein. Somewhat inherent in a negative-valued cryptocurrency token is a requirement that the recipient accept the obligation; one would generally not permit gifting of a liability, though when the net value of the gift is positive, the transfer of the accompanying liability may be acceptable. This is a deviation from a typical cryptocurrency transaction, in which the transferor authorizes the transfer to a wallet address and the recipient may remain passive. On the other hand, one would not normally proactively assume a liability without consideration, and therefore passivity of the transferor seems unlikely for a typical transaction.
See, U.S. Pat. Nos. 9,569,771; 9,992,028; 10022613; 10046228; 10049017; 10050959; 10114969; 10168693; 10195513; 10200197; 10219744; 10231652; 10236006; 10289816; 10291627; 10297106; 10320843; 10333696; 10335063; 10335064; 10341121; 10346815; 10362058; 10362278; 10388097; 10425426; 10445965; 10476701; 10476847; 10484168; 10504314; 10528722; 10532268; 10545491; 10554394; 10554753; 10572679; 10572684; 10581869; 10592985; 10593157; 10600006; 10614661; 10615960; 10621164; 10630468; 10630477; 10637645; 10650313; 10652014; 10657595; 10664353; 10664591; 10664835; 10678931; 10680800; 10681033; 10685399; 10700850; 10708039; 10708250; 10713731; 10715317; 10715326; 10715500; 10719623; 10721058; 10721217; 10721240; 10726657; 10728283; 10740455; 10747905; 10748370; 10748644; 10749687; 10749848; 10755276; 10761877; 10762228; 10762506; 10778410; 10789590; 10790961; 10790964; 10790987; 10790990; 10797887; 10803205; 10803451; 10810550; 10810583; 10812274; 10817872; 10819505; 10819959; 10824763; 10825024; 10825295; 10831903; 10832522; 10833858; 10839107; 10839411; 10841100; 10846372; 10855455; 10861016; 10868865; 10872487; 10878108; 10878429; 10880089; 10885203; 10885735; 10887100; 10887104; 10892888; 10892894; 10904000; 20160072800; 20160170996; 20160224803; 20160300252; 20160321654; 20160330034; 20160358165; 20170155515; 20170161829; 20170173262; 20170243284; 20170250796; 20170287068; 20170289111; 20170316391; 20170329980; 20180025435; 20180041345; 20180068359; 20180071789; 20180074481; 20180075386; 20180075406; 20180082043; 20180109541; 20180117446; 20180117447; 20180157558; 20180183768; 20180189753; 20180198630; 20180240191; 20180264347; 20180285970; 20180285996; 20180303420; 20180303421; 20180303422; 20180303423; 20180303424; 20180307859; 20180326291; 20180329783; 20180330077; 20180330078; 20180330079; 20180330125; 20180330343; 20180331821; 20180331835; 20180332011; 20180365201; 20180365764; 20190005471; 20190012660; 20190012663; 20190013943; 20190014176; 20190019183; 20190020651; 20190026146; 20190036678; 20190052458; 20190058580; 20190080392; 20190089537; 20190095880; 20190095995; 20190102163; 20190114706; 20190116174; 20190122297; 20190130483; 20190130698; 20190130701; 20190132295; 20190139007; 20190147415; 20190158272; 20190158594; 20190164152; 20190164153; 20190166161; 20190166162; 20190182035; 20190183255; 20190188787; 20190190701; 20190205773; 20190220861; 20190221076; 20190228469; 20190236879; 20190236880; 20190236881; 20190238311; 20190244195; 20190244290; 20190251270; 20190251553; 20190251554; 20190251558; 20190253235; 20190268312; 20190279204; 20190280880; 20190281066; 20190281259; 20190287175; 20190288853; 20190294805; 20190294956; 20190295073; 20190295371; 20190296910; 20190303541; 20190303579; 20190303623; 20190303931; 20190303951; 20190305957; 20190305959; 20190305968; 20190306173; 20190306176; 20190311351; 20190311352; 20190312719; 20190312734; 20190318367; 20190325044; 20190327078; 20190332807; 20190333051; 20190334694; 20190334695; 20190334715; 20190334716; 20190342074; 20190347725; 20190355472; 20190358515; 20190361917; 20190362054; 20190363877; 20190371106; 20190372762; 20190378096; 20190385162; 20190385711; 20190386814; 20190394019; 20200004973; 20200007331; 20200012676; 20200013073; 20200013118; 20200013251; 20200019864; 20200021569; 20200021600; 20200027179; 20200028693; 20200033837; 20200034550; 20200036519; 20200036707; 20200042988; 20200042989; 20200042994; 20200042995; 20200042998; 20200042999; 20200044863; 20200050774; 20200051077; 20200051188; 20200051361; 20200052898; 20200052903; 20200053054; 20200057876; 20200057920; 20200058022; 20200073560; 20200074456; 20200074457; 20200074459; 20200074460; 20200074548; 20200074552; 20200076829; 20200082126; 20200082360; 20200082433; 20200084483; 20200089872; 20200104636; 20200106708; 20200111022; 20200111093; 20200112442; 20200112545; 20200117690; 20200118458; 20200119969; 20200120074; 20200126070; 20200126075; 20200128075; 20200134612; 20200134624; 20200134625; 20200136799; 20200136829; 20200142986; 20200143368; 20200143466; 20200145195; 20200150885; 20200151709; 20200151992; 20200153627; 20200153628; 20200153801; 20200153803; 20200160290; 20200160641; 20200162251; 20200162268; 20200167503; 20200167512; 20200174990; 20200175180; 20200175502; 20200175509; 20200175611; 20200177366; 20200184093; 20200184465; 20200184471; 20200184555; 20200184556; 20200186350; 20200192957; 20200193292; 20200193418; 20200193419; 20200193434; 20200193516; 20200193541; 20200195419; 20200195437; 20200201679; 20200201910; 20200202018; 20200202345; 20200202376; 20200202427; 20200202429; 20200204375; 20200204563; 20200210380; 20200210392; 20200210404; 20200210405; 20200211018; 20200213110; 20200213130; 20200213134; 20200213291; 20200213292; 20200213329; 20200213331; 20200219188; 20200219362; 20200226687; 20200226867; 20200228317; 20200242102; 20200250320; 20200250590; 20200258339; 20200258340; 20200259638; 20200273028; 20200273099; 20200273100; 20200273101; 20200273578; 20200274693; 20200279253; 20200279260; 20200279324; 20200279325; 20200279326; 20200280431; 20200280553; 20200286083; 20200286092; 20200286170; 20200294128; 20200294129; 20200294131; 20200294132; 20200294133; 20200294134; 20200294135; 20200294136; 20200294137; 20200294138; 20200294139; 20200294158; 20200295926; 20200296128; 20200302523; 20200302525; 20200304290; 20200311566; 20200311695; 20200311720; 20200311816; 20200320043; 20200320340; 20200320481; 20200320825; 20200327250; 20200327546; 20200327609; 20200334669; 20200334776; 20200336470; 20200342452; 20200342528; 20200342529; 20200342530; 20200349054; 20200349274; 20200349563; 20200351083; 20200351089; 20200351098; 20200351253; 20200351258; 20200351657; 20200356085; 20200356689; 20200358595; 20200359550; 20200359582; 20200364456; 20200364700; 20200364703; 20200364704; 20200366459; 20200366460; 20200366503; 20200374118; 20200374135; 20200380476; 20200382478; 20200387777; 20200387891; 20200387893; 20200387896; 20200387965; 20200387966; 20200387967; 20200387968; 20200389292; 20200389301; 20200394652; 20200394708; 20200394709; 20200396065; 20200402171; 20200404023; 20200410585; 20200412550; 20210012282; 20210012335; 20210012416; 20210012419; 20210012433; 20210014071; 20210018953; and 20210019792.
Another aspect of the technology is that the token may represent a risk instrument having a negative present value, but which may vary over time. In some cases, a recipient might accept such a risk without consideration, and in other cases, the token may have a positive current value, but substantial risk of assuming a future negative value, and in either case a transfer would be accepted by voluntary affirmance and not simply foisted upon an unsuspecting victim. While smart contracts are not necessarily legally binding or enforceable contracts, it is generally understood that a liability outside of the code of the smart contract would need assent of the obligor.
The present technology also permits the creation of artificial (virtual) legal entities which may be outside of jurisdictional corporate law. In such a case, the virtual entity would be capitalized by its incorporator with some assets, which would generally be a cryptocurrency. Real assets are difficult to transfer to an unincorporated entity without recourse to the transferor under jurisdictional law. Once capitalized within the cryptocurrency system, the entity may engage in transactions. In some cases, the transactions themselves may occur within the real economy. A virtual entity may, for example, acquire goods or rights, especially if the vendor is satisfied. One possible transaction for a virtual entity is a leveraged acquisition. That is the virtual entity borrows based on existing capital and the assets being acquired. While the transaction could be structured as a loan per se to the identified virtual entity, another option is for the lender to transfer debt token and an asset to the recipient virtual entity. In this case, one option is for the tokens in the account (both asset and liability) to be visible to observers in the blockchain. Therefore, the net assets are visible, and a future creditor can determine net assets based on the public ledger, all without breaching the anonymity of the control over the entity. In this design, distributions for the virtual entity would be limited or disclosed, so that a creditor has recourse against the virtual entity or its proceeds.
A particular distinction of tokenized debt versus debt is that the liability is on the part of the token-holder. In some cases the payment for receiving the token exceeds the satisfaction cost; for example, the process of satisfying a debt may unmask the creditor; therefore, a creditor that values its anonymity may transfer before satisfaction, and pay for that privilege. Meanwhile, the intermediate recipient has an arbitration opportunity. Similarly, the creditor may also be unmasked in a satisfaction transaction, and transfer the asset token before satisfaction, with a similar arbitration opportunity. In a special case, the intermediate for both creditor and debtor is the same entity, though the likelihood of matching creditor and debtor in an anonymous transaction is low, except for a large clearinghouse.
A debt transaction may be a demand liability, a term liability, or an open-ended liability with accruing interest. When the asset token is fungible, the obligation would generally be put to market, with a competitive “market value” transaction to satisfy the obligation. The demand may be put to market any time for a demand or open-ended obligation, or within a fixed window (at last on the minimum duration) for a term obligation. Likewise, a tender may be made to surrender the debt token at market payment at any time, subject to term constraints of the underlying transaction. In event of a default, various mechanisms may be implemented to incentivize compliance with the transaction rules. In a stake-based system, the debtor has net assets within the cryptocurrency system, and a default diminishes the value of the stake. However, this may be a weak incentive. The token debt obligation may be secured, and a legal process implemented (or implementable) to collect the debt. A reputation score may be applied, with debtor addresses vying to demonstrate high payment rates, and therefore high credit-worthiness. Note that because of pyramid risk, the creditworthiness of a party may be gamed before a large default. As noted above, one penalty may be an unmasking of a defaulting party through a smart contract, along with personal association of associated wallet addresses, which may provide a high incentive, so long as the party cares about reputation within the cryptosystem (and otherwise). When unmasked, assets attributed to the debtor may be subject to seizure or forfeiture, in satisfaction of the debt. Where the obligation is indirect (or in other cases, such as where a defense is proposed), the wallet may be frozen or sequestered, rather than drained or emptied.
Where the debt token is anonymous and transferrable, typically there is a reason for the debtor to surface or appear. For example, the debt token may represent a risk that has potential positive value over time, that is ascertainable only upon committing assets, e.g., wallet asset contents, escrowed assets, external funds source. Therefore, each time the debtor seeks to determine status, it may risk being forced to pay. Similarly, the unmasking may be periodic, such as once per year. A party may, in advance of unmasking, transfer assets to a “street name”, which in turn would only accept the debt token with accompanying payment to satisfy the obligation. After unmasking, the party may reacquire the debt token.
While a street name or clearinghouse or intermediary may be a trusted or untrusted entity, it may itself be implemented in a decentralized manner through, e.g., smart contracts, Unmasking may take the form of achieving public knowledge of a decryption key holding a record of the current owner of a debt token. When a party acquires a debt token, it is transferred according to a distributed ledger. In this case, once the transaction is cleared, sufficient information to identify a prior owner of the debt token is unavailable (unless a separate rule is triggered to unmask the prior owner). A default of a debt coin typically occurs in a term debt obligation, where the demand is asserted on a date certain. A default may also occur in a demand note obligation, though such an obligation has low (but not zero) feasibility in a blockchain transaction as defined herein. In an open-ended obligation, the debt may never have to be paid. In that case, the initial ratio of amount received for accepting the debt coin and the obligation will be high, e.g., 100:1, depending on the rules and an additional incentive for eventual payment provided (as one of the rules). For example, the establishment of a wallet may incur service and maintenance fees which could be implemented as recurring transfers of debt tokens to the wallet. When the wallet has assets, and a transaction occurs, the debt is satisfied at the time of the transaction, akin to a service fee. When the token represents a risk or contingency liability, an oracle may trigger a rule dependent on occurrence of the contingency, that unmasks the debtor. While some language used herein supposes that smart contracts are continuously executing, all such determinations may occur at predefined times or on occurrence of particular transactions. Further, while traditional smart contracts are executed in a distributed manner, this need not be so, and rather, the creditor may issue a demand or request, e.g., execute the underlying code in a secure and authenticated manner/environment, and transfer the result as a proposed transaction to be processed if authenticated according to the consensus protocol. Once the request for processing is issued, the distributed consensus execution environment may then verify the result, and issue the transaction based on the result. That is, the entire system is not burdened by each smart contract for each block update, and rather a party with a stake may trigger execution of the smart contract.
Note that proxy key, escrowed key, split key, and homomorphic cryptography are not necessary to all embodiments of the invention, and where external information off the blockchain is invoked, may also be maintained by trusted repositories rather than virtual constructs. The essential underlying theme is a token that has or may assume, a negative value at the time of a transaction, and thus that the recipient authorizes receipt under an incentive that may be intrinsic or extrinsic to the transaction. Further, because the token may at a relevant time have a negative value, some mechanism exists for accepting consideration to extinguish the debt, or the token representing the debt at a future time. The tokenized debt is transferrable, and preferably fungible, such that a market exists for transfer of debt tokens accompanying consideration. The tokenized debt may be associated with tokenized assets, and each may be transferrable on the blockchain. Because the debt and asset may be created in pairs mechanisms may be provided to permit additions of sets of tokens to the blockchain with zero (or near zero) net value, with rules governing withdrawals or debt extinction that materially affect other token-holders. The distributed consensus processing system may be run using a transaction fee model, and/or a mining incentive token model. Where a mining incentive is provided, care is employed to avoid deflation of asset values and other instabilities. Proof of work is useful, where the necessary computations are executed to implement smart contracts. Proof of stake may also be employed wherein creditors have an incentive to maintain the system to support their assets. Other available consensus mechanisms are delegated proof of stake, proof of capacity, proof of space, proof of elapsed time (PoET), proof of burn, proof of edit distance, delegated proof of importance, proof of process, proof of signature, proof of retrievability, proof of location, proof or reputation, proof of proof, proof of history, proof of existence, proof of research, proof of activity, proof of weight, proof of zero, proof of care, proof of value, proof of participation, proof of believability, proof of presence, proof of ownership, proof of quality, proof of authority, proof of activity, proof of processed payments, proof of time, proof of disintegration, Byzantine fault tolerance, proof of trust, proof of devotion, direct acyclic graph., etc. See tokenseconomy.gitbook.io/consensus/ (all discussed mechanisms expressly incorporated herein by reference). Each consensus mechanism has a different spectrum of advantages and disadvantages, and hybrid schemes are also available. Indeed, where competitive proof of work is not the key principle, multiple consensus techniques may operate concurrently, with perhaps a transaction closing delay for the multiple schemes to converge on a consensus See U.S. Pat. No. 10,643,288, and also:
The Bitcoin protocol imposes the need to wait for transaction confirmations block by block, which, depending on the approach adopted, currently take from a few seconds to around ten minutes each and limits the volumes of transactions. Ethereum, as well as FR 3018377, enables the decentralized execution of executable contracts. Sidechains technology was designed, essentially, to enable commitments and transactions to be managed in a manner other than that envisaged in Bitcoin and to be able to return to the original Bitcoin on demand [blockstream.com/sidechains.pdf]. More recently, in addition to these systems, “state-channel networks” such as “Lightning Network” [lightning.network/lightning-network-paper.pdf], and Payment-Channel Network [raiden.network] have been proposed for Ethereum, to avoid the need to use blockchain for each transaction. This approach involves the nodes monitoring the blockchain to react in the event of the insertion of transactions that do not reflect the current state, in order to rectify this problem, which requires implementing locks to secure an observation time window, which rather slows down the process WO2016/120826 A2 describes a system-on-chip (Sol, called “Wallet Node” or “WN.” or even “entity”) integrated into—or coupled with—a connected device such as a smartphone, a connected thing of the Internet of Things (IoT) or even a computer, offering guarantees of integrity of execution so that the access restrictions between its different parts cannot be altered or circumvented. Basically, the only possible execution of a WN is to react to an incoming message, by verifying its integrity and then executing the executable Wallet Program code corresponding to the hash specified in this message. With reference to this PCT application, in the present text. “message” means “Wallet Message” except when explicitly stated otherwise.
According to another aspect, a transactional system with peer-to-peer architecture is proposed implementing transactions enabling units of account to be transferred between unit emitter nodes and unit receiver nodes, each transaction having an input referring to an output of a previous transaction (or several inputs each referring to an output of a previous transaction) and itself having at least one new output specifying a number of units of account and a receiver node, it being possible to validate each transaction by entering, in a blockchain stored in a distributed manner between the nodes, a signature of the transaction, characterized in that at least some of the transactions are performed by nodes capable of ensuring a blindness condition of said transactions, in that it comprises a set of transactions satisfying the condition of blindness so as to simplify this set based on the quantities of units of account and addresses of the emitter nodes and receiver nodes involved in these transactions, in order to generate a smaller set of transactions and so as generate and store in the blockchain only some of the signatures of transactions of said smaller set and only on the instruction of the nodes concerned. The present technology may be implemented in an automated agent which operates according to a game theoretic paradigm and protocol. See, US 20200187018; 20180068358; 20180049043; 20170206512; 20170103457; 20160224951; 20150111591; 20140081793; 20130080307; 20110004513; 20100317420; 20100235285; 20080262893; 20070087756; 20070053513; 20060167784; 20210014150; 20210012421; 20200402623; 20200344060; 20200327378; 20200327254; 20200311816; 20200250590; 20200219017; 20200204524; 20200193418; 20200192957; 20200184278; 20200175623; 20200143459; 20200126365; 20200125999; 20200120023; 20200097849; 20200043007; 20200042995; 20200042988; 20200021589; 20200011683; 20190386814; 20190379642; 20190349372; 20190349371; 20190334904; 20190334717; 20190319861; 20190272589; 20190251509; 20190251503; 20190228351; 20190036678; 20180285840; 20180276626; 20180204111; 20180078843; 20170232300; 20170206512; 20160224951; 20160088012; and 20140310243. In such an environment, the agent or node would be expected to act rationally, according to rules, constraints and context. “Cheating” may either be prohibited (by rule), or disincentivized. When a debt token is included within a decentralized economic paradigm for independent agents, it allows increased economic freedoms and provides additional tools. Thus an agent is not limited by its present resources, and may predict its future resources, and discount accordingly to best manage its value and expectations. Likewise, nodes with excess resources may loan those for a gain, especially a gain after risk and opportunity cost adjustment. Thus there will be a net increase in societal wealth resulting from availability of credit, and the present technology permits a market valuation of the debt. This market valuation (through e.g., an automated auction), allows assessment of the rational expectation of risks and opportunity costs, and arbitraging of superior or different information for these factors.
A further aspect of the technology allows the transaction rules to vary in dependence on a time-varying economic (dimensionless) value associated with a token. For example, when a token has a positive value, a more traditional framework regarding authentication and transfers is adopted, while when the value is negative, as assessed by consensus, oracles, trusted resources, etc., the framework as described herein is adopted. For example, exchanges establish the value of a token per external assets. Multiple exchanges may be queried for current value, and filters and constraints applied, on a predetermined basis. The smart contracts established and executing on a blockchain assess the external value, and execute selectively dependent on that value. Presumably, near-zero values are filtered, since sign inversions may be common, and the existence of a significant negative value determined. In such a case, the recipient must actively authorize receipt of the token. When the value is significantly positive, the sender must actively authorize receipt. (In the case of passive receipt, a wallet may have a smart contract that liquidates positive-valued tokens as they near zero, to avoid undesired liabilities). When the value of tokens is near zero, the volume of transactions may increase dramatically, for example to meet an external funding requirement. However, in a market, the likelihood that a viable cryptocurrency can remain at near zero value with high trading volume is low. That is to remain near zero value at large volumes for an issue that is not limited at zero value, supply and demand must be equal, which is unlikely over an extended duration.
It is therefore an object to provide a method of transacting a liability, comprising: defining smart contract which separates a set of rights as a first fungible token type and set of responsibilities as a second fungible token type, the second token type comprising a representation of a liability; in a first transaction, establishing a first transaction consideration which offsets a difference in a value of the set of rights and the set of responsibilities, and allocating a first fungible token with a requirement to pay the consideration to a first party, and allocating the second fungible token with a right to receive the consideration to a second party; and in a second transaction, merging possession of a token of the first fungible token type and a token of the second fungible token type, and extinguish the smart contract set of rights and the set of responsibilities to thereby satisfy the liability.
It is also an object to provide a method of creating a gain within a coupled transaction, comprising: defining cryptographically-secured agreement which defines a set of rights and set of responsibilities the set of responsibilities being represented as a token, the set of responsibilities comprising an economic obligation to a holder of the set of rights transferring the set of responsibilities to a holder, and thereby creating a debt by the holder in an amount representing the economic obligation; and satisfying the economic obligation.
It is a further object to provide a tokenized transaction, comprising transferring a token subject to a smart contract, in consideration of a transfer of a first asset to the token holder, wherein the token holder incurs pursuant to the smart contract a future liability to tender a second asset to a designated recipient.
Another object provides a system for tokenization and management of liability, comprising: a digital token having a set of stored rules stored related to a liability, including terms between an issuer and a creditor; and a processor configured to: update a status of the digital token within an electronic distributed ledger which is cryptographically secure and supports token authentication, transactor authentication, non-repudiation, and avoidance of inconsistent subsequent transactions; reassess a value associated with the liability in response to an external contingency; and extinguishing the digital token if material terms of the contract are satisfied, by broadcast of an update of the digital token to the electronic distributed ledger. The set of rules may be immutable or updatable according to a cryptographic protocol, for example. The digital token may have a status dependent on a state of performance of one or more terms of the contract. The reassessed value associated with liability may be based on the state of performance of one or more terms of the contract, external information from at least one oracle, external information from a plurality of oracles, external information from all counterparties of the contract or external information from all counterparties of the contract who are subject to prejudice according to the reassessed value, for example. The value associated with the liability may be subject to fluctuation, e.g., with markets or sentiments.
It is another object to provide a method for transacting a digital token representing a liability, comprising: generating a digital token comprising a set of stored rules stored related to at least a liability associated with the digital token, the set of rules comprising terms of a contract obligating a holder of the token to settle the liability; modifying a parameter associated with the digital token in response to an updated status of one of the terms of the contract; modifying a settlement value of the liability associated with the digital token in response to the updated status of one of the terms of the contract; and updating an electronic distributed ledger with at least one of the modified parameter and the modified settlement value of the liability associated with the digital token. A proxy key may be used to escrow transactions, wherein the escrow may comprise valuable information, rather than a more traditional asset escrow. The information may represent a non-economic penalty to provide an incentive orthogonal to the cryptocurrency regime. The method may further comprise generating a hash function associated with the updated status of the terms of the contract. The settlement value of the liability may fluctuate. The method may further comprise adding at least one new rule to the terms of the contract after generation of the token.
It is a still further object to provide a computer program product for controlling an automated processor to perform at least said updating step. In general, some embodiments of the technology tie the objective (economic) liability represented by the token, to a subjective value or non-economic (i.e., not valued according to objective economic principles) right or feature, such that the default risk is reduced. However, the liability representing token is preferably transferrable, and would therefore naturally gravitate to those holders who have the highest difference between the objective liability discounted by the default risk, and the subjective value, resulting in potential risk increase for the rights holder. However, the creditor also discounts the valuation based on these ultimate risks.
It is a further object to provide a method of transacting a liability, comprising issuing a fungible token representing a liability; transferring the fungible token representing the liability from a first party to a second party, wherein the second party authorizes acceptance of the fungible token representing the liability, the transfer being automatically recorded on a distributed ledger system operating according to a consensus mechanism; defining a smart contract which automatically executes on the distributed ledger system, the smart contract being operable to receive evidence of satisfaction of the liability and upon receipt of the evidence of satisfaction of the liability, updating the distributed ledger system to represent a satisfaction of the liability: communicating evidence of satisfaction of the liability to the distributed ledger system for processing by the smart contract; and selectively recording extinction of the liability on the distributed ledger system, by the smart contract, dependent on receipt of the communication evidencing satisfaction of the liability. The distributed ledger system may comprise a blockchain, and the fungible token may comprise a cryptocurrency token. The smart contract may be further operable to determine a term of the liability, and to impose at least one of an incentive for satisfaction of the liability, and a penalty for failure of satisfaction of the liability, upon the second party, after the term of the liability is matured.
The issuing of the fungible token representing the liability may be concurrent with issuing of a fungible token representing a right to satisfaction of the liability. A fungible token representing the right to satisfaction of the liability may be transferred to a third party, the transfer being automatically recorded on the distributed ledger system. The smart contract may automatically execute on the distributed ledger system to match the fungible token representing the liability with the fungible token representing a right to satisfaction of the liability. The updating of the distributed ledger system to represent a satisfaction of the liability may comprise extinction of both the fungible token representing the liability and the fungible token representing a right to satisfaction of the liability.
A first fungible token representing the right to satisfaction of the liability may be transferred to a third party, the transfer being automatically recorded on the distributed ledger system. The smart contract may automatically execute on the distributed ledger system to match the fungible token representing the liability with a second fungible token representing a right to satisfaction of a liability having corresponding terms to the first fungible token representing the right to satisfaction of the liability. The updating of the distributed ledger system to represent a satisfaction of the liability may comprise extinction of both the fungible token representing the liability and the second fungible token.
The issuing of the fungible token representing the liability may be concurrent with issuing of a first fungible token representing a right to satisfaction of the liability, and the smart contract may be operable to merge ownership of the fungible token representing the liability with the first fungible token representing a right to satisfaction of the liability, and to record the merger on the distributed ledger system.
The method may further comprise conducting an automated auction for pricing the transfer of the fungible token representing the liability from the first party to the second party. The method may further comprise compensating the at least one participant in the distributed ledger system operating according to a consensus mechanism which executes the smart contract. The method may further comprise, upon execution of the smart contract, automatically generating at least one second fungible token representing a right to satisfaction of a liability having corresponding terms to the first fungible token representing the right to satisfaction of the liability.
It is also an object to provide a method of transacting a liability, comprising defining smart contract automatically executing on a blockchain system, which separates a set of rights as a first fungible token type and set of responsibilities as a second fungible token type, the second token type comprising a representation of a liability. The tokens may be fungible and transferrable. In a first transaction, a first transaction consideration may b established which offsets a difference in a value of the set of rights and the set of responsibilities, a first fungible token allocated with a requirement to pay the consideration to a first party, and the second fungible token allocated with a right to receive the consideration to a second party. In a second transaction, possession of a token of the first fungible token type and a token of the second fungible token type is merged, and the smart contract set of rights and the set of responsibilities extinguished, to thereby satisfy the liability.
It is another object to provide a system supporting a liability transaction, comprising: a fungible digital token representing a liability; a distributed ledger system operating according to a consensus mechanism; a smart contract which automatically executes on the distributed ledger system, the smart contract being operable to receive evidence of satisfaction of the liability and upon receipt of the evidence of satisfaction of the liability, updating the distributed ledger system to represent a satisfaction of the liability; a communication port of the distributed ledger system, configured to receive evidence of satisfaction of the liability for processing by the smart contract; and at least one automated processor, configured to: record a transfer of the fungible token representing the liability from a first party to a second party on the distributed ledger system, selectively dependent on authorization of acceptance of the fungible token representing the liability by the second party; and execute the smart contract to selectively record extinction of the liability on the distributed ledger system, dependent on the receipt of the communication evidencing satisfaction of the liability. The fungible digital token may comprise a set of stored rules stored related to the liability, the set of rules including terms of a contract between an issuer and a creditor, the fungible digital token being cryptographically secure and support token authentication, transactor authentication, non-repudiation, and avoidance of inconsistent subsequent transactions.
The at least one automated processor may be further configured to update a status of the fungible digital token within an automated electronic distributed ledger operating according to a consensus mechanism; and reassess a value associated with the liability in response to an external contingency. The digital token may have a status dependent on a state of performance of one or more terms of the contract. The reassessed value associated with liability may be based on the state of performance of one or more terms of the contract. The reassessed value associated with liability may be based on external information from at least one oracle. The distributed ledger system may comprise a blockchain, and the fungible token comprise a cryptocurrency token. The smart contract may determine a term of the liability, and to impose at least one of an incentive for satisfaction of the liability, and a penalty for failure of satisfaction of the liability, upon the second party, after the term of the liability is matured.
The issuing of the fungible token representing the liability may be concurrent with issuing of a fungible token representing a right to satisfaction in an amount of the liability, and both the fungible token representing the liability and the fungible token representing the right to satisfaction in the amount of the liability being issued to the first party, the issuance of the fungible token representing the liability and the fungible token representing the right to satisfaction in the amount of the liability each being recorded on the distributed ledger system. The distributed ledger system may further record ownership of plurality of fungible tokens representing the right to satisfaction of the liability. The smart contract may be operable to match the fungible token representing the liability with a selected fungible token representing a right to satisfaction in the amount of the liability. The updating of the distributed ledger system to represent a satisfaction of the liability may comprise extinction of both the fungible token representing the liability and the selected fungible token representing the right to satisfaction of the amount of the liability. The match of the fungible token representing the liability with the selected fungible token representing a right to satisfaction in the amount of the liability by the smart contract may cause a transfer and merger of ownership of the fungible token representing the liability and the selected fungible token representing a right to satisfaction in the amount of the liability.
EXAMPLE 1. According to an exemplary transaction, a first person Bob seeks to borrow 1 Bitcoin (or any amount of any asset, cryptocurrency, or right) from John under terms of a smart contract, e.g., at a defined interest rate due at a predetermined time. Bob receives the consideration, e.g. a Bitcoin through a traditional Bitcoin transaction, which is further coupled to a second transaction which issues a token to Bob representing the smart contract, e.g., loan agreement, which is hereinafter referred to as a Truly Undesirable non-Recourse Debt token (debt token), having a present value of negative 1 bitcoin. As a result of completion of the transaction. John possesses (is issued a counter-token (anti-debt token) representing the smart contract rights, and has relinquished 1 Bitcoin. Therefore, the initial transaction is revenue neutral, and has no gain or loss, at least to the extent that the smart contract terms represent fair consideration for the transaction as a whole. The loan agreement may have a high interest rate, representing return in the risk that John takes in entering into the transaction. The smart contract may permit substitution of assets, if the asset is not “special”. This permits satisfaction of the obligation without a transaction in the same market, thus avoiding market perturbing effects, and also permits transactions in relatively illiquid assets.
The transaction has the following attributes: Bob's and John's debt and anti-debt tokens are each transferrable to third parties. John's identity (and the identity of any transferee) is not reported publicly, and may remain anonymous to Bob. Bob's identity (and the identity of any transferee) is not required to be reported publicly, and may remain anonymous to John. On transaction closing, neither party may repudiate the debt and anti-debt token transfers. The Bitcoin (or any other accompanying consideration provided) is subject to its own authentication and transaction paradigm. The debt and anti-debt tokens are recorded on a ledger (which may be a distributed ledger, or blockchain) are subsequent transactions verified to avoid duplicate transfer. No trusted third party is required either to effectuate the transaction, or to maintain the status of the transaction before the debt is satisfied. The debt is satisfied when debt and anti-debt tokens of the same value come under common possession, and are mutually negated. The debt and anti-debt tokens are fungible, so satisfaction of the debt can be achieved on a market rate basis, and without special matching.
According to the protocol, new corresponding debt and anti-debt tokens may be generated by a party, with perhaps a transaction fee to record the new tokens on a ledger. Therefore, the transaction may be initiated by generating a pair of debt and anti-debt tokens having matching opposite value, and transferring either the debt or anti-debt tokens to the counterparty. For example. John generates the debt and anti-debt token pair, and transfers the debt token to Bob, along with a cryptocurrency (e.g., Bitcoin) payment. Therefore, assuming that the smart contract agreement has no other material terms, John is an unsecured creditor of the holder of the debt token, and can transfer or sell the anti-debt token to a third party to assume his rights under the smartcontract. Since the debt token has at inception, a presumed negative value, i.e., represents a debt, there is no essential economic incentive within the confines of the transaction heretofore described, for Bob to admit to possessing the debt token. However, if Bob is subject to income taxes the acceptance of the smart contract consideration, e.g., the Bitcoin, without also accepting the debt token, leads to a taxable gain. Further, the smart contract terms may have a future contingent benefit for the debt token-holder, and therefore there may be other incentives for Bob to comply with the smart contract and honor the debt. In some cases, the present valuation of the debt token is subjective, that is, it is linked to a subjectively valued risk, or to a subjectively valued right or obligation. Taking the risk first, according to the Black-Scholes model, which is used to determine the fair price or theoretical value for a call or a put option based on six variables such as volatility, type of option, underlying stock price, time, strike price, and risk-free rate. If the option is an American Option, that permits exercise over the option period, the holder of the option has to exercise correctly. See, en.wikipedia.org/wiki/Black-Scholes_model. However, subjective biases will make the actual option worth more or less to different people, regardless of the objective valuation potential. Similarly, other types of illiquid instruments subject to risk also have subjective valuation. Clearly, the value of an antidote to one who needs it is higher than to one who does not.
Therefore, at the time of separation of the debt and anti-debt token pair, the objective value of the separation may be neutral, but each respective token of the pair may have distinct demand, such that for Bob, the debt token has intrinsic value, and for John, the anti-debt token has intrinsic value. Given the offsetting coupled transaction, the objective value of Bob's net and John's net will each be near zero, but the subjective valuation of the transaction for Bob and John may each be positive. Therefore, according to game theory, the net gains from the transaction are positive, even if objectively no gain is otherwise apparent from the initial severing of the debt and anti-debt token pair held by a single individual. Stated otherwise, the gains result from the transaction, and not the division of the rights and responsibilities. This is therefore a feature of the technology, that the valuation even of an objectively observed obligation may nevertheless create positive subjective incentives to comply.
EXAMPLE 2. The term “liability” as used herein refers to the obligation of one party to another in the performance of an agreement. In some environments, liability management is performed through the use of actuarial assumption tables. These tables estimate future redemption probabilities. e.g., for insurance products. These estimates are quantified and applied to the reported liability on for example, financial statements such as a balance sheet. In some applications, for example redemption programs, these approaches result in variance risk, which is the difference between the estimated liability redemption and the actual liability redemption. Redemption variance may result in an unexpected financial loss to the reporting entity. Thus, it may be difficult and inefficient for the issuer to make changes to reported estimated financial liability when a redemption variance occurs.
Liability agreements, especially in the form if blockchain-implemented smart contracts, are typically static. The ability to change an agreement usually requires the consent of both parties, which may necessitate redrafting written documents. If an agreement is modifiable within predetermined timelines, the ability to modify multiple liability agreements is generally unfeasible by a person needing to review the liability of each agreement and changing terms as needed. In systems using computer aided liabilities, the ability of liabilities to be used in rapidly executed transactions is stymied by the fact that each transaction needs to be manually evaluated for the change in liability. Systems that use computer aided tracking of liability agreements still use human input to record changes. Thus conventional approaches still suffer from the need for a person to physically redraft agreements because of the modified terms. Of course, the value of a modified liability also changes, the tracking of which is difficult to assess one agreement at a time. The technology provides a system and method for management of liabilities and in some embodiments, a specific solution mitigating variance in the assessment of liability values. The embodiment permits anonymity of the debtor, and unsecured liability. These features therefore imply high risk by the creditor, and as a result, opportunities for speculation, derivatization, risk aggregation and de-aggregation, risk transfer, and risk profiling.
With respect to risk profiling, assuming a high liquidity of markets, the market assessment of liability value may be used to estimate valuation in less liquid markets, and therefore may be used to forecast economic conditions and market participant sentiment. In these cases, actual profits or losses in trading tokens may be less important to the users than ensuring high market liquidity and trades based on current sentiment, though the sentiment must be economically motivated.
Embodiments disclosed below generally exist within an electronic online environment. In an exemplary embodiment, a liability may be created under rules stored in the form of a digital token. A digital token maybe a string of bytes entered into an electronic ledger. In an exemplary embodiment, the digital token is processed by computer executable instructions that change the string of bytes from one state to another upon fulfillment of a contingency or based on reliably determined externalities, e.g., from a so-called oracle. The rules may form a contract (sometimes referred to as a “smart contract” because of the ability of the automated system to apply rules with high reliability, without discretion, and without trust. In exemplary applications, the token may have tangible value that can appreciate/depreciate and may thus be a tradeable asset or commodity. The rights and liability represented by the token may remain static or be modified based on criteria within the rules being met. The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. For example, while the foregoing was described in the context of a rewards or redemption program and associated liabilities, it will be understood that other applications may use aspects of the subject technology to track information and assess changing value as provided by the system and processes disclosed.
A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. A phrase such an embodiment may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such a configuration may refer to one or more configurations and vice versa.
Certain units described in this specification have been labeled as modules in order to more particularly emphasize their implementation independence. A module is “[a] self-contained hardware or software component that interacts with a larger system.” Alan Freedman, “The Computer Glossary” 268 (8th ed. 1998). A module may include a machine- or machines-executable instructions. For example, a module may be implemented as a hardware circuit including custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as analog circuits, quantum computers, microprocessors, logic chips transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also include software-defined units or instructions, that when executed by a processing machine or device, transform data stored on a data storage device from a first state to a second state. An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions that may be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may include disparate instructions stored in different locations that, when joined logically together, include the module, and when executed by the processor, achieve the stated data transformation. A module of executable code may be a single instruction, or many instructions and may even be distributed over several different code segments, among different programs, and/or across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices. The absence of a module reflects the inability of system including the module to execute in given circumstances to perform the function of the respective module, and not that its physical or logical constituents are excluded, that is, the module is unavailable. In the foregoing description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, distributed ledgers, blockchains, smart contracts, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the present embodiments. One skilled in the relevant art will recognize, however, that the invention requires a specific implementation that requires special purpose technology for implementation, that generic hardware alone will not achieve the objectives set forth herein.
As used herein, various terminology is for the purpose of describing particular implementations only and is not intended to be limiting of implementations. For example, as used herein, an ordinal term (e.g., “first.” “second.” “third.” etc.) used to modify an element, such as a structure, a component, an operation, etc., does not by itself indicate any priority or order of the element with respect to another element, but rather merely distinguishes the element from another element having a same name (but for use of the ordinal term). The term “coupled” is defined as connected, although not necessarily directly, and not necessarily mechanically; two items that are “coupled” may be unitary with each other, but in that case the unitary element must meet established criteria for each item. The terms “a” and “an” are defined as one or more unless this disclosure explicitly requires otherwise. The term “substantially” is defined as largely but not necessarily wholly what is specified (and includes what is specified; e.g., substantially 90 degrees includes 90 degrees and substantially parallel includes parallel), as understood by a person of ordinary skill in the art.
The phrase “and/or” means “and” or “or”. To illustrate. A, B, and/or C includes A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C or a combination of A, B, and C. In other words “and/or” operates as an “inclusive or”. Similarly, the phrase “A, B, C or a combination thereof” or “A, B, C, or any combination thereof” includes A alone, B alone, C alone, a combination of A and B, a combination of A and C, a combination of B and C or a combination of A, B, and C.
As used herein, whether in the above description or the following claims the terms “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” and the like are to be understood to be open-ended, that is to mean including but not limited to. The terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), and “include” (and any form of include, such as “includes” and “including”). As a result, an apparatus that “comprises,” “has” or “includes” one or more elements possesses those one or more elements, but is not limited to possessing only those one or more elements. Likewise, a method that “comprises.” “has.” or “includes” one or more steps possesses those one or more steps, but is not limited to possessing only those one or more steps.
Any embodiment of any of the systems, methods and article of manufacture can consist of or consist essentially of-rather than comprise/have/include-any of the described steps, elements, and/or features. Thus, in any of the claims, the term “consisting of” or “consisting essentially of” can be substituted for any of the open-ended linking verbs recited above, in order to change the scope of a given claim from what it would otherwise be using the open-ended linking verb. Thus, the transitional phrases “consisting of” and “consisting essentially of,” respectively, shall be considered exclusionary transitional phrases, as set forth, with respect to claims, in the United States Patent Office Manual of Patent Examining Procedures. Additionally, the terms “wherein” or “whereby” may be used interchangeably with “where.”
Further, a device or system that is configured in a certain way is configured in at least that way, but it can also be configured in other ways than those specifically described. The feature or features of one embodiment may be applied to other embodiments, even though not described or illustrated, unless expressly prohibited by this disclosure or the nature of the embodiments.
The phrase “configured to” means a specification or clarification of the structure or composition of an element defining what the element is, by way of a specific description of its configuration and interface with other elements or an external constraint. Functional language within such a specification is taken to be an affirmative limitation, and not a mere intended use.
The claims hereinbelow are to be construed as excluding abstract subject matter as judicially excluded from patent protection, and the scope of all terms and phrases is to be constrained to only include that which is properly encompassed. By way of example, if a claim phrase is amenable of construction to encompass either patent eligible subject matter and patent ineligible subject matter, then the claim shall be interpreted to cover only the patent eligible subject matter. The scope of the claims shall be considered definite in accordance with the ability of a judicial or administrative court or tribunal to make this determination, regardless of any retroactive or ex post facto changes in interpretation by such court or tribunal. The various disclosure expressly provided herein, in conjunction with the incorporated references, are to be considered to encompass any combinations, permutations, and subcombinations of the respective disclosures or portions thereof, and shall not be limited by the various exemplary combinations specifically described herein.
The present application is a non-provisional of, and claims benefit of priority under 35 U.S.C. § 119(e), from U.S. Provisional Patent Application No. 62/968,196, filed Jan. 31, 2020, the entirety of which is expressly incorporated herein by reference. See 37 C.F.R. § 1.57.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4351982 | Miller et al. | Sep 1982 | A |
| 4977595 | Ohta et al. | Dec 1990 | A |
| 5224162 | Okamoto et al. | Jun 1993 | A |
| 5237159 | Stephens | Aug 1993 | A |
| 5315658 | Micali | May 1994 | A |
| 5392353 | Morales | Feb 1995 | A |
| 5621201 | Langhans | Apr 1997 | A |
| 5623547 | Jones et al. | Apr 1997 | A |
| 5677955 | Doggett et al. | Oct 1997 | A |
| 5679940 | Templeton et al. | Oct 1997 | A |
| 5696908 | Muehlberger et al. | Dec 1997 | A |
| 5717757 | Micali | Feb 1998 | A |
| 5754939 | Herz et al. | May 1998 | A |
| 5768385 | Simon | Jun 1998 | A |
| 5793868 | Micali | Aug 1998 | A |
| 5799087 | Rosen | Aug 1998 | A |
| 5812668 | Weber | Sep 1998 | A |
| 5815657 | Williams et al. | Sep 1998 | A |
| 5828840 | Cowan et al. | Oct 1998 | A |
| 5832089 | Kravitz et al. | Nov 1998 | A |
| 5839119 | Krsul et al. | Nov 1998 | A |
| 5850446 | Berger et al. | Dec 1998 | A |
| 5857023 | Demers et al. | Jan 1999 | A |
| 5884277 | Khosla | Mar 1999 | A |
| 5889862 | Ohta et al. | Mar 1999 | A |
| 5889863 | Weber | Mar 1999 | A |
| 5898154 | Rosen | Apr 1999 | A |
| 5901229 | Fujisaki et al. | May 1999 | A |
| 5903651 | Kocher | May 1999 | A |
| 5903880 | Biffar | May 1999 | A |
| 5915093 | Berlin et al. | Jun 1999 | A |
| 5920629 | Rosen | Jul 1999 | A |
| 5926548 | Okamoto | Jul 1999 | A |
| 5930777 | Barber | Jul 1999 | A |
| 5933498 | Schneck et al. | Aug 1999 | A |
| 5937394 | Wong et al. | Aug 1999 | A |
| 5943424 | Berger et al. | Aug 1999 | A |
| 5949045 | Ezawa et al. | Sep 1999 | A |
| 5952638 | Demers et al. | Sep 1999 | A |
| 5960083 | Micali | Sep 1999 | A |
| 5963648 | Rosen | Oct 1999 | A |
| 5963924 | Williams et al. | Oct 1999 | A |
| 5978840 | Nguyen et al. | Nov 1999 | A |
| 5983208 | Haller et al. | Nov 1999 | A |
| 5987132 | Rowney | Nov 1999 | A |
| 5987140 | Rowney et al. | Nov 1999 | A |
| 5996076 | Rowney et al. | Nov 1999 | A |
| 5999919 | Jarecki et al. | Dec 1999 | A |
| 6002767 | Kramer | Dec 1999 | A |
| 6003765 | Okamoto | Dec 1999 | A |
| 6016484 | Williams et al. | Jan 2000 | A |
| 6018724 | Arent | Jan 2000 | A |
| 6021399 | Demers et al. | Feb 2000 | A |
| 6026163 | Micali | Feb 2000 | A |
| 6026379 | Haller et al. | Feb 2000 | A |
| 6029150 | Kravitz | Feb 2000 | A |
| 6029151 | Nikander | Feb 2000 | A |
| 6035402 | Vaeth et al. | Mar 2000 | A |
| 6047067 | Rosen | Apr 2000 | A |
| 6047887 | Rosen | Apr 2000 | A |
| 6049786 | Smorodinsky | Apr 2000 | A |
| 6049787 | Takahashi et al. | Apr 2000 | A |
| 6055508 | Naor et al. | Apr 2000 | A |
| 6057872 | Candelore | May 2000 | A |
| 6058381 | Nelson | May 2000 | A |
| 6061448 | Smith et al. | May 2000 | A |
| 6061665 | Bahreman | May 2000 | A |
| 6065675 | Teicher | May 2000 | A |
| 6072870 | Nguyen et al. | Jun 2000 | A |
| 6192472 | Garay et al. | Feb 2001 | B1 |
| 6587946 | Jakobsson | Jul 2003 | B1 |
| 6687822 | Jakobsson | Feb 2004 | B1 |
| 6779111 | Gehrmann et al. | Aug 2004 | B1 |
| 6859533 | Wang et al. | Feb 2005 | B1 |
| 6937726 | Wang | Aug 2005 | B1 |
| 7181017 | Nagel et al. | Feb 2007 | B1 |
| 7380119 | Bade et al. | May 2008 | B2 |
| 7869591 | Nagel et al. | Jan 2011 | B1 |
| 8316237 | Felsher et al. | Nov 2012 | B1 |
| 8449378 | Michaelson et al. | May 2013 | B2 |
| 8453219 | Shuster et al. | May 2013 | B2 |
| 8493386 | Burch et al. | Jul 2013 | B2 |
| 8501762 | Li et al. | Aug 2013 | B2 |
| 8505103 | Song et al. | Aug 2013 | B2 |
| 8522330 | Shuster et al. | Aug 2013 | B2 |
| 8523657 | Michaelson et al. | Sep 2013 | B2 |
| 8566247 | Nagel et al. | Oct 2013 | B1 |
| 8572207 | Shuster et al. | Oct 2013 | B2 |
| 8621368 | Shuster et al. | Dec 2013 | B2 |
| 8632193 | Maurel | Jan 2014 | B2 |
| 8671142 | Shuster et al. | Mar 2014 | B2 |
| 8688525 | Minde | Apr 2014 | B2 |
| 8719131 | Roth et al. | May 2014 | B1 |
| 8726379 | Stiansen et al. | May 2014 | B1 |
| 8727893 | Lee et al. | May 2014 | B2 |
| 8756151 | Lubling et al. | Jun 2014 | B1 |
| 8756156 | Campi et al. | Jun 2014 | B1 |
| 8769643 | Ben Ayed | Jul 2014 | B1 |
| 8777735 | Fine et al. | Jul 2014 | B1 |
| 8862506 | Smith et al. | Oct 2014 | B2 |
| 8904181 | Felsher et al. | Dec 2014 | B1 |
| 8905303 | Ben Ayed | Dec 2014 | B1 |
| 8909517 | Mosko et al. | Dec 2014 | B2 |
| 8915781 | Fine et al. | Dec 2014 | B2 |
| 8918794 | Kruglick | Dec 2014 | B2 |
| 8938534 | Le et al. | Jan 2015 | B2 |
| 8947427 | Shuster et al. | Feb 2015 | B2 |
| 8950004 | Messinger et al. | Feb 2015 | B2 |
| 8961300 | Fine | Feb 2015 | B2 |
| 8961301 | Fine et al. | Feb 2015 | B2 |
| 8962964 | Emmerson | Feb 2015 | B2 |
| 8968082 | Fine et al. | Mar 2015 | B2 |
| 8968104 | Fine et al. | Mar 2015 | B2 |
| 8972612 | Le et al. | Mar 2015 | B2 |
| 8974284 | Selby et al. | Mar 2015 | B2 |
| 8985442 | Zhou et al. | Mar 2015 | B1 |
| 8986096 | Fine et al. | Mar 2015 | B2 |
| 8992311 | Fine | Mar 2015 | B2 |
| 8992312 | Fine et al. | Mar 2015 | B2 |
| 9014661 | deCharms | Apr 2015 | B2 |
| 9015847 | Kaplan et al. | Apr 2015 | B1 |
| 9020110 | Baharav et al. | Apr 2015 | B1 |
| 9027007 | Brackman et al. | May 2015 | B2 |
| 9039508 | Arnone et al. | May 2015 | B1 |
| 9046994 | Shuster et al. | Jun 2015 | B2 |
| 9047600 | Zhou et al. | Jun 2015 | B2 |
| 9056253 | Thompson et al. | Jun 2015 | B2 |
| 9070252 | Riahei et al. | Jun 2015 | B2 |
| 9070253 | Tung et al. | Jun 2015 | B2 |
| 9071444 | Everett | Jun 2015 | B2 |
| 9076294 | Fine et al. | Jul 2015 | B2 |
| 9076295 | Fine et al. | Jul 2015 | B2 |
| 9087399 | Shuster et al. | Jul 2015 | B2 |
| 9092939 | Fine et al. | Jul 2015 | B2 |
| 9092940 | Fine et al. | Jul 2015 | B2 |
| 9104873 | Chen et al. | Aug 2015 | B1 |
| 9135787 | Russell et al. | Sep 2015 | B1 |
| 9138652 | Thompson et al. | Sep 2015 | B1 |
| 9160764 | Stiansen et al. | Oct 2015 | B2 |
| 9171299 | Schwartz | Oct 2015 | B1 |
| 9177156 | Kaplan et al. | Nov 2015 | B1 |
| 9185161 | Messinger et al. | Nov 2015 | B2 |
| 9210472 | Andrews, II et al. | Dec 2015 | B2 |
| 9213949 | Lewis et al. | Dec 2015 | B1 |
| 9214063 | Fine et al. | Dec 2015 | B2 |
| 9218470 | Domke et al. | Dec 2015 | B2 |
| 9219824 | Harper | Dec 2015 | B1 |
| 9224262 | Fine et al. | Dec 2015 | B2 |
| 9232476 | Ur et al. | Jan 2016 | B1 |
| 9256769 | Lamfalusi et al. | Feb 2016 | B1 |
| 9258307 | Pianese et al. | Feb 2016 | B2 |
| 9270534 | Hyde et al. | Feb 2016 | B2 |
| 9275389 | Dides et al. | Mar 2016 | B1 |
| 9280792 | Xiao | Mar 2016 | B2 |
| 9294365 | Misra et al. | Mar 2016 | B2 |
| 9298806 | Vessenes et al. | Mar 2016 | B1 |
| 9299071 | Klingen | Mar 2016 | B1 |
| 9299218 | Fine et al. | Mar 2016 | B2 |
| 9300724 | Misra et al. | Mar 2016 | B2 |
| 9305428 | Fine et al. | Apr 2016 | B2 |
| 9305437 | Koopman et al. | Apr 2016 | B1 |
| 9307047 | Chung et al. | Apr 2016 | B2 |
| 9311639 | Filler | Apr 2016 | B2 |
| 9311640 | Filler | Apr 2016 | B2 |
| 9317997 | Fine et al. | Apr 2016 | B2 |
| 9317998 | Fine | Apr 2016 | B2 |
| 9317999 | Fine et al. | Apr 2016 | B2 |
| 9324062 | Schwartz | Apr 2016 | B2 |
| 9330261 | Wilson | May 2016 | B2 |
| 9332302 | Briggs et al. | May 2016 | B2 |
| 9338499 | Briggs et al. | May 2016 | B2 |
| 9338500 | Briggs et al. | May 2016 | B2 |
| 9344754 | Briggs et al. | May 2016 | B2 |
| 9350753 | Kaplan et al. | May 2016 | B2 |
| 9350762 | Doddapaneni | May 2016 | B2 |
| 9351032 | Briggs et al. | May 2016 | B2 |
| 9351124 | Shelton | May 2016 | B1 |
| D759073 | Winklevoss | Jun 2016 | S |
| 9364950 | Izhikevich et al. | Jun 2016 | B2 |
| 9373223 | Webb | Jun 2016 | B1 |
| 9374280 | Misra et al. | Jun 2016 | B2 |
| 9386022 | Shuster et al. | Jul 2016 | B2 |
| 9397985 | Seger, II et al. | Jul 2016 | B1 |
| 9398018 | MacGregor et al. | Jul 2016 | B2 |
| 9401850 | Misra et al. | Jul 2016 | B2 |
| 9406195 | Tung et al. | Aug 2016 | B2 |
| 9411976 | Irvine | Aug 2016 | B2 |
| 9413735 | Hird | Aug 2016 | B1 |
| 9413780 | Kaplan et al. | Aug 2016 | B1 |
| 9418213 | Roth et al. | Aug 2016 | B1 |
| 9419951 | Felsher et al. | Aug 2016 | B1 |
| 9425954 | Chalker | Aug 2016 | B1 |
| 9426151 | Richards et al. | Aug 2016 | B2 |
| 9426167 | Childress et al. | Aug 2016 | B1 |
| 9430905 | Webb | Aug 2016 | B2 |
| 9436455 | Ziat et al. | Sep 2016 | B2 |
| 9436811 | Messinger et al. | Sep 2016 | B2 |
| 9436935 | Hudon | Sep 2016 | B2 |
| 9440152 | Thompson et al. | Sep 2016 | B2 |
| 9443383 | Fine et al. | Sep 2016 | B2 |
| 9451010 | Spitz et al. | Sep 2016 | B2 |
| 9452353 | Lewis | Sep 2016 | B2 |
| 9454365 | Oberheide et al. | Sep 2016 | B2 |
| 9454656 | Oberheide et al. | Sep 2016 | B2 |
| 9460322 | Lamfalusi et al. | Oct 2016 | B2 |
| 9463388 | Thompson et al. | Oct 2016 | B2 |
| 9465488 | Howard | Oct 2016 | B2 |
| 9466051 | Roth et al. | Oct 2016 | B1 |
| 9473503 | Shuster et al. | Oct 2016 | B2 |
| 9473524 | Kaplan et al. | Oct 2016 | B2 |
| 9485736 | Ur et al. | Nov 2016 | B2 |
| 9489502 | Davis et al. | Nov 2016 | B2 |
| 9489522 | El Defrawy et al. | Nov 2016 | B1 |
| 9489762 | Jenkins | Nov 2016 | B2 |
| 9489798 | Fine et al. | Nov 2016 | B2 |
| 9495668 | Juels | Nov 2016 | B1 |
| 9495679 | Kassemi et al. | Nov 2016 | B2 |
| 9501791 | Dziuk | Nov 2016 | B2 |
| 9509699 | Burch et al. | Nov 2016 | B2 |
| 9514264 | Nebesnyi | Dec 2016 | B1 |
| 9514293 | Moritz et al. | Dec 2016 | B1 |
| 9514497 | Baharav et al. | Dec 2016 | B2 |
| 9514609 | Katz et al. | Dec 2016 | B2 |
| 9514644 | Fourie | Dec 2016 | B2 |
| 9516035 | Moritz et al. | Dec 2016 | B1 |
| 9519925 | Crites | Dec 2016 | B2 |
| 9521045 | Childress et al. | Dec 2016 | B1 |
| 9531724 | Shuster et al. | Dec 2016 | B2 |
| 9532222 | Oberheide et al. | Dec 2016 | B2 |
| 9533413 | Izhikevich et al. | Jan 2017 | B2 |
| 9536385 | Fine et al. | Jan 2017 | B2 |
| 9542683 | Kalinin et al. | Jan 2017 | B2 |
| 9544143 | Oberheide et al. | Jan 2017 | B2 |
| 9548957 | Degaugue et al. | Jan 2017 | B2 |
| 9552580 | Dides et al. | Jan 2017 | B2 |
| 9552615 | Mathura et al. | Jan 2017 | B2 |
| 9552694 | Fine et al. | Jan 2017 | B2 |
| 9552696 | Fine et al. | Jan 2017 | B2 |
| 9553882 | Margalit et al. | Jan 2017 | B2 |
| 9553888 | Stiansen et al. | Jan 2017 | B2 |
| 9553982 | Unitt | Jan 2017 | B2 |
| 9558623 | Fine et al. | Jan 2017 | B2 |
| 9558624 | Arnone et al. | Jan 2017 | B2 |
| 9559920 | Childress et al. | Jan 2017 | B1 |
| 9563470 | Modani et al. | Feb 2017 | B2 |
| 9569262 | Modani et al. | Feb 2017 | B2 |
| 9569771 | Lesavich et al. | Feb 2017 | B2 |
| 9576426 | Marshall et al. | Feb 2017 | B2 |
| 9582182 | Katz et al. | Feb 2017 | B2 |
| 9595031 | Grassadonia | Mar 2017 | B1 |
| 9595034 | Van Rooyen et al. | Mar 2017 | B2 |
| 9596787 | Iyengar et al. | Mar 2017 | B1 |
| 9607156 | Oberheide et al. | Mar 2017 | B2 |
| 9607330 | Spitz et al. | Mar 2017 | B2 |
| 9607461 | Taylor | Mar 2017 | B2 |
| 9608814 | Oberheide et al. | Mar 2017 | B2 |
| 9608829 | Spanos et al. | Mar 2017 | B2 |
| 9619967 | Fine et al. | Apr 2017 | B2 |
| 9633513 | Webb | Apr 2017 | B2 |
| 9635000 | Muftic | Apr 2017 | B1 |
| 9641338 | Sriram et al. | May 2017 | B2 |
| 9641341 | Oberheide et al. | May 2017 | B2 |
| 9645604 | Nebesnyi | May 2017 | B1 |
| 9646029 | Baird, III | May 2017 | B1 |
| 9648015 | Avetisov et al. | May 2017 | B1 |
| 9648029 | Cheng | May 2017 | B2 |
| 9659104 | Soon-Shiong et al. | May 2017 | B2 |
| 9659123 | Kheterpal et al. | May 2017 | B2 |
| 9659439 | Aleksey | May 2017 | B1 |
| 9660627 | Nebesnyi | May 2017 | B1 |
| 9660803 | Chalker | May 2017 | B2 |
| 9665239 | Koh et al. | May 2017 | B1 |
| 9667427 | Oberhauser et al. | May 2017 | B2 |
| 9667600 | Piqueras Jover et al. | May 2017 | B2 |
| 9667809 | López Quirarte | May 2017 | B1 |
| 9672499 | Yang et al. | Jun 2017 | B2 |
| 9672509 | Klingen | Jun 2017 | B2 |
| 9672518 | Sobel et al. | Jun 2017 | B2 |
| 9673979 | Poole | Jun 2017 | B1 |
| 9674584 | Briggs et al. | Jun 2017 | B2 |
| 9679275 | Bruscoe | Jun 2017 | B2 |
| 9679276 | Cuende | Jun 2017 | B1 |
| 9686247 | Dow et al. | Jun 2017 | B2 |
| 9697342 | Davis et al. | Jul 2017 | B2 |
| 9697362 | Kaplan et al. | Jul 2017 | B2 |
| 9704143 | Walker et al. | Jul 2017 | B2 |
| 9704190 | Custer | Jul 2017 | B2 |
| 9710808 | Slepinin | Jul 2017 | B2 |
| 9712500 | Dow et al. | Jul 2017 | B2 |
| 9712556 | Hirvonen et al. | Jul 2017 | B2 |
| 9720649 | Sahl et al. | Aug 2017 | B2 |
| 9721239 | Ho | Aug 2017 | B1 |
| 9722790 | Ebrahimi | Aug 2017 | B2 |
| 9728037 | Fine et al. | Aug 2017 | B2 |
| 9729318 | Hoy et al. | Aug 2017 | B2 |
| 9734491 | Jiva et al. | Aug 2017 | B2 |
| 9735958 | Alness et al. | Aug 2017 | B2 |
| 9740873 | Ho | Aug 2017 | B1 |
| 9740906 | AlNasser et al. | Aug 2017 | B2 |
| 9741337 | Shastry et al. | Aug 2017 | B1 |
| 9742744 | Ho | Aug 2017 | B1 |
| 9747077 | Sanguinetti et al. | Aug 2017 | B2 |
| 9747586 | Frolov et al. | Aug 2017 | B1 |
| 9747753 | Katz et al. | Aug 2017 | B2 |
| 9749140 | Oberhauser et al. | Aug 2017 | B2 |
| 9749297 | Gvili | Aug 2017 | B2 |
| 9749860 | Chudy et al. | Aug 2017 | B2 |
| 9754131 | Wilson | Sep 2017 | B2 |
| 9754490 | Kentley et al. | Sep 2017 | B2 |
| 9762562 | Maguire et al. | Sep 2017 | B2 |
| 9762590 | Oberheide et al. | Sep 2017 | B2 |
| 9763271 | Gabel | Sep 2017 | B1 |
| 9767520 | Isaacson et al. | Sep 2017 | B2 |
| 9767651 | Fine et al. | Sep 2017 | B2 |
| 9769189 | Mohaisen et al. | Sep 2017 | B2 |
| 9772820 | Sanguinetti et al. | Sep 2017 | B2 |
| 9773232 | Grassadonia | Sep 2017 | B1 |
| 9773351 | Hudson et al. | Sep 2017 | B2 |
| 9774448 | Oberheide et al. | Sep 2017 | B2 |
| 9774578 | Ateniese et al. | Sep 2017 | B1 |
| 9774579 | Oberheide et al. | Sep 2017 | B2 |
| 9781494 | Barakat et al. | Oct 2017 | B1 |
| 9785369 | Ateniese et al. | Oct 2017 | B1 |
| 9785912 | Quezada | Oct 2017 | B2 |
| 9786127 | Marshall et al. | Oct 2017 | B2 |
| 9787545 | Hyde et al. | Oct 2017 | B2 |
| 9792600 | Grassadonia | Oct 2017 | B1 |
| 9792742 | Johnson et al. | Oct 2017 | B2 |
| 9794074 | Toll et al. | Oct 2017 | B2 |
| 9800514 | Chen et al. | Oct 2017 | B1 |
| 9800517 | Anderson | Oct 2017 | B1 |
| 9807106 | Daniel et al. | Oct 2017 | B2 |
| 9811981 | Trepp et al. | Nov 2017 | B2 |
| 9813770 | Andrews, II et al. | Nov 2017 | B2 |
| 9815191 | Oleynik | Nov 2017 | B2 |
| 9818092 | Pennanen | Nov 2017 | B2 |
| 9818098 | Royyuru et al. | Nov 2017 | B2 |
| 9818109 | Loh | Nov 2017 | B2 |
| 9818116 | Caldera | Nov 2017 | B2 |
| 9820120 | deCharms | Nov 2017 | B2 |
| 9824222 | Kaplan et al. | Nov 2017 | B1 |
| 9824408 | Isaacson et al. | Nov 2017 | B2 |
| 9824540 | Webb | Nov 2017 | B2 |
| 9825765 | Oberheide et al. | Nov 2017 | B2 |
| 9825931 | Johnsrud et al. | Nov 2017 | B2 |
| 9830580 | MacGregor et al. | Nov 2017 | B2 |
| 9830593 | Myers | Nov 2017 | B2 |
| 9836790 | Ronca et al. | Dec 2017 | B2 |
| 9836908 | Spanos et al. | Dec 2017 | B2 |
| 9842216 | Unitt | Dec 2017 | B2 |
| 9846856 | Rinzler et al. | Dec 2017 | B2 |
| 9849364 | Tran et al. | Dec 2017 | B2 |
| 9852305 | Gajek | Dec 2017 | B2 |
| 9852417 | Tyler et al. | Dec 2017 | B2 |
| 9852426 | Bacastow | Dec 2017 | B2 |
| 9852427 | Caldera | Dec 2017 | B2 |
| 9853819 | Truu et al. | Dec 2017 | B2 |
| 9853977 | Laucius et al. | Dec 2017 | B1 |
| 9858546 | Rinzler et al. | Jan 2018 | B2 |
| 9858766 | Aleksey | Jan 2018 | B2 |
| 9858781 | Campero et al. | Jan 2018 | B1 |
| 9862092 | Izhikevich et al. | Jan 2018 | B2 |
| 9864970 | Rinzler et al. | Jan 2018 | B2 |
| 9866393 | Rush et al. | Jan 2018 | B1 |
| 9870562 | Davis et al. | Jan 2018 | B2 |
| 9872050 | Uhr et al. | Jan 2018 | B2 |
| 9875489 | Spitz et al. | Jan 2018 | B2 |
| 9875510 | Kasper | Jan 2018 | B1 |
| 9876646 | Ebrahimi et al. | Jan 2018 | B2 |
| 9876775 | Mossbarger | Jan 2018 | B2 |
| 9881176 | Goldfarb et al. | Jan 2018 | B2 |
| 9882715 | Alness et al. | Jan 2018 | B2 |
| 9885672 | Forutanpour et al. | Feb 2018 | B2 |
| 9886685 | Keohane et al. | Feb 2018 | B2 |
| 9887975 | Gifford et al. | Feb 2018 | B1 |
| 9887995 | Rotter et al. | Feb 2018 | B2 |
| 9888007 | Caldera et al. | Feb 2018 | B2 |
| 9888026 | Kaplan et al. | Feb 2018 | B2 |
| 9889382 | Thompson et al. | Feb 2018 | B2 |
| 9892141 | Darcy | Feb 2018 | B2 |
| 9892400 | Grassadonia | Feb 2018 | B1 |
| 9892460 | Winklevoss et al. | Feb 2018 | B1 |
| 9892597 | Trepp et al. | Feb 2018 | B1 |
| 9894101 | Hendrick et al. | Feb 2018 | B2 |
| 9898739 | Monastyrsky et al. | Feb 2018 | B2 |
| 9898781 | Silverman | Feb 2018 | B1 |
| 9898782 | Winklevoss et al. | Feb 2018 | B1 |
| 9900841 | Ur et al. | Feb 2018 | B2 |
| 9904544 | Thomas et al. | Feb 2018 | B2 |
| 9904830 | AlNasser et al. | Feb 2018 | B2 |
| 9906513 | Wuehler | Feb 2018 | B2 |
| 9906525 | Avetisov et al. | Feb 2018 | B1 |
| 9911102 | Bowles et al. | Mar 2018 | B2 |
| 9911150 | Kassemi et al. | Mar 2018 | B2 |
| 9916290 | Soon-Shiong et al. | Mar 2018 | B2 |
| 9916432 | Bower et al. | Mar 2018 | B2 |
| 9917754 | Childress et al. | Mar 2018 | B2 |
| 9917802 | Melzer et al. | Mar 2018 | B2 |
| 9922380 | Isaacson et al. | Mar 2018 | B2 |
| 9922381 | Isaacson et al. | Mar 2018 | B2 |
| 9922498 | Fine et al. | Mar 2018 | B2 |
| 9930043 | Shuster et al. | Mar 2018 | B2 |
| 9933790 | Blackley | Apr 2018 | B2 |
| 9934138 | Bache et al. | Apr 2018 | B1 |
| 9934502 | Grassadonia et al. | Apr 2018 | B1 |
| 9935772 | Madisetti et al. | Apr 2018 | B1 |
| 9935948 | Schultz et al. | Apr 2018 | B2 |
| 9940663 | Ward et al. | Apr 2018 | B2 |
| 9940779 | To et al. | Apr 2018 | B2 |
| 9942046 | Drego et al. | Apr 2018 | B2 |
| 9942048 | Oberheide et al. | Apr 2018 | B2 |
| 9942217 | Gulledge | Apr 2018 | B2 |
| 9942231 | Laucius et al. | Apr 2018 | B1 |
| 9942250 | Stiansen et al. | Apr 2018 | B2 |
| 9947033 | Stickle et al. | Apr 2018 | B1 |
| 9948468 | Nayshtut et al. | Apr 2018 | B2 |
| 9948682 | Anton et al. | Apr 2018 | B2 |
| 9949697 | Iscoe et al. | Apr 2018 | B2 |
| 9952908 | Nedeltchev et al. | Apr 2018 | B2 |
| 9953347 | Spitz et al. | Apr 2018 | B2 |
| 9958840 | Kniazev et al. | May 2018 | B2 |
| 9959065 | Ateniese et al. | May 2018 | B2 |
| 9959080 | Krilivsky | May 2018 | B2 |
| 9960909 | Karighattam et al. | May 2018 | B2 |
| 9960920 | Cuende et al. | May 2018 | B2 |
| 9961050 | Gvili | May 2018 | B2 |
| 9965628 | Ford et al. | May 2018 | B2 |
| 9965804 | Winklevoss et al. | May 2018 | B1 |
| 9965805 | Winklevoss et al. | May 2018 | B1 |
| 9967088 | Ateniese et al. | May 2018 | B2 |
| 9967091 | Vandervort | May 2018 | B2 |
| 9967096 | Ateniese et al. | May 2018 | B2 |
| 9967102 | Osborne et al. | May 2018 | B2 |
| 9967238 | Hogan et al. | May 2018 | B1 |
| 9967333 | Chen et al. | May 2018 | B2 |
| 9967334 | Ford | May 2018 | B2 |
| 9967747 | Rotter et al. | May 2018 | B2 |
| 9973341 | Ferrin | May 2018 | B2 |
| 9979718 | Kurian | May 2018 | B2 |
| 9979719 | Oberheide et al. | May 2018 | B2 |
| 9984243 | Ho | May 2018 | B1 |
| 9985699 | Cronin | May 2018 | B1 |
| 9985937 | Ho | May 2018 | B1 |
| 9985964 | Andrade | May 2018 | B2 |
| 9986305 | Briggs et al. | May 2018 | B2 |
| D820859 | Yamazaki et al. | Jun 2018 | S |
| 9987743 | Izhikevich et al. | Jun 2018 | B2 |
| 9990418 | Rogers | Jun 2018 | B1 |
| 9990504 | Chapman et al. | Jun 2018 | B1 |
| 9992022 | Chapman et al. | Jun 2018 | B1 |
| 9992028 | Androulaki et al. | Jun 2018 | B2 |
| 9992194 | Oberheide et al. | Jun 2018 | B2 |
| 9992620 | Curry et al. | Jun 2018 | B2 |
| 9994339 | Colson et al. | Jun 2018 | B2 |
| 9996325 | Lim et al. | Jun 2018 | B2 |
| 9997023 | Fine et al. | Jun 2018 | B2 |
| 9998150 | Lazier | Jun 2018 | B1 |
| 9998282 | Oberheide et al. | Jun 2018 | B2 |
| 9998286 | Ramathal et al. | Jun 2018 | B1 |
| 9998539 | Brock et al. | Jun 2018 | B1 |
| 10002277 | Endress et al. | Jun 2018 | B1 |
| 10002362 | Endress et al. | Jun 2018 | B1 |
| 10002389 | Winklevoss et al. | Jun 2018 | B1 |
| 10002396 | Isaacson et al. | Jun 2018 | B2 |
| 10003507 | Wood et al. | Jun 2018 | B2 |
| 10004429 | Shoshan | Jun 2018 | B2 |
| 10007405 | D'Amore et al. | Jun 2018 | B2 |
| 10007826 | Ebrahimi et al. | Jun 2018 | B2 |
| 10007893 | Emmerson | Jun 2018 | B2 |
| 10007913 | Ebrahimi | Jun 2018 | B2 |
| D824404 | Di Nicola et al. | Jul 2018 | S |
| 10012398 | Swanson | Jul 2018 | B2 |
| 10013548 | Oberheide et al. | Jul 2018 | B2 |
| 10013836 | Finn | Jul 2018 | B2 |
| 10019696 | Keohane et al. | Jul 2018 | B2 |
| 10019874 | Trepp et al. | Jul 2018 | B1 |
| 10021113 | Oberheide et al. | Jul 2018 | B2 |
| 10022613 | Tran et al. | Jul 2018 | B2 |
| 10022614 | Tran et al. | Jul 2018 | B1 |
| 10025797 | Fonss | Jul 2018 | B1 |
| 10025887 | Santarone et al. | Jul 2018 | B1 |
| 10025941 | Griffin et al. | Jul 2018 | B1 |
| 10026082 | Davis | Jul 2018 | B2 |
| 10026118 | Castinado et al. | Jul 2018 | B2 |
| 10031775 | Modani et al. | Jul 2018 | B2 |
| 10035065 | Schupak et al. | Jul 2018 | B2 |
| 10037527 | Han et al. | Jul 2018 | B2 |
| 10037533 | Caldera | Jul 2018 | B2 |
| 10042782 | Struttmann | Aug 2018 | B2 |
| 10043174 | Chikkanna | Aug 2018 | B1 |
| 10046228 | Tran et al. | Aug 2018 | B2 |
| 10046521 | Walker et al. | Aug 2018 | B2 |
| 10049017 | Karame et al. | Aug 2018 | B2 |
| 10050779 | Alness et al. | Aug 2018 | B2 |
| 10050959 | Soon-Shiong et al. | Aug 2018 | B2 |
| 10055446 | Pattanaik et al. | Aug 2018 | B2 |
| 10055554 | Papa et al. | Aug 2018 | B2 |
| 10055715 | Grassadonia et al. | Aug 2018 | B1 |
| 10055720 | MacGregor et al. | Aug 2018 | B2 |
| 10055768 | Briggs et al. | Aug 2018 | B2 |
| 10055926 | Campero et al. | Aug 2018 | B2 |
| 10055935 | Arnone et al. | Aug 2018 | B2 |
| 10057065 | Reinhold | Aug 2018 | B2 |
| 10057205 | Spicer et al. | Aug 2018 | B2 |
| 10057222 | Piqueras Jover et al. | Aug 2018 | B2 |
| 10057238 | Gulledge | Aug 2018 | B2 |
| 10061668 | Lazier et al. | Aug 2018 | B1 |
| 10063529 | Milazzo et al. | Aug 2018 | B2 |
| 10063531 | Oberheide et al. | Aug 2018 | B2 |
| 10063548 | Laucius et al. | Aug 2018 | B1 |
| 10063572 | Milazzo et al. | Aug 2018 | B2 |
| 10067994 | Curtis | Sep 2018 | B2 |
| 10068228 | Winklevoss et al. | Sep 2018 | B1 |
| 10068397 | Day et al. | Sep 2018 | B2 |
| 10069672 | Curtis | Sep 2018 | B2 |
| 10075298 | Struttmann | Sep 2018 | B2 |
| 10079682 | Lu | Sep 2018 | B2 |
| 10079881 | Cohn et al. | Sep 2018 | B2 |
| 10084607 | Toll et al. | Sep 2018 | B2 |
| 10084816 | Zhang et al. | Sep 2018 | B2 |
| 10087783 | Sahl et al. | Oct 2018 | B2 |
| 10089176 | Donlan et al. | Oct 2018 | B1 |
| 10089489 | Goldfarb et al. | Oct 2018 | B2 |
| 10089492 | Shah | Oct 2018 | B2 |
| 10089819 | Halvorson et al. | Oct 2018 | B1 |
| 10089830 | Aleksey | Oct 2018 | B2 |
| 10091180 | Moritz et al. | Oct 2018 | B1 |
| 10095253 | Whidden et al. | Oct 2018 | B2 |
| 10095549 | Needham et al. | Oct 2018 | B1 |
| 10097344 | Davis | Oct 2018 | B2 |
| 10097345 | Agrawal et al. | Oct 2018 | B2 |
| 10097356 | Zinder | Oct 2018 | B2 |
| 10097362 | Lòpez Quirarte | Oct 2018 | B2 |
| 10097558 | Roth et al. | Oct 2018 | B2 |
| 10102065 | Franklin | Oct 2018 | B1 |
| 10102265 | Madisetti et al. | Oct 2018 | B1 |
| 10102510 | Yau et al. | Oct 2018 | B2 |
| 10102526 | Madisetti et al. | Oct 2018 | B1 |
| 10103885 | Davis | Oct 2018 | B2 |
| 10103893 | Kroonmaa et al. | Oct 2018 | B2 |
| 10103953 | Chang et al. | Oct 2018 | B1 |
| 10104198 | Ho | Oct 2018 | B1 |
| 10108589 | Soon-Shiong et al. | Oct 2018 | B2 |
| 10108812 | Ansari et al. | Oct 2018 | B2 |
| 10108819 | Donlan et al. | Oct 2018 | B1 |
| 10108938 | Brock et al. | Oct 2018 | B1 |
| 10108954 | Dunlevy et al. | Oct 2018 | B2 |
| 10110385 | Rush et al. | Oct 2018 | B1 |
| 10110576 | Ateniese et al. | Oct 2018 | B2 |
| 10114854 | Batra et al. | Oct 2018 | B2 |
| 10114963 | Griffin et al. | Oct 2018 | B1 |
| 10114969 | Chaney et al. | Oct 2018 | B1 |
| 10114970 | Goldfarb et al. | Oct 2018 | B2 |
| 10114980 | Barinov et al. | Oct 2018 | B2 |
| 10115068 | Vivier | Oct 2018 | B2 |
| 10116453 | Oberheide et al. | Oct 2018 | B2 |
| 10116657 | Andrade | Oct 2018 | B2 |
| 10116667 | Johnsrud | Oct 2018 | B2 |
| 10116765 | Orbach | Oct 2018 | B2 |
| 10121019 | Struttmann | Nov 2018 | B2 |
| 10121025 | Rice | Nov 2018 | B1 |
| 10121126 | Lamison-White | Nov 2018 | B2 |
| 10121143 | Madisetti et al. | Nov 2018 | B1 |
| 10121172 | Hudson et al. | Nov 2018 | B2 |
| 10121186 | Isaacson et al. | Nov 2018 | B2 |
| 10121215 | Branscomb et al. | Nov 2018 | B2 |
| 10121339 | Strulovitch et al. | Nov 2018 | B2 |
| 10127105 | Donlan | Nov 2018 | B1 |
| 10127368 | Anderson et al. | Nov 2018 | B2 |
| 10127378 | Toth | Nov 2018 | B2 |
| 10127528 | Solis | Nov 2018 | B2 |
| 10127552 | Ronca et al. | Nov 2018 | B2 |
| 10127647 | Forutanpour et al. | Nov 2018 | B2 |
| 10129032 | Vandervort | Nov 2018 | B2 |
| 10129238 | Kurian et al. | Nov 2018 | B2 |
| 10129250 | Oberheide et al. | Nov 2018 | B2 |
| 10130013 | Iyengar et al. | Nov 2018 | B1 |
| 10130195 | Phillips et al. | Nov 2018 | B2 |
| 10134201 | Hudson et al. | Nov 2018 | B2 |
| 10135607 | Roets | Nov 2018 | B1 |
| 10135609 | Bibera et al. | Nov 2018 | B2 |
| 10135616 | Finlow-Bates | Nov 2018 | B2 |
| 10135793 | Durniak et al. | Nov 2018 | B2 |
| 10135834 | Galebach et al. | Nov 2018 | B1 |
| 10135870 | Castinado et al. | Nov 2018 | B2 |
| 10135921 | Finlow-Bates | Nov 2018 | B2 |
| 10136098 | Altenburger et al. | Nov 2018 | B2 |
| 10140470 | Kurian et al. | Nov 2018 | B2 |
| 10140602 | Kelly et al. | Nov 2018 | B2 |
| 10140658 | Bagherzadeh | Nov 2018 | B1 |
| 10142098 | Suresh et al. | Nov 2018 | B2 |
| 10142312 | Johnsrud et al. | Nov 2018 | B2 |
| 10142333 | Griffin et al. | Nov 2018 | B1 |
| 10142347 | Kurian | Nov 2018 | B2 |
| 10146792 | Dobrek et al. | Dec 2018 | B1 |
| 10146947 | Chapman et al. | Dec 2018 | B1 |
| 10147264 | Halvorson | Dec 2018 | B1 |
| 10147428 | Shastry et al. | Dec 2018 | B1 |
| 10148441 | Kaliski, Jr. | Dec 2018 | B2 |
| 10152756 | Isaacson et al. | Dec 2018 | B2 |
| 10153905 | Kaliski, Jr. | Dec 2018 | B2 |
| 10153939 | Curtis | Dec 2018 | B2 |
| 10153983 | Castinado et al. | Dec 2018 | B2 |
| 10154029 | Griffin | Dec 2018 | B1 |
| 10157078 | Curtis | Dec 2018 | B2 |
| 10157294 | Szymanski et al. | Dec 2018 | B2 |
| 10157295 | Barinov et al. | Dec 2018 | B2 |
| 10157380 | Angrish et al. | Dec 2018 | B2 |
| 10158480 | Winklevoss et al. | Dec 2018 | B1 |
| 10158492 | Pearce | Dec 2018 | B2 |
| 10158527 | Anderson et al. | Dec 2018 | B2 |
| 10158703 | Kurian | Dec 2018 | B2 |
| 10158737 | Curtis | Dec 2018 | B2 |
| 10162519 | Hoffman | Dec 2018 | B2 |
| 10162704 | Kirschner et al. | Dec 2018 | B1 |
| 10162954 | Davis et al. | Dec 2018 | B2 |
| 10163079 | Brock et al. | Dec 2018 | B1 |
| 10163080 | Chow et al. | Dec 2018 | B2 |
| 10163297 | Bosak et al. | Dec 2018 | B1 |
| 10164773 | Suresh et al. | Dec 2018 | B2 |
| 10164779 | Uhr et al. | Dec 2018 | B2 |
| 10164952 | Vandervort | Dec 2018 | B2 |
| 10166675 | Izhikevich et al. | Jan 2019 | B2 |
| 10168693 | Kingston et al. | Jan 2019 | B2 |
| 10169433 | Lerios et al. | Jan 2019 | B2 |
| 10169586 | Maciejak et al. | Jan 2019 | B2 |
| 10169614 | Brady et al. | Jan 2019 | B2 |
| 10169770 | Glazier et al. | Jan 2019 | B2 |
| 10169937 | Zwink et al. | Jan 2019 | B1 |
| 10171245 | Wilkins et al. | Jan 2019 | B2 |
| 10171555 | Spitz et al. | Jan 2019 | B2 |
| 10171967 | Ameixieira | Jan 2019 | B2 |
| 10176308 | Mintz et al. | Jan 2019 | B2 |
| 10176309 | Tormasov et al. | Jan 2019 | B2 |
| 10176352 | AlNasser et al. | Jan 2019 | B2 |
| 10176481 | Aljawhari | Jan 2019 | B2 |
| 10176671 | Halvorson | Jan 2019 | B1 |
| 10177908 | Hamel et al. | Jan 2019 | B2 |
| 10178069 | Li et al. | Jan 2019 | B2 |
| 10178105 | Kurian et al. | Jan 2019 | B2 |
| 10180912 | Franklin et al. | Jan 2019 | B1 |
| 10181113 | Rivalto et al. | Jan 2019 | B2 |
| 10182051 | Andrade | Jan 2019 | B1 |
| 10183214 | Katz | Jan 2019 | B2 |
| 10185550 | Smith et al. | Jan 2019 | B2 |
| 10185759 | Goldberg | Jan 2019 | B2 |
| 10185917 | Greystoke et al. | Jan 2019 | B2 |
| 10185928 | Quezada | Jan 2019 | B2 |
| 10186115 | Fine et al. | Jan 2019 | B2 |
| 10187203 | Hamel et al. | Jan 2019 | B2 |
| 10187214 | Ferrin | Jan 2019 | B2 |
| 10187369 | Caldera et al. | Jan 2019 | B2 |
| 10187373 | Poole | Jan 2019 | B1 |
| 10192073 | Marin | Jan 2019 | B2 |
| 10193695 | Endress et al. | Jan 2019 | B1 |
| 10193696 | Struttmann et al. | Jan 2019 | B2 |
| 10193884 | Griffin et al. | Jan 2019 | B1 |
| 10194320 | Egner et al. | Jan 2019 | B1 |
| 10195513 | Tran et al. | Feb 2019 | B2 |
| 10198311 | Donlan et al. | Feb 2019 | B1 |
| 10198325 | Davis | Feb 2019 | B2 |
| 10198905 | Arnone et al. | Feb 2019 | B2 |
| 10198908 | Dabrowski | Feb 2019 | B2 |
| 10198949 | Becker | Feb 2019 | B2 |
| 10200196 | Rodriguez De Castro | Feb 2019 | B1 |
| 10200197 | Li et al. | Feb 2019 | B1 |
| 10200198 | Ganesan et al. | Feb 2019 | B2 |
| 10200199 | Truu et al. | Feb 2019 | B2 |
| 10200834 | Tran et al. | Feb 2019 | B2 |
| 10204148 | Madisetti et al. | Feb 2019 | B2 |
| 10204339 | Madisetti et al. | Feb 2019 | B2 |
| 10204341 | Davis | Feb 2019 | B2 |
| 10204378 | Wnuk | Feb 2019 | B1 |
| 10204472 | Halvorson et al. | Feb 2019 | B1 |
| 10206082 | Khan et al. | Feb 2019 | B2 |
| 10210502 | Filler | Feb 2019 | B2 |
| 10217037 | Di Iorio et al. | Feb 2019 | B1 |
| 10219744 | Mauro et al. | Mar 2019 | B2 |
| 10223096 | Ziat et al. | Mar 2019 | B2 |
| 10223520 | Oberheide et al. | Mar 2019 | B2 |
| 10223685 | Cole | Mar 2019 | B2 |
| 10223873 | Bosak | Mar 2019 | B1 |
| 10225076 | Leng et al. | Mar 2019 | B2 |
| 10225078 | Bibera et al. | Mar 2019 | B2 |
| 10225289 | Tucker, IV et al. | Mar 2019 | B1 |
| 10225614 | Andrews, II et al. | Mar 2019 | B2 |
| 10229275 | Unitt | Mar 2019 | B2 |
| 10229396 | Shtylman et al. | Mar 2019 | B2 |
| 10229400 | Kassemi et al. | Mar 2019 | B2 |
| 10230526 | Manning | Mar 2019 | B2 |
| 10230530 | Lancashire et al. | Mar 2019 | B2 |
| 10231077 | Raduchel et al. | Mar 2019 | B2 |
| 10231652 | Mauro | Mar 2019 | B2 |
| 10235402 | Franklin et al. | Mar 2019 | B1 |
| 10235529 | Ho | Mar 2019 | B1 |
| 10235538 | Uhr et al. | Mar 2019 | B2 |
| 10235726 | Branscomb et al. | Mar 2019 | B2 |
| 10236006 | Gurijala et al. | Mar 2019 | B1 |
| 10237062 | Oberheide et al. | Mar 2019 | B2 |
| 10237064 | Hoy et al. | Mar 2019 | B2 |
| 10237259 | Ronda et al. | Mar 2019 | B2 |
| 10237583 | Allen | Mar 2019 | B1 |
| 10238288 | Gupta et al. | Mar 2019 | B2 |
| 10241842 | Smith et al. | Mar 2019 | B2 |
| 10242219 | Struttmann | Mar 2019 | B2 |
| 10242538 | Pierce et al. | Mar 2019 | B2 |
| 10243731 | Velissarios et al. | Mar 2019 | B2 |
| 10243738 | Chase et al. | Mar 2019 | B2 |
| 10243743 | Madisetti et al. | Mar 2019 | B1 |
| 10243748 | Callan et al. | Mar 2019 | B1 |
| 10243934 | Ho | Mar 2019 | B1 |
| 10248119 | Kentley-Klay et al. | Apr 2019 | B2 |
| 10248793 | Kirschner | Apr 2019 | B1 |
| 10248813 | Anderson et al. | Apr 2019 | B2 |
| 10249114 | Day et al. | Apr 2019 | B2 |
| 10250381 | Rice | Apr 2019 | B1 |
| 10250522 | Anderson | Apr 2019 | B1 |
| 10250535 | Kassemi et al. | Apr 2019 | B2 |
| 10250583 | Caldera et al. | Apr 2019 | B2 |
| 10250694 | Mankovskii et al. | Apr 2019 | B2 |
| 10252145 | Tran et al. | Apr 2019 | B2 |
| 10255001 | Warstler | Apr 2019 | B2 |
| 10255108 | Dillenberger et al. | Apr 2019 | B2 |
| 10255342 | Madisetti et al. | Apr 2019 | B2 |
| 10255442 | Sanso et al. | Apr 2019 | B2 |
| 10255460 | Wilson | Apr 2019 | B2 |
| 10255600 | Ronca et al. | Apr 2019 | B2 |
| 10255625 | Liberty et al. | Apr 2019 | B2 |
| 10255635 | Winklevoss et al. | Apr 2019 | B1 |
| 10256829 | Bertsch et al. | Apr 2019 | B1 |
| 10256974 | Rodriguez De Castro | Apr 2019 | B1 |
| 10257268 | Cencini et al. | Apr 2019 | B2 |
| 10257270 | Cohn et al. | Apr 2019 | B2 |
| 10257496 | Peeters et al. | Apr 2019 | B2 |
| 10257819 | Jalkanen et al. | Apr 2019 | B2 |
| 10257960 | Banerjee et al. | Apr 2019 | B1 |
| 10261726 | Krilivsky | Apr 2019 | B2 |
| 10262138 | Boutnaru | Apr 2019 | B2 |
| 10262140 | Smith et al. | Apr 2019 | B2 |
| 10262163 | Rodriguez De Castro | Apr 2019 | B1 |
| 10262164 | Rodriguez De Castro et al. | Apr 2019 | B2 |
| 10262311 | Cronin et al. | Apr 2019 | B1 |
| 10262318 | Cronin | Apr 2019 | B1 |
| 10262321 | Ramanathan et al. | Apr 2019 | B1 |
| 10262351 | Boemi et al. | Apr 2019 | B2 |
| 10262377 | Angelovski et al. | Apr 2019 | B2 |
| 10268782 | Santarone et al. | Apr 2019 | B1 |
| 10268829 | Roets et al. | Apr 2019 | B2 |
| 10268994 | Spitz et al. | Apr 2019 | B2 |
| 10269004 | Tyler et al. | Apr 2019 | B2 |
| 10269009 | Winklevoss et al. | Apr 2019 | B1 |
| 10269012 | Miller et al. | Apr 2019 | B2 |
| 10269073 | Bodson et al. | Apr 2019 | B1 |
| 10269110 | Forutanpour et al. | Apr 2019 | B2 |
| 10270475 | Lazier | Apr 2019 | B1 |
| 10270476 | Lazier | Apr 2019 | B1 |
| 10270599 | Nadeau et al. | Apr 2019 | B2 |
| 10270600 | Vandervort | Apr 2019 | B2 |
| 10275363 | Zaydman et al. | Apr 2019 | B2 |
| 10275627 | Endress et al. | Apr 2019 | B2 |
| 10275772 | Ronca et al. | Apr 2019 | B2 |
| 10275902 | Bradski | Apr 2019 | B2 |
| 10277400 | Griffin et al. | Apr 2019 | B1 |
| 10277561 | Cox et al. | Apr 2019 | B2 |
| 10282554 | Seger, II et al. | May 2019 | B2 |
| 10282741 | Yu et al. | May 2019 | B2 |
| 10282798 | Sheppard et al. | May 2019 | B2 |
| 10282938 | Halvorson | May 2019 | B1 |
| 10284379 | Muftic | May 2019 | B1 |
| 10285133 | Ur et al. | May 2019 | B2 |
| 10289631 | Madisetti et al. | May 2019 | B2 |
| 10289716 | Astigarraga et al. | May 2019 | B1 |
| 10289816 | Malassenet et al. | May 2019 | B1 |
| 10289915 | Bertsch et al. | May 2019 | B1 |
| 10289987 | Walker et al. | May 2019 | B1 |
| 10289989 | Kelly et al. | May 2019 | B2 |
| 10291408 | Campagna et al. | May 2019 | B2 |
| 10291413 | Ramathal et al. | May 2019 | B2 |
| 10291627 | Gleichauf | May 2019 | B2 |
| 10293263 | Thompson et al. | May 2019 | B2 |
| 10296248 | Ateniese et al. | May 2019 | B2 |
| 10296729 | Bertsch et al. | May 2019 | B1 |
| 10296764 | Batishchev | May 2019 | B1 |
| 10296794 | Ratti | May 2019 | B2 |
| 10296865 | Schmidt | May 2019 | B2 |
| 10296894 | Tyler et al. | May 2019 | B2 |
| 10297094 | Day et al. | May 2019 | B2 |
| 10297106 | Simons | May 2019 | B1 |
| 10298259 | Lazier | May 2019 | B1 |
| 10298396 | Kurani et al. | May 2019 | B1 |
| 10298405 | Ramathal et al. | May 2019 | B2 |
| 10298571 | Andrade | May 2019 | B2 |
| 10298572 | Andrade | May 2019 | B2 |
| 10298585 | Treat et al. | May 2019 | B1 |
| 10303877 | Roguine et al. | May 2019 | B2 |
| 10303887 | Black et al. | May 2019 | B2 |
| 10304078 | Rulli et al. | May 2019 | B2 |
| 10304143 | Kasper et al. | May 2019 | B2 |
| 10304147 | Kelly et al. | May 2019 | B2 |
| 10304280 | Halvorson | May 2019 | B1 |
| 10304283 | Fine et al. | May 2019 | B2 |
| 10304295 | Rhodes et al. | May 2019 | B1 |
| 10305694 | Dix et al. | May 2019 | B2 |
| 10305833 | Dennis | May 2019 | B1 |
| 10305875 | Ateniese et al. | May 2019 | B1 |
| 10311240 | Nissler et al. | Jun 2019 | B1 |
| 10311250 | Khi et al. | Jun 2019 | B2 |
| 10311406 | Kassemi et al. | Jun 2019 | B2 |
| 10311515 | Katsuyama et al. | Jun 2019 | B2 |
| 10311668 | Halvorson | Jun 2019 | B1 |
| 10313108 | Suresh et al. | Jun 2019 | B2 |
| 10313360 | Wilson | Jun 2019 | B2 |
| 10313376 | Thom et al. | Jun 2019 | B2 |
| 10313385 | Shakarian et al. | Jun 2019 | B2 |
| 10313510 | Chang et al. | Jun 2019 | B2 |
| 10318505 | Baird, III | Jun 2019 | B2 |
| 10318738 | Smith et al. | Jun 2019 | B2 |
| 10318747 | MacCarthaigh et al. | Jun 2019 | B1 |
| 10318753 | Anton et al. | Jun 2019 | B2 |
| 10318938 | Johnsrud et al. | Jun 2019 | B2 |
| 10320569 | Wentz et al. | Jun 2019 | B1 |
| 10320768 | Maguire et al. | Jun 2019 | B2 |
| 10320843 | Dobrek et al. | Jun 2019 | B1 |
| 10320969 | Chang et al. | Jun 2019 | B2 |
| 10321603 | Banerjee et al. | Jun 2019 | B1 |
| 10324790 | Franklin et al. | Jun 2019 | B1 |
| 10325156 | Bertsch et al. | Jun 2019 | B1 |
| 10325257 | Winklevoss et al. | Jun 2019 | B1 |
| 10325596 | Tran et al. | Jun 2019 | B1 |
| 10326766 | Egner et al. | Jun 2019 | B2 |
| 10331123 | Mattingly et al. | Jun 2019 | B2 |
| 10331412 | Sanguinetti et al. | Jun 2019 | B2 |
| 10332169 | Degaugue et al. | Jun 2019 | B2 |
| 10332205 | Russell et al. | Jun 2019 | B1 |
| 10332335 | Halvorson et al. | Jun 2019 | B2 |
| 10332336 | Halvorson | Jun 2019 | B1 |
| 10333696 | Ahmed | Jun 2019 | B2 |
| 10333705 | Smith et al. | Jun 2019 | B2 |
| 10333706 | Smith et al. | Jun 2019 | B2 |
| 10333721 | Uhr et al. | Jun 2019 | B2 |
| 10333910 | Hogan et al. | Jun 2019 | B2 |
| 10334050 | Kentley-Klay et al. | Jun 2019 | B2 |
| 10335063 | Mauro et al. | Jul 2019 | B2 |
| 10335064 | Mauro et al. | Jul 2019 | B2 |
| 10338558 | Firu et al. | Jul 2019 | B2 |
| 10338913 | Franchitti | Jul 2019 | B2 |
| 10339014 | Smith et al. | Jul 2019 | B2 |
| 10339506 | Kassemi et al. | Jul 2019 | B2 |
| 10339523 | McDonough et al. | Jul 2019 | B2 |
| 10339750 | Wegelin | Jul 2019 | B1 |
| 10339754 | Halvorson | Jul 2019 | B1 |
| 10340038 | Witchey | Jul 2019 | B2 |
| 10341105 | Innes et al. | Jul 2019 | B2 |
| 10341121 | Androulaki et al. | Jul 2019 | B2 |
| 10341123 | Ebrahimi et al. | Jul 2019 | B2 |
| 10341309 | Ramirez et al. | Jul 2019 | B1 |
| 10341431 | Finlow-Bates | Jul 2019 | B2 |
| 10346406 | Booz et al. | Jul 2019 | B2 |
| 10346428 | Madhavan et al. | Jul 2019 | B2 |
| 10346814 | Pennanen | Jul 2019 | B2 |
| 10346815 | Glover et al. | Jul 2019 | B2 |
| 10346826 | Boudville | Jul 2019 | B2 |
| 10346845 | Sherlock et al. | Jul 2019 | B2 |
| 10346846 | Kassemi et al. | Jul 2019 | B2 |
| 10346848 | Ziat et al. | Jul 2019 | B2 |
| 10346869 | Ahmed et al. | Jul 2019 | B1 |
| 10347026 | Tokuchi | Jul 2019 | B2 |
| 10348368 | Cronin | Jul 2019 | B2 |
| 10348484 | King | Jul 2019 | B2 |
| 10348707 | Ateniese et al. | Jul 2019 | B2 |
| 10348756 | Oberheide et al. | Jul 2019 | B2 |
| 10352797 | Gunawan et al. | Jul 2019 | B2 |
| 10354236 | Wang | Jul 2019 | B1 |
| 10354301 | Chang et al. | Jul 2019 | B2 |
| 10354325 | Skala et al. | Jul 2019 | B1 |
| 10354494 | Hartl | Jul 2019 | B2 |
| 10355869 | Bisti | Jul 2019 | B2 |
| 10356066 | Ateniese et al. | Jul 2019 | B2 |
| 10356094 | Anton et al. | Jul 2019 | B2 |
| 10356099 | Caldera et al. | Jul 2019 | B2 |
| 10361849 | Smith et al. | Jul 2019 | B2 |
| 10361859 | Clark et al. | Jul 2019 | B2 |
| 10361870 | Chow et al. | Jul 2019 | B2 |
| 10362010 | Sharp et al. | Jul 2019 | B2 |
| 10362058 | Hu et al. | Jul 2019 | B2 |
| 10362278 | Palazzolo et al. | Jul 2019 | B1 |
| 10362517 | Crawford | Jul 2019 | B2 |
| 10365981 | Marripudi et al. | Jul 2019 | B2 |
| 10366062 | Lazier et al. | Jul 2019 | B1 |
| 10366204 | Tanner, Jr. et al. | Jul 2019 | B2 |
| 10366247 | Beecham et al. | Jul 2019 | B2 |
| 10366388 | Campero et al. | Jul 2019 | B2 |
| 10366419 | Storti | Jul 2019 | B2 |
| 10367353 | McNamara et al. | Jul 2019 | B1 |
| 10367645 | Dechu et al. | Jul 2019 | B2 |
| 10367803 | Adrian | Jul 2019 | B2 |
| 10367905 | Kouru et al. | Jul 2019 | B2 |
| 10372942 | Uhr et al. | Aug 2019 | B1 |
| 10372943 | Rodriguez De Castro et al. | Aug 2019 | B1 |
| 10373129 | James et al. | Aug 2019 | B1 |
| 10373158 | James et al. | Aug 2019 | B1 |
| 10373426 | Robinson et al. | Aug 2019 | B2 |
| 10373438 | Fine et al. | Aug 2019 | B2 |
| 10373441 | Halvorson | Aug 2019 | B1 |
| 10375037 | Baird, III et al. | Aug 2019 | B2 |
| 10375105 | Kozloski et al. | Aug 2019 | B2 |
| 10380359 | Naqvi et al. | Aug 2019 | B2 |
| 10380373 | Rong et al. | Aug 2019 | B2 |
| 10380574 | Crites | Aug 2019 | B2 |
| 10380589 | Studnitzer | Aug 2019 | B2 |
| 10380594 | Bayer et al. | Aug 2019 | B1 |
| 10380613 | Liu | Aug 2019 | B1 |
| 10380682 | Kundu | Aug 2019 | B2 |
| 10380685 | Phillips et al. | Aug 2019 | B1 |
| 10380702 | McCoy et al. | Aug 2019 | B2 |
| 10380812 | Pickover et al. | Aug 2019 | B2 |
| 10380842 | Jayachandran | Aug 2019 | B2 |
| 10381758 | Scanlon | Aug 2019 | B1 |
| 10382196 | Shields et al. | Aug 2019 | B2 |
| 10382205 | Ko | Aug 2019 | B1 |
| 10382208 | Shields et al. | Aug 2019 | B2 |
| 10382388 | Li et al. | Aug 2019 | B2 |
| 10386988 | Koh et al. | Aug 2019 | B1 |
| 10387850 | Srinivasan | Aug 2019 | B1 |
| 10387878 | Johnsrud et al. | Aug 2019 | B2 |
| 10387881 | Studnitzer | Aug 2019 | B2 |
| 10387950 | Dziuk | Aug 2019 | B2 |
| 10388097 | Ivanov et al. | Aug 2019 | B1 |
| 10388106 | Arnone et al. | Aug 2019 | B2 |
| 10389518 | Chen et al. | Aug 2019 | B2 |
| 10389535 | Fiege et al. | Aug 2019 | B2 |
| 10389713 | Andrade | Aug 2019 | B2 |
| 10389749 | Kozloski et al. | Aug 2019 | B2 |
| 10390458 | Tufty et al. | Aug 2019 | B2 |
| 10391628 | Izhikevich et al. | Aug 2019 | B2 |
| 10394762 | Franklin et al. | Aug 2019 | B1 |
| 10394789 | Animesh et al. | Aug 2019 | B1 |
| 10394845 | Madisetti et al. | Aug 2019 | B2 |
| 10395053 | Samid | Aug 2019 | B2 |
| 10395058 | Kothavale et al. | Aug 2019 | B1 |
| 10395062 | Uhr et al. | Aug 2019 | B2 |
| 10396988 | Davis | Aug 2019 | B2 |
| 10396992 | Anton et al. | Aug 2019 | B2 |
| 10396997 | Brady et al. | Aug 2019 | B2 |
| 10396999 | Zhang | Aug 2019 | B2 |
| 10397328 | Bohli et al. | Aug 2019 | B2 |
| 10401411 | Snook et al. | Sep 2019 | B2 |
| 10402594 | Takaai et al. | Sep 2019 | B2 |
| 10402792 | Lin et al. | Sep 2019 | B2 |
| 10402793 | Haldenby et al. | Sep 2019 | B2 |
| 10402796 | Castagna | Sep 2019 | B2 |
| 10402808 | Peterson | Sep 2019 | B1 |
| 10402823 | Vlasov et al. | Sep 2019 | B1 |
| 10402829 | Baar et al. | Sep 2019 | B1 |
| 10402845 | Glazier et al. | Sep 2019 | B2 |
| 10403093 | Halvorson | Sep 2019 | B1 |
| 10404454 | Rodriguez De Castro | Sep 2019 | B1 |
| 10404455 | Ateniese et al. | Sep 2019 | B2 |
| 10404463 | Rodriguez De Castro | Sep 2019 | B1 |
| 10404469 | Madhavan et al. | Sep 2019 | B2 |
| 10404471 | Griffin et al. | Sep 2019 | B1 |
| 10404523 | Cencini et al. | Sep 2019 | B2 |
| 10404703 | Peterson | Sep 2019 | B1 |
| 10405215 | Tavares Coutinho et al. | Sep 2019 | B2 |
| 10406422 | Pasternak et al. | Sep 2019 | B1 |
| 10409783 | Miller et al. | Sep 2019 | B1 |
| 10409827 | Kheterpal et al. | Sep 2019 | B2 |
| 10410209 | Boyle et al. | Sep 2019 | B2 |
| 10410211 | Reese et al. | Sep 2019 | B2 |
| 10410232 | Lueken | Sep 2019 | B1 |
| 10410604 | Greco et al. | Sep 2019 | B2 |
| 10411897 | Paolini-Subramanya et al. | Sep 2019 | B2 |
| 10411905 | Smith et al. | Sep 2019 | B2 |
| 10412086 | Lintilhac et al. | Sep 2019 | B1 |
| 10412113 | Hanley et al. | Sep 2019 | B2 |
| 10412185 | Lu | Sep 2019 | B2 |
| 10412536 | Gabel | Sep 2019 | B2 |
| 10417188 | King | Sep 2019 | B2 |
| 10417217 | Pierce et al. | Sep 2019 | B2 |
| 10417615 | Bowles et al. | Sep 2019 | B2 |
| 10419152 | Hanneman, Jr. | Sep 2019 | B2 |
| 10419209 | Griffin et al. | Sep 2019 | B1 |
| 10419225 | Deery et al. | Sep 2019 | B2 |
| 10419454 | El-Moussa et al. | Sep 2019 | B2 |
| 10423921 | Wilkinson et al. | Sep 2019 | B2 |
| 10423938 | Gaeta et al. | Sep 2019 | B1 |
| 10423947 | Baar et al. | Sep 2019 | B1 |
| 10423961 | El Defrawy et al. | Sep 2019 | B1 |
| 10423993 | Metnick | Sep 2019 | B2 |
| 10424125 | Hudson et al. | Sep 2019 | B2 |
| 10424140 | Johnson et al. | Sep 2019 | B2 |
| 10424149 | Halvorson | Sep 2019 | B1 |
| 10424164 | Kehoe | Sep 2019 | B2 |
| 10425230 | Tang et al. | Sep 2019 | B1 |
| 10425426 | Simons | Sep 2019 | B1 |
| 10425428 | Krishnamurthy | Sep 2019 | B2 |
| 10425436 | Firstenberg et al. | Sep 2019 | B2 |
| 10425698 | Briggs et al. | Sep 2019 | B2 |
| 10430162 | Roetteler et al. | Oct 2019 | B2 |
| 10430499 | Soon-Shiong et al. | Oct 2019 | B2 |
| 10430563 | Mintz et al. | Oct 2019 | B2 |
| 10430574 | Anderson et al. | Oct 2019 | B2 |
| 10430751 | Wilkinson et al. | Oct 2019 | B2 |
| 10430771 | Bonestell et al. | Oct 2019 | B2 |
| 10430789 | Herald, Jr. et al. | Oct 2019 | B1 |
| 10430874 | Lee et al. | Oct 2019 | B1 |
| 10430898 | Sun et al. | Oct 2019 | B2 |
| 10432402 | Griffin et al. | Oct 2019 | B1 |
| 10432411 | Barinov et al. | Oct 2019 | B2 |
| 10433112 | Santarone et al. | Oct 2019 | B2 |
| 10435185 | Divine et al. | Oct 2019 | B2 |
| 10437328 | Nelson | Oct 2019 | B2 |
| 10437630 | Curtis | Oct 2019 | B2 |
| 10437790 | Paterra et al. | Oct 2019 | B1 |
| 10438106 | Breed et al. | Oct 2019 | B2 |
| 10438170 | Kozloski et al. | Oct 2019 | B2 |
| 10438174 | Bowles et al. | Oct 2019 | B2 |
| 10438197 | Kote | Oct 2019 | B2 |
| 10438198 | Griffin et al. | Oct 2019 | B1 |
| 10438207 | Subhedar et al. | Oct 2019 | B2 |
| 10438209 | Kurian | Oct 2019 | B2 |
| 10438249 | Briggs et al. | Oct 2019 | B2 |
| 10438290 | Winklevoss et al. | Oct 2019 | B1 |
| 10440101 | Kurian et al. | Oct 2019 | B2 |
| 10444818 | McNamara et al. | Oct 2019 | B1 |
| 10445643 | Katz et al. | Oct 2019 | B2 |
| 10445698 | Hunn | Oct 2019 | B2 |
| 10445708 | Hunt et al. | Oct 2019 | B2 |
| 10445709 | McDonald et al. | Oct 2019 | B2 |
| 10445732 | Oberheide et al. | Oct 2019 | B2 |
| 10445754 | Snider et al. | Oct 2019 | B2 |
| 10445836 | Hertz et al. | Oct 2019 | B2 |
| 10445963 | Brandwijk | Oct 2019 | B2 |
| 10445965 | Ivanov et al. | Oct 2019 | B2 |
| 10446037 | Kentley-Klay et al. | Oct 2019 | B2 |
| 10447478 | Gray | Oct 2019 | B2 |
| 10447480 | Alas et al. | Oct 2019 | B2 |
| 10447664 | Haldenby et al. | Oct 2019 | B2 |
| 10447696 | Armknecht et al. | Oct 2019 | B2 |
| 10448064 | Allen | Oct 2019 | B1 |
| 10448251 | Maria | Oct 2019 | B1 |
| 10452127 | McNamara et al. | Oct 2019 | B1 |
| 10452863 | Miller | Oct 2019 | B2 |
| 10453065 | Wagner | Oct 2019 | B2 |
| 10453319 | Jarvis et al. | Oct 2019 | B2 |
| 10454878 | Khan et al. | Oct 2019 | B2 |
| 10454927 | Oberhauser et al. | Oct 2019 | B2 |
| 10454933 | Chenard et al. | Oct 2019 | B2 |
| 10454970 | Anton et al. | Oct 2019 | B2 |
| 10455742 | Yu et al. | Oct 2019 | B2 |
| 10459946 | Madisetti et al. | Oct 2019 | B2 |
| 10459990 | Li et al. | Oct 2019 | B1 |
| 10460118 | Hamel et al. | Oct 2019 | B2 |
| 10460283 | Madisetti et al. | Oct 2019 | B2 |
| 10460312 | Kurani et al. | Oct 2019 | B1 |
| 10460313 | Clark | Oct 2019 | B1 |
| 10460394 | Perl et al. | Oct 2019 | B2 |
| 10461940 | Cheng et al. | Oct 2019 | B2 |
| 10462153 | Stocker | Oct 2019 | B2 |
| 10462174 | Kaplan et al. | Oct 2019 | B2 |
| 10462185 | Attfield et al. | Oct 2019 | B2 |
| 10466277 | Brooks | Nov 2019 | B1 |
| 10467353 | Santarone et al. | Nov 2019 | B2 |
| 10467391 | Bertsch et al. | Nov 2019 | B1 |
| 10467506 | Tyrrell | Nov 2019 | B2 |
| 10467586 | Fuller et al. | Nov 2019 | B2 |
| 10467694 | Katsuyama et al. | Nov 2019 | B2 |
| 10467861 | Aleksey | Nov 2019 | B2 |
| 10469248 | Chalakudi et al. | Nov 2019 | B2 |
| 10469250 | Rady | Nov 2019 | B2 |
| 10469264 | Uhr et al. | Nov 2019 | B2 |
| 10469487 | Griffin et al. | Nov 2019 | B1 |
| 10469507 | El-Moussa et al. | Nov 2019 | B2 |
| 10469525 | Hittel et al. | Nov 2019 | B2 |
| 10474640 | Roche, Jr. | Nov 2019 | B1 |
| 10474836 | Cieslak et al. | Nov 2019 | B1 |
| 10474945 | McDonald et al. | Nov 2019 | B2 |
| 10475002 | Silva et al. | Nov 2019 | B2 |
| 10475030 | Castinado et al. | Nov 2019 | B2 |
| 10475062 | Narayanam et al. | Nov 2019 | B2 |
| 10475092 | Patterson | Nov 2019 | B1 |
| 10475115 | Minsley et al. | Nov 2019 | B2 |
| 10475272 | Campero et al. | Nov 2019 | B2 |
| 10475273 | Campero et al. | Nov 2019 | B2 |
| 10475275 | Halvorson | Nov 2019 | B1 |
| 10475287 | Daumling et al. | Nov 2019 | B1 |
| 10476665 | Griffin et al. | Nov 2019 | B1 |
| 10476701 | Wang et al. | Nov 2019 | B2 |
| 10476847 | Smith et al. | Nov 2019 | B1 |
| 10476879 | Bathen et al. | Nov 2019 | B2 |
| 10476907 | Hittel et al. | Nov 2019 | B2 |
| 10482288 | Rice | Nov 2019 | B2 |
| 10482446 | Cooper et al. | Nov 2019 | B2 |
| 10482470 | Larson et al. | Nov 2019 | B2 |
| 10482538 | White et al. | Nov 2019 | B1 |
| 10484168 | Ford et al. | Nov 2019 | B2 |
| 10484178 | Andrade | Nov 2019 | B2 |
| 10484341 | Todd et al. | Nov 2019 | B1 |
| 10484346 | Russinovich et al. | Nov 2019 | B2 |
| 10484376 | Laucius et al. | Nov 2019 | B1 |
| 10484413 | Kar et al. | Nov 2019 | B2 |
| 10484415 | Peterson | Nov 2019 | B1 |
| 10489385 | Baird, III et al. | Nov 2019 | B2 |
| 10489485 | Wu et al. | Nov 2019 | B2 |
| 10489709 | Katz et al. | Nov 2019 | B2 |
| 10489757 | Melika et al. | Nov 2019 | B2 |
| 10489780 | Miller et al. | Nov 2019 | B2 |
| 10489834 | Gupta | Nov 2019 | B2 |
| 10489837 | Degaugue et al. | Nov 2019 | B2 |
| 10491375 | Maggu et al. | Nov 2019 | B2 |
| 10491378 | Binning et al. | Nov 2019 | B2 |
| 10491396 | Uhr et al. | Nov 2019 | B2 |
| 10491402 | Kaehler | Nov 2019 | B2 |
| 10491404 | Yamamoto | Nov 2019 | B1 |
| 10491414 | Weed et al. | Nov 2019 | B1 |
| 10491608 | Tatge et al. | Nov 2019 | B1 |
| 10492337 | Kim | Nov 2019 | B2 |
| 10493996 | Phillips et al. | Dec 2019 | B2 |
| 10496327 | Paterra et al. | Dec 2019 | B1 |
| 10496633 | Pattanaik et al. | Dec 2019 | B2 |
| 10496914 | Scaife et al. | Dec 2019 | B2 |
| 10496923 | Katz et al. | Dec 2019 | B2 |
| 10496963 | Silva et al. | Dec 2019 | B2 |
| 10496976 | Singh et al. | Dec 2019 | B2 |
| 10496989 | Castinado et al. | Dec 2019 | B2 |
| 10496994 | Hopper | Dec 2019 | B2 |
| 10497037 | Isaacson et al. | Dec 2019 | B2 |
| 10497209 | Macdonald | Dec 2019 | B2 |
| 10497325 | Staton et al. | Dec 2019 | B1 |
| 10498535 | Bohli et al. | Dec 2019 | B2 |
| 10498541 | Ebrahimi et al. | Dec 2019 | B2 |
| 10498542 | Ebrahimi et al. | Dec 2019 | B2 |
| 10499525 | Singh | Dec 2019 | B1 |
| 10503614 | Abraham et al. | Dec 2019 | B2 |
| 10503750 | Curtis | Dec 2019 | B2 |
| 10503933 | Auh | Dec 2019 | B2 |
| 10504080 | Melika et al. | Dec 2019 | B2 |
| 10504163 | Dogin et al. | Dec 2019 | B2 |
| 10504178 | Pierce et al. | Dec 2019 | B2 |
| 10504179 | McGuire et al. | Dec 2019 | B1 |
| 10504193 | Isaacson et al. | Dec 2019 | B2 |
| 10504314 | Ivanov et al. | Dec 2019 | B2 |
| 10504843 | de Rochemont | Dec 2019 | B2 |
| 10505708 | Xia | Dec 2019 | B2 |
| 10505717 | Davis | Dec 2019 | B2 |
| 10505720 | Li | Dec 2019 | B2 |
| 10505723 | Griffin et al. | Dec 2019 | B1 |
| 10505726 | Andon et al. | Dec 2019 | B1 |
| 10505740 | Struttmann et al. | Dec 2019 | B2 |
| 10505949 | Zhang | Dec 2019 | B2 |
| 10507787 | Ferguson et al. | Dec 2019 | B2 |
| 10509919 | Wang et al. | Dec 2019 | B1 |
| 10509932 | Ebrahimi et al. | Dec 2019 | B2 |
| 10510034 | Larson et al. | Dec 2019 | B2 |
| 10510053 | Armstrong | Dec 2019 | B2 |
| 10510079 | Larson et al. | Dec 2019 | B2 |
| 10510441 | Wall Warner et al. | Dec 2019 | B2 |
| 10511447 | Lakk | Dec 2019 | B1 |
| 10511580 | Isaacson et al. | Dec 2019 | B2 |
| 10511686 | Orbach | Dec 2019 | B2 |
| 10511827 | Peeters et al. | Dec 2019 | B2 |
| 10512839 | Nelson et al. | Dec 2019 | B2 |
| 10512843 | Cunningham et al. | Dec 2019 | B1 |
| 10515333 | Vivier | Dec 2019 | B2 |
| 10515409 | Creighton, IV et al. | Dec 2019 | B2 |
| 10515516 | Eckman et al. | Dec 2019 | B1 |
| 10518178 | Cunningham et al. | Dec 2019 | B1 |
| 10518409 | Oleynik | Dec 2019 | B2 |
| 10521593 | Kaplan et al. | Dec 2019 | B2 |
| 10521604 | Miller | Dec 2019 | B2 |
| 10521623 | Rodriguez et al. | Dec 2019 | B2 |
| 10521775 | Hearn et al. | Dec 2019 | B2 |
| 10521814 | Collins et al. | Dec 2019 | B1 |
| 10521973 | Bekas et al. | Dec 2019 | B2 |
| 10522006 | Alexander | Dec 2019 | B2 |
| 10522016 | Strulovitch et al. | Dec 2019 | B2 |
| 10522112 | Greco et al. | Dec 2019 | B2 |
| 10523421 | Hunt et al. | Dec 2019 | B2 |
| 10523443 | Kleinman | Dec 2019 | B1 |
| 10523447 | Yang | Dec 2019 | B2 |
| 10523526 | Dementev et al. | Dec 2019 | B2 |
| 10523643 | Davis et al. | Dec 2019 | B1 |
| 10526142 | Jin et al. | Jan 2020 | B2 |
| 10528377 | Vyas et al. | Jan 2020 | B2 |
| 10528551 | Li et al. | Jan 2020 | B2 |
| 10528722 | Gray | Jan 2020 | B2 |
| 10528776 | Levy et al. | Jan 2020 | B1 |
| 10528868 | Gillespie | Jan 2020 | B2 |
| 10528924 | Schwartz | Jan 2020 | B2 |
| 10528947 | Sheerin | Jan 2020 | B2 |
| 10529015 | Hill et al. | Jan 2020 | B1 |
| 10529041 | Brown et al. | Jan 2020 | B2 |
| 10529042 | Brown et al. | Jan 2020 | B2 |
| 10529190 | Halvorson | Jan 2020 | B1 |
| 10530577 | Pazhoor et al. | Jan 2020 | B1 |
| 10530585 | Lindell | Jan 2020 | B2 |
| 10530734 | Kaliski, Jr. et al. | Jan 2020 | B2 |
| 10530756 | Youngs et al. | Jan 2020 | B1 |
| 10530834 | Tian | Jan 2020 | B2 |
| 10530859 | Todd | Jan 2020 | B1 |
| 10531230 | Wootton et al. | Jan 2020 | B2 |
| 10532268 | Tran et al. | Jan 2020 | B2 |
| 10534634 | Yang et al. | Jan 2020 | B2 |
| 10534913 | Daniel et al. | Jan 2020 | B2 |
| 10535063 | Lingham et al. | Jan 2020 | B2 |
| 10535065 | Muftic | Jan 2020 | B2 |
| 10535111 | O'Brien | Jan 2020 | B2 |
| 10535207 | Goluguri et al. | Jan 2020 | B1 |
| 10536265 | Tong | Jan 2020 | B2 |
| 10536430 | Liu et al. | Jan 2020 | B2 |
| 10536434 | Kothavale et al. | Jan 2020 | B2 |
| 10536445 | Lerner | Jan 2020 | B1 |
| 10536482 | Gabaev et al. | Jan 2020 | B2 |
| 10538034 | Walker et al. | Jan 2020 | B2 |
| 10540209 | Wang | Jan 2020 | B2 |
| 10540344 | Shen et al. | Jan 2020 | B2 |
| 10540514 | Winarski | Jan 2020 | B1 |
| 10540619 | Castle et al. | Jan 2020 | B2 |
| 10540639 | Brock et al. | Jan 2020 | B2 |
| 10540640 | James et al. | Jan 2020 | B1 |
| 10540653 | James et al. | Jan 2020 | B1 |
| 10540654 | James et al. | Jan 2020 | B1 |
| 10540671 | Glazier et al. | Jan 2020 | B2 |
| 10541806 | Rosenoer | Jan 2020 | B2 |
| 10541820 | Takada Chino et al. | Jan 2020 | B2 |
| 10541821 | Toll et al. | Jan 2020 | B2 |
| 10542030 | Oberheide et al. | Jan 2020 | B2 |
| 10542046 | Katragadda et al. | Jan 2020 | B2 |
| 10542060 | Xie et al. | Jan 2020 | B2 |
| 10542800 | Gross | Jan 2020 | B2 |
| 10545491 | Kingston et al. | Jan 2020 | B2 |
| 10545794 | Qiu | Jan 2020 | B2 |
| 10546296 | Narasimhan et al. | Jan 2020 | B2 |
| 10546326 | Publicover et al. | Jan 2020 | B2 |
| 10547401 | Yu | Jan 2020 | B2 |
| 10547441 | Di Nicola et al. | Jan 2020 | B2 |
| 10547446 | Sriram et al. | Jan 2020 | B2 |
| 10547457 | Duccini et al. | Jan 2020 | B1 |
| 10547594 | Chang et al. | Jan 2020 | B2 |
| 10547643 | Varley et al. | Jan 2020 | B2 |
| 10547981 | Ye et al. | Jan 2020 | B2 |
| 10554394 | Krut | Feb 2020 | B1 |
| 10554753 | Tormasov et al. | Feb 2020 | B2 |
| 10572679 | Frank et al. | Feb 2020 | B2 |
| 10572684 | LFever et al. | Feb 2020 | B2 |
| 10581805 | Simons et al. | Mar 2020 | B2 |
| 10581869 | Simons | Mar 2020 | B2 |
| 10592985 | Ford et al. | Mar 2020 | B2 |
| 10593157 | Simons | Mar 2020 | B2 |
| 10594484 | Rodriguez et al. | Mar 2020 | B2 |
| 10600006 | Wang et al. | Mar 2020 | B1 |
| 10614661 | Simons | Apr 2020 | B2 |
| 10615960 | Zhang et al. | Apr 2020 | B2 |
| 10621164 | Kain | Apr 2020 | B1 |
| 10621366 | Campagna et al. | Apr 2020 | B2 |
| 10630468 | Wang et al. | Apr 2020 | B1 |
| 10630477 | Ju et al. | Apr 2020 | B1 |
| 10637645 | Gray | Apr 2020 | B2 |
| 10643288 | Orsini et al. | May 2020 | B2 |
| 10650313 | Ackerman et al. | May 2020 | B2 |
| 10652014 | Wright et al. | May 2020 | B2 |
| 10657595 | de Jong et al. | May 2020 | B2 |
| 10664353 | Karame et al. | May 2020 | B2 |
| 10664591 | Gray | May 2020 | B2 |
| 10664835 | Ma et al. | May 2020 | B2 |
| 10678931 | Liu et al. | Jun 2020 | B2 |
| 10680800 | Zhang et al. | Jun 2020 | B2 |
| 10681033 | Gray | Jun 2020 | B2 |
| 10685399 | Snow et al. | Jun 2020 | B2 |
| 10692085 | Zagarese et al. | Jun 2020 | B2 |
| 10700850 | Ma et al. | Jun 2020 | B2 |
| 10708039 | Zhang et al. | Jul 2020 | B1 |
| 10708250 | Simons | Jul 2020 | B2 |
| 10713731 | Karame et al. | Jul 2020 | B2 |
| 10715317 | Chari et al. | Jul 2020 | B2 |
| 10715326 | Maim | Jul 2020 | B2 |
| 10715500 | Ma et al. | Jul 2020 | B2 |
| 10719623 | Miller et al. | Jul 2020 | B1 |
| 10721058 | Housholder et al. | Jul 2020 | B2 |
| 10721217 | Treat et al. | Jul 2020 | B2 |
| 10721240 | Gleichauf | Jul 2020 | B2 |
| 10726657 | Cui et al. | Jul 2020 | B2 |
| 10728283 | Dobrek et al. | Jul 2020 | B1 |
| 10740455 | Gray | Aug 2020 | B2 |
| 10747905 | Gray | Aug 2020 | B2 |
| 10748370 | Cui et al. | Aug 2020 | B2 |
| 10748644 | Shriberg et al. | Aug 2020 | B2 |
| 10749687 | Gray | Aug 2020 | B2 |
| 10749848 | Voell et al. | Aug 2020 | B2 |
| 10755276 | Ma | Aug 2020 | B2 |
| 10761877 | Peffers et al. | Sep 2020 | B2 |
| 10762228 | Liu et al. | Sep 2020 | B2 |
| 10762506 | Cash et al. | Sep 2020 | B1 |
| 10778410 | Han et al. | Sep 2020 | B2 |
| 10789590 | Tran et al. | Sep 2020 | B2 |
| 10790961 | Lin | Sep 2020 | B2 |
| 10790964 | Chopra et al. | Sep 2020 | B2 |
| 10790987 | Zhang et al. | Sep 2020 | B2 |
| 10790990 | Zhang | Sep 2020 | B2 |
| 10797887 | Zhang | Oct 2020 | B2 |
| 10803205 | Yu et al. | Oct 2020 | B1 |
| 10803451 | Peikert et al. | Oct 2020 | B2 |
| 10810550 | Narayanan | Oct 2020 | B1 |
| 10810583 | Peikert et al. | Oct 2020 | B2 |
| 10812274 | Back et al. | Oct 2020 | B2 |
| 10817872 | Lin | Oct 2020 | B2 |
| 10819505 | Ma et al. | Oct 2020 | B2 |
| 10819959 | Palazzolo | Oct 2020 | B2 |
| 10824763 | Yu | Nov 2020 | B2 |
| 10825024 | Pennington et al. | Nov 2020 | B1 |
| 10825295 | Simons | Nov 2020 | B2 |
| 10831903 | Li et al. | Nov 2020 | B2 |
| 10832522 | Simons | Nov 2020 | B2 |
| 10833858 | Gray | Nov 2020 | B2 |
| 10839107 | Wei et al. | Nov 2020 | B2 |
| 10839411 | Benoliel et al. | Nov 2020 | B2 |
| 10841100 | Lam et al. | Nov 2020 | B2 |
| 10846372 | Jayachandran et al. | Nov 2020 | B1 |
| 10853592 | Rodriguez et al. | Dec 2020 | B2 |
| 10855455 | Wang et al. | Dec 2020 | B2 |
| 10861016 | Ma | Dec 2020 | B2 |
| 10868865 | Shadmon et al. | Dec 2020 | B2 |
| 10872487 | Komo et al. | Dec 2020 | B2 |
| 10878108 | Nicolas et al. | Dec 2020 | B1 |
| 10878429 | Bakalis | Dec 2020 | B2 |
| 10880089 | Brown et al. | Dec 2020 | B2 |
| 10885203 | Li et al. | Jan 2021 | B2 |
| 10885735 | Cui et al. | Jan 2021 | B2 |
| 10887100 | Wentz | Jan 2021 | B2 |
| 10887104 | Jayachandran et al. | Jan 2021 | B1 |
| 10892888 | Ma et al. | Jan 2021 | B2 |
| 10892894 | Baughman et al. | Jan 2021 | B2 |
| 10904000 | Gray | Jan 2021 | B2 |
| 11068978 | Ferreira | Jul 2021 | B1 |
| 20010034640 | Chaum | Oct 2001 | A1 |
| 20020007457 | Neff | Jan 2002 | A1 |
| 20020026345 | Juels | Feb 2002 | A1 |
| 20020049601 | Asokan | Apr 2002 | A1 |
| 20020073202 | Wang | Jun 2002 | A1 |
| 20020073318 | Gennaro et al. | Jun 2002 | A1 |
| 20020103999 | Camnisch et al. | Aug 2002 | A1 |
| 20020128978 | Neff | Sep 2002 | A1 |
| 20020131600 | Ionescu | Sep 2002 | A1 |
| 20020152252 | Kaminaga et al. | Oct 2002 | A1 |
| 20030028423 | Neff | Feb 2003 | A1 |
| 20030059041 | MacKenzie et al. | Mar 2003 | A1 |
| 20030074330 | Asokan et al. | Apr 2003 | A1 |
| 20030085997 | Takagi et al. | May 2003 | A1 |
| 20030191956 | Ishiguro et al. | Oct 2003 | A1 |
| 20040003278 | Chen et al. | Jan 2004 | A1 |
| 20040062399 | Takase | Apr 2004 | A1 |
| 20040193529 | Asher | Sep 2004 | A1 |
| 20040215828 | Li et al. | Oct 2004 | A1 |
| 20040246960 | Irish et al. | Dec 2004 | A1 |
| 20040264927 | Evans et al. | Dec 2004 | A1 |
| 20050005266 | Datig | Jan 2005 | A1 |
| 20050008152 | Mackenzie | Jan 2005 | A1 |
| 20050021479 | Jorba et al. | Jan 2005 | A1 |
| 20050028009 | Neff | Feb 2005 | A1 |
| 20050039034 | Doyle et al. | Feb 2005 | A1 |
| 20050099960 | Boss et al. | May 2005 | A1 |
| 20050108391 | Boss et al. | May 2005 | A1 |
| 20050138364 | Roskind et al. | Jun 2005 | A1 |
| 20050144468 | Northcutt et al. | Jun 2005 | A1 |
| 20050152596 | Walmsley | Jul 2005 | A1 |
| 20050153624 | Wieland et al. | Jul 2005 | A1 |
| 20050182937 | Bedi | Aug 2005 | A1 |
| 20050193048 | Vaudenay et al. | Sep 2005 | A1 |
| 20060015737 | Canard et al. | Jan 2006 | A1 |
| 20060052962 | Shipton et al. | Mar 2006 | A1 |
| 20060059333 | Gentry et al. | Mar 2006 | A1 |
| 20060063205 | Carlson | Mar 2006 | A1 |
| 20060071951 | Walmsley et al. | Apr 2006 | A1 |
| 20060071981 | Plunkett | Apr 2006 | A1 |
| 20060082609 | Walmsley et al. | Apr 2006 | A1 |
| 20060085647 | Neff | Apr 2006 | A1 |
| 20060085651 | Staddon et al. | Apr 2006 | A1 |
| 20060098814 | Al-Khoraidly et al. | May 2006 | A1 |
| 20060136728 | Gentry et al. | Jun 2006 | A1 |
| 20060137006 | Ramzan et al. | Jun 2006 | A1 |
| 20060140401 | Johnson et al. | Jun 2006 | A1 |
| 20060156392 | Baugher | Jul 2006 | A1 |
| 20060156416 | Huotari et al. | Jul 2006 | A1 |
| 20060167784 | Hoffberg | Jul 2006 | A1 |
| 20060190378 | Szydlo | Aug 2006 | A1 |
| 20060205011 | Carlson | Sep 2006 | A1 |
| 20060242699 | Ramzan et al. | Oct 2006 | A1 |
| 20060248334 | Ramzan et al. | Nov 2006 | A1 |
| 20070005594 | Pinkas et al. | Jan 2007 | A1 |
| 20070006150 | Walmsley | Jan 2007 | A9 |
| 20070016528 | Verhaegh et al. | Jan 2007 | A1 |
| 20070044139 | Tuyls et al. | Feb 2007 | A1 |
| 20070053506 | Takashima | Mar 2007 | A1 |
| 20070053507 | Smaragdis et al. | Mar 2007 | A1 |
| 20070053513 | Hoffberg | Mar 2007 | A1 |
| 20070074036 | Ramzan et al. | Mar 2007 | A1 |
| 20070079342 | Ellis et al. | Apr 2007 | A1 |
| 20070087756 | Hoffberg | Apr 2007 | A1 |
| 20070095909 | Chaum | May 2007 | A1 |
| 20070106908 | Miyazaki et al. | May 2007 | A1 |
| 20070116283 | Tuyls et al. | May 2007 | A1 |
| 20070118746 | Lauter et al. | May 2007 | A1 |
| 20070150404 | Golle | Jun 2007 | A1 |
| 20070150596 | Miller et al. | Jun 2007 | A1 |
| 20070156553 | Zimmerman | Jul 2007 | A1 |
| 20070156586 | Kerschbaum | Jul 2007 | A1 |
| 20070171050 | Westhoff et al. | Jul 2007 | A1 |
| 20070171851 | Beckmann et al. | Jul 2007 | A1 |
| 20070185878 | Fierstein et al. | Aug 2007 | A1 |
| 20070189519 | Neff | Aug 2007 | A1 |
| 20070192864 | Bryant et al. | Aug 2007 | A1 |
| 20070219933 | Datig | Sep 2007 | A1 |
| 20070220279 | Northcutt et al. | Sep 2007 | A1 |
| 20070233602 | Zweig et al. | Oct 2007 | A1 |
| 20070233606 | Zweig et al. | Oct 2007 | A1 |
| 20070234431 | Evans et al. | Oct 2007 | A1 |
| 20070248232 | Driscoll et al. | Oct 2007 | A1 |
| 20070250718 | Lee et al. | Oct 2007 | A1 |
| 20070280482 | Yan et al. | Dec 2007 | A1 |
| 20070299952 | Goodman et al. | Dec 2007 | A1 |
| 20080000969 | Salomonsen et al. | Jan 2008 | A1 |
| 20080002578 | Coffman et al. | Jan 2008 | A1 |
| 20080006615 | Rosario et al. | Jan 2008 | A1 |
| 20080034203 | Camnisch et al. | Feb 2008 | A1 |
| 20080037785 | Gantman et al. | Feb 2008 | A1 |
| 20080059791 | Lee et al. | Mar 2008 | A1 |
| 20080063210 | Goodman et al. | Mar 2008 | A1 |
| 20080065882 | Goodman et al. | Mar 2008 | A1 |
| 20080065903 | Goodman et al. | Mar 2008 | A1 |
| 20080086757 | Pestoni | Apr 2008 | A1 |
| 20080114681 | Staddon et al. | May 2008 | A1 |
| 20080114682 | Staddon et al. | May 2008 | A1 |
| 20080126801 | Lee et al. | May 2008 | A1 |
| 20080130902 | Foo Kune et al. | Jun 2008 | A1 |
| 20080137863 | Thomas | Jun 2008 | A1 |
| 20080140577 | Rahman et al. | Jun 2008 | A1 |
| 20080159294 | Irish et al. | Jul 2008 | A1 |
| 20080165956 | Zhu et al. | Jul 2008 | A1 |
| 20080172233 | Smaragdis et al. | Jul 2008 | A1 |
| 20080172333 | Neff | Jul 2008 | A1 |
| 20080201398 | Meyer | Aug 2008 | A1 |
| 20080208560 | Johnson et al. | Aug 2008 | A1 |
| 20080212780 | Lemma et al. | Sep 2008 | A1 |
| 20080215897 | Doyle et al. | Sep 2008 | A1 |
| 20080216051 | Johnson et al. | Sep 2008 | A1 |
| 20080262893 | Hoffberg | Oct 2008 | A1 |
| 20080273696 | Greco et al. | Nov 2008 | A1 |
| 20080273697 | Greco et al. | Nov 2008 | A1 |
| 20080280559 | Dandekar et al. | Nov 2008 | A1 |
| 20080292104 | Loc'H et al. | Nov 2008 | A1 |
| 20080294909 | Ostrovsky et al. | Nov 2008 | A1 |
| 20080301448 | Charles et al. | Dec 2008 | A1 |
| 20080304657 | Tuyls et al. | Dec 2008 | A1 |
| 20080313264 | Pestoni | Dec 2008 | A1 |
| 20080313691 | Cholas et al. | Dec 2008 | A1 |
| 20080320300 | Gkantsidis et al. | Dec 2008 | A1 |
| 20090006855 | Tuyls et al. | Jan 2009 | A1 |
| 20090028322 | Goodman et al. | Jan 2009 | A1 |
| 20090028336 | Goodman et al. | Jan 2009 | A1 |
| 20090028339 | Goodman et al. | Jan 2009 | A1 |
| 20090062942 | Smaragdis et al. | Mar 2009 | A1 |
| 20090074006 | Qi et al. | Mar 2009 | A1 |
| 20090077444 | Qi et al. | Mar 2009 | A1 |
| 20090083279 | Hasek | Mar 2009 | A1 |
| 20090083546 | Staddon et al. | Mar 2009 | A1 |
| 20090089789 | Faltings et al. | Apr 2009 | A1 |
| 20090094464 | Futa et al. | Apr 2009 | A1 |
| 20090097642 | Schnell et al. | Apr 2009 | A1 |
| 20090109916 | Berg et al. | Apr 2009 | A1 |
| 20090119518 | Staddon et al. | May 2009 | A1 |
| 20090136033 | Sy | May 2009 | A1 |
| 20090138486 | Hydrie et al. | May 2009 | A1 |
| 20090150982 | Kim | Jun 2009 | A1 |
| 20090158054 | Dijk et al. | Jun 2009 | A1 |
| 20090177591 | Thorpe et al. | Jul 2009 | A1 |
| 20090182667 | Parkes et al. | Jul 2009 | A1 |
| 20090182997 | Gillard et al. | Jul 2009 | A1 |
| 20090187757 | Kerschbaum | Jul 2009 | A1 |
| 20090196304 | Sayenko | Aug 2009 | A1 |
| 20090207819 | Kroselberg et al. | Aug 2009 | A1 |
| 20090216970 | Basler et al. | Aug 2009 | A1 |
| 20090221439 | Carlson | Sep 2009 | A1 |
| 20090238365 | Bardera Bosch et al. | Sep 2009 | A1 |
| 20090252327 | Ciet et al. | Oct 2009 | A1 |
| 20090259843 | Gentry et al. | Oct 2009 | A1 |
| 20090265547 | Gentry et al. | Oct 2009 | A1 |
| 20090265548 | Gentry et al. | Oct 2009 | A1 |
| 20090265737 | Issa et al. | Oct 2009 | A1 |
| 20090268908 | Bikel et al. | Oct 2009 | A1 |
| 20090276841 | Guo et al. | Nov 2009 | A1 |
| 20090279694 | Takahashi et al. | Nov 2009 | A1 |
| 20090282039 | Diamond | Nov 2009 | A1 |
| 20090287924 | Gentry et al. | Nov 2009 | A1 |
| 20090310582 | Beser | Dec 2009 | A1 |
| 20090319802 | Walmsley | Dec 2009 | A1 |
| 20090325575 | Rantanen et al. | Dec 2009 | A1 |
| 20090327141 | Rabin et al. | Dec 2009 | A1 |
| 20100005309 | Gentry et al. | Jan 2010 | A1 |
| 20100005310 | Gentry et al. | Jan 2010 | A1 |
| 20100027784 | Tuyls et al. | Feb 2010 | A1 |
| 20100042828 | Masui et al. | Feb 2010 | A1 |
| 20100067462 | Beser et al. | Mar 2010 | A1 |
| 20100080152 | Lindh et al. | Apr 2010 | A1 |
| 20100093364 | Ribeiro et al. | Apr 2010 | A1 |
| 20100111296 | Brown et al. | May 2010 | A1 |
| 20100119069 | Kamikura et al. | May 2010 | A1 |
| 20100138671 | Kim et al. | Jun 2010 | A1 |
| 20100138882 | Ellis et al. | Jun 2010 | A1 |
| 20100142704 | Camenisch et al. | Jun 2010 | A1 |
| 20100146299 | Swaminathan et al. | Jun 2010 | A1 |
| 20100153714 | Ramzan et al. | Jun 2010 | A1 |
| 20100161998 | Chen et al. | Jun 2010 | A1 |
| 20100174904 | Ramzan et al. | Jul 2010 | A1 |
| 20100185863 | Rabin et al. | Jul 2010 | A1 |
| 20100199090 | Berbain et al. | Aug 2010 | A1 |
| 20100205430 | Chiou et al. | Aug 2010 | A1 |
| 20100217613 | Kelly | Aug 2010 | A1 |
| 20100218037 | Swartz et al. | Aug 2010 | A1 |
| 20100220643 | Qi et al. | Sep 2010 | A1 |
| 20100223057 | Capman et al. | Sep 2010 | A1 |
| 20100234022 | Winterbottom | Sep 2010 | A1 |
| 20100235285 | Hoffberg | Sep 2010 | A1 |
| 20100246812 | Rane et al. | Sep 2010 | A1 |
| 20100267386 | Lim et al. | Oct 2010 | A1 |
| 20100278221 | Qi et al. | Nov 2010 | A1 |
| 20100281267 | Sakumoto | Nov 2010 | A1 |
| 20100281269 | Kindarji et al. | Nov 2010 | A1 |
| 20100287370 | Gentry et al. | Nov 2010 | A1 |
| 20100290617 | Nath | Nov 2010 | A1 |
| 20100293293 | Beser | Nov 2010 | A1 |
| 20100317420 | Hoffberg | Dec 2010 | A1 |
| 20100329448 | Rane et al. | Dec 2010 | A1 |
| 20100329454 | Takashima | Dec 2010 | A1 |
| 20110004513 | Hoffberg | Jan 2011 | A1 |
| 20110026781 | Osadchy et al. | Feb 2011 | A1 |
| 20110039589 | Skov | Feb 2011 | A1 |
| 20110040820 | Rane et al. | Feb 2011 | A1 |
| 20110041178 | Jakobsson et al. | Feb 2011 | A1 |
| 20110041180 | Jakobsson et al. | Feb 2011 | A1 |
| 20110051931 | Farrugia et al. | Mar 2011 | A1 |
| 20110055300 | Sun et al. | Mar 2011 | A1 |
| 20110060901 | Troncoso Pastoriza et al. | Mar 2011 | A1 |
| 20110060917 | Troncoso Pastoriza et al. | Mar 2011 | A1 |
| 20110060918 | Troncoso Pastoriza et al. | Mar 2011 | A1 |
| 20110067012 | Eisen et al. | Mar 2011 | A1 |
| 20110069630 | Doppler et al. | Mar 2011 | A1 |
| 20110074850 | Walmsley et al. | Mar 2011 | A1 |
| 20110085658 | Kerschbaum | Apr 2011 | A1 |
| 20110087885 | Lerner | Apr 2011 | A1 |
| 20110090879 | Hamiti et al. | Apr 2011 | A1 |
| 20110103253 | Qi et al. | May 2011 | A1 |
| 20110103374 | Lajoie et al. | May 2011 | A1 |
| 20110107105 | Hada | May 2011 | A1 |
| 20110107364 | Lajoie et al. | May 2011 | A1 |
| 20110107379 | Lajoie et al. | May 2011 | A1 |
| 20110110525 | Gentry | May 2011 | A1 |
| 20110135096 | Rane et al. | Jun 2011 | A1 |
| 20110154016 | Niccolini et al. | Jun 2011 | A1 |
| 20110202766 | Lerner | Aug 2011 | A1 |
| 20110211692 | Raykova et al. | Sep 2011 | A1 |
| 20110213962 | Pestoni | Sep 2011 | A1 |
| 20110219067 | Bernosky et al. | Sep 2011 | A1 |
| 20110231555 | Ebrahimi et al. | Sep 2011 | A1 |
| 20110243320 | Halevi et al. | Oct 2011 | A1 |
| 20110243324 | Lima et al. | Oct 2011 | A1 |
| 20110255687 | Farrugia et al. | Oct 2011 | A1 |
| 20110264920 | Rieffel et al. | Oct 2011 | A1 |
| 20110283099 | Nath et al. | Nov 2011 | A1 |
| 20110289311 | Roy-Chowdhury et al. | Nov 2011 | A1 |
| 20110295752 | Parkes et al. | Dec 2011 | A1 |
| 20110296438 | Lue-Sang et al. | Dec 2011 | A1 |
| 20110296481 | Cholas et al. | Dec 2011 | A1 |
| 20120002811 | Smart | Jan 2012 | A1 |
| 20120005719 | McDougal | Jan 2012 | A1 |
| 20120009939 | Islam et al. | Jan 2012 | A1 |
| 20120009949 | Islam et al. | Jan 2012 | A1 |
| 20120009950 | Islam et al. | Jan 2012 | A1 |
| 20120030468 | Papamanthou et al. | Feb 2012 | A1 |
| 20120039463 | Gentry et al. | Feb 2012 | A1 |
| 20120039465 | Gentry et al. | Feb 2012 | A1 |
| 20120039473 | Gentry et al. | Feb 2012 | A1 |
| 20120045056 | Takashima et al. | Feb 2012 | A1 |
| 20120063593 | Camenisch et al. | Mar 2012 | A1 |
| 20120072737 | Schrijen et al. | Mar 2012 | A1 |
| 20120089494 | Danezis et al. | Apr 2012 | A1 |
| 20120102335 | Goodman et al. | Apr 2012 | A1 |
| 20120114123 | Garcia Morchon et al. | May 2012 | A1 |
| 20120121080 | Kerschbaum | May 2012 | A1 |
| 20120124393 | Sethumadhavan et al. | May 2012 | A1 |
| 20120127890 | Islam | May 2012 | A1 |
| 20120129550 | Hannan et al. | May 2012 | A1 |
| 20120129551 | Islam | May 2012 | A1 |
| 20120143922 | Rane et al. | Jun 2012 | A1 |
| 20120144186 | Puiggali Allepuz et al. | Jun 2012 | A1 |
| 20120144459 | Nguyen et al. | Jun 2012 | A1 |
| 20120163222 | Islam et al. | Jun 2012 | A1 |
| 20120163584 | Adjedj | Jun 2012 | A1 |
| 20120172050 | Ledlie et al. | Jul 2012 | A1 |
| 20120185437 | Pavlov et al. | Jul 2012 | A1 |
| 20120198560 | Fiske | Aug 2012 | A1 |
| 20120201378 | Nabeel et al. | Aug 2012 | A1 |
| 20120204026 | Shi et al. | Aug 2012 | A1 |
| 20120207299 | Hattori et al. | Aug 2012 | A1 |
| 20120209790 | Szydlo | Aug 2012 | A1 |
| 20120213359 | Troncoso Pastoriza et al. | Aug 2012 | A1 |
| 20120215845 | Aad et al. | Aug 2012 | A1 |
| 20120224474 | Beser | Sep 2012 | A1 |
| 20120224688 | Rodgers et al. | Sep 2012 | A1 |
| 20120226900 | Rodgers et al. | Sep 2012 | A1 |
| 20120233460 | Kamara et al. | Sep 2012 | A1 |
| 20120239932 | Allepuz et al. | Sep 2012 | A1 |
| 20120239944 | Goodman et al. | Sep 2012 | A1 |
| 20120240062 | Passmore et al. | Sep 2012 | A1 |
| 20120260092 | Girao et al. | Oct 2012 | A1 |
| 20120260348 | Woodruff | Oct 2012 | A1 |
| 20120269348 | Rong et al. | Oct 2012 | A1 |
| 20120275592 | Zweig et al. | Nov 2012 | A1 |
| 20120278622 | Lesavich et al. | Nov 2012 | A1 |
| 20120284530 | Takashima et al. | Nov 2012 | A1 |
| 20120297198 | Danezis et al. | Nov 2012 | A1 |
| 20120297201 | Matsuda et al. | Nov 2012 | A1 |
| 20120317034 | Guha et al. | Dec 2012 | A1 |
| 20120317656 | Woodruff | Dec 2012 | A1 |
| 20120323981 | Yamamoto et al. | Dec 2012 | A1 |
| 20130010686 | Shatzkamer et al. | Jan 2013 | A1 |
| 20130010950 | Kerschbaum | Jan 2013 | A1 |
| 20130011215 | Wells et al. | Jan 2013 | A1 |
| 20130014270 | Sy et al. | Jan 2013 | A1 |
| 20130024689 | Liu et al. | Jan 2013 | A1 |
| 20130024693 | Chiou et al. | Jan 2013 | A1 |
| 20130024933 | Jakobsson et al. | Jan 2013 | A1 |
| 20130024936 | Jakobsson et al. | Jan 2013 | A1 |
| 20130028415 | Takashima et al. | Jan 2013 | A1 |
| 20130035979 | Tenbrock | Feb 2013 | A1 |
| 20130039489 | Takashima et al. | Feb 2013 | A1 |
| 20130051551 | El Aimani | Feb 2013 | A1 |
| 20130061263 | Issa et al. | Mar 2013 | A1 |
| 20130080307 | Hoffberg | Mar 2013 | A1 |
| 20130085916 | Abbe et al. | Apr 2013 | A1 |
| 20130086378 | Yao et al. | Apr 2013 | A1 |
| 20130096943 | Carey et al. | Apr 2013 | A1 |
| 20130097431 | Hriljac | Apr 2013 | A1 |
| 20130111205 | Biswas | May 2013 | A1 |
| 20130114811 | Boufounos et al. | May 2013 | A1 |
| 20130148551 | Lindh et al. | Jun 2013 | A1 |
| 20130148868 | Troncoso Pastoriza et al. | Jun 2013 | A1 |
| 20130152160 | Smith et al. | Jun 2013 | A1 |
| 20130156188 | Xu et al. | Jun 2013 | A1 |
| 20130170640 | Gentry | Jul 2013 | A1 |
| 20130173917 | Clifton et al. | Jul 2013 | A1 |
| 20130173929 | Takashima et al. | Jul 2013 | A1 |
| 20130182848 | Sundaram et al. | Jul 2013 | A1 |
| 20130191650 | Balakrishnan et al. | Jul 2013 | A1 |
| 20130195267 | Alessio et al. | Aug 2013 | A1 |
| 20130198522 | Kohno et al. | Aug 2013 | A1 |
| 20130198854 | Erway et al. | Aug 2013 | A1 |
| 20130202109 | Ducharme | Aug 2013 | A1 |
| 20130205331 | Ducharme | Aug 2013 | A1 |
| 20130216044 | Gentry et al. | Aug 2013 | A1 |
| 20130227283 | Williamson et al. | Aug 2013 | A1 |
| 20130232567 | Kaid et al. | Sep 2013 | A1 |
| 20130238897 | Mashatan et al. | Sep 2013 | A1 |
| 20130246813 | Mori et al. | Sep 2013 | A1 |
| 20130247230 | Parann-Nissany et al. | Sep 2013 | A1 |
| 20130254532 | Raykova et al. | Sep 2013 | A1 |
| 20130268772 | Golle | Oct 2013 | A1 |
| 20130275743 | Jawurek et al. | Oct 2013 | A1 |
| 20130275752 | Zhang et al. | Oct 2013 | A1 |
| 20130279690 | Durham et al. | Oct 2013 | A1 |
| 20130283393 | Hierro et al. | Oct 2013 | A1 |
| 20130315390 | Gentry et al. | Nov 2013 | A1 |
| 20130318351 | Hirano et al. | Nov 2013 | A1 |
| 20130318360 | Yamamoto et al. | Nov 2013 | A1 |
| 20130318560 | Cholas et al. | Nov 2013 | A1 |
| 20130322627 | Takashima et al. | Dec 2013 | A1 |
| 20130324155 | Islam et al. | Dec 2013 | A1 |
| 20130326224 | Yavuz | Dec 2013 | A1 |
| 20130329883 | Tamayo-Rios | Dec 2013 | A1 |
| 20130336474 | Takashima et al. | Dec 2013 | A1 |
| 20130339743 | Hada | Dec 2013 | A1 |
| 20130339754 | Takashima et al. | Dec 2013 | A1 |
| 20130339814 | Rane et al. | Dec 2013 | A1 |
| 20140007087 | Scott-Nash et al. | Jan 2014 | A1 |
| 20140041039 | Saldamli et al. | Feb 2014 | A1 |
| 20140047544 | Jakobsson | Feb 2014 | A1 |
| 20140056426 | Ducharme | Feb 2014 | A1 |
| 20140059345 | Camenisch et al. | Feb 2014 | A1 |
| 20140059347 | Dougherty et al. | Feb 2014 | A1 |
| 20140075183 | Wang et al. | Mar 2014 | A1 |
| 20140081793 | Hoffberg | Mar 2014 | A1 |
| 20140090023 | Hu et al. | Mar 2014 | A1 |
| 20140090036 | Roberts | Mar 2014 | A1 |
| 20140093077 | Jawurek et al. | Apr 2014 | A1 |
| 20140095860 | Shikfa et al. | Apr 2014 | A1 |
| 20140095865 | Yerra et al. | Apr 2014 | A1 |
| 20140098960 | Xu et al. | Apr 2014 | A1 |
| 20140101765 | Jakobsson et al. | Apr 2014 | A1 |
| 20140108020 | Sharma et al. | Apr 2014 | A1 |
| 20140115090 | Hasek | Apr 2014 | A1 |
| 20140115321 | Isshiki | Apr 2014 | A1 |
| 20140115322 | Xu et al. | Apr 2014 | A1 |
| 20140121990 | Baldi et al. | May 2014 | A1 |
| 20140123301 | Kaliski, Jr. | May 2014 | A1 |
| 20140139608 | Rosario et al. | May 2014 | A1 |
| 20140140514 | Gentry | May 2014 | A1 |
| 20140142958 | Sharma et al. | May 2014 | A1 |
| 20140143369 | Dobre | May 2014 | A1 |
| 20140143764 | Kerschbaum | May 2014 | A1 |
| 20140143878 | Milman et al. | May 2014 | A1 |
| 20140143879 | Milman et al. | May 2014 | A1 |
| 20140153717 | Sakumoto | Jun 2014 | A1 |
| 20140164760 | Hybertson | Jun 2014 | A1 |
| 20140177828 | Loftus et al. | Jun 2014 | A1 |
| 20140185797 | Yasuda et al. | Jul 2014 | A1 |
| 20140185803 | Lima et al. | Jul 2014 | A1 |
| 20140189361 | Sakumoto | Jul 2014 | A1 |
| 20140189792 | Lesavich et al. | Jul 2014 | A1 |
| 20140195818 | Neumann et al. | Jul 2014 | A1 |
| 20140211943 | Nyang | Jul 2014 | A1 |
| 20140215217 | Gronowski et al. | Jul 2014 | A1 |
| 20140215222 | Sakumoto et al. | Jul 2014 | A1 |
| 20140228049 | Hannan et al. | Aug 2014 | A1 |
| 20140233726 | Yajima et al. | Aug 2014 | A1 |
| 20140233731 | Naccache et al. | Aug 2014 | A1 |
| 20140233740 | Niamut et al. | Aug 2014 | A1 |
| 20140237253 | Joye et al. | Aug 2014 | A1 |
| 20140237254 | Joye et al. | Aug 2014 | A1 |
| 20140247939 | Hattori et al. | Sep 2014 | A1 |
| 20140250301 | Chang et al. | Sep 2014 | A1 |
| 20140258396 | Miller | Sep 2014 | A1 |
| 20140270159 | Youn et al. | Sep 2014 | A1 |
| 20140273958 | Messana et al. | Sep 2014 | A1 |
| 20140281511 | Kaushik et al. | Sep 2014 | A1 |
| 20140281567 | Rane et al. | Sep 2014 | A1 |
| 20140289536 | MacCarthy et al. | Sep 2014 | A1 |
| 20140298028 | Takashima et al. | Oct 2014 | A1 |
| 20140310243 | McGee et al. | Oct 2014 | A1 |
| 20140310527 | Veugen et al. | Oct 2014 | A1 |
| 20140314232 | Fahrny | Oct 2014 | A1 |
| 20140321642 | El Aimani et al. | Oct 2014 | A1 |
| 20140321644 | Lemieux | Oct 2014 | A1 |
| 20140324447 | Dittus | Oct 2014 | A1 |
| 20140325217 | Mori et al. | Oct 2014 | A1 |
| 20140325230 | Sy et al. | Oct 2014 | A1 |
| 20140328279 | Beser | Nov 2014 | A1 |
| 20140331059 | Rane et al. | Nov 2014 | A1 |
| 20140334622 | Smyth et al. | Nov 2014 | A1 |
| 20140344575 | Saremi | Nov 2014 | A1 |
| 20140348326 | Meyer et al. | Nov 2014 | A1 |
| 20140351104 | Abbe et al. | Nov 2014 | A1 |
| 20140372769 | Kerschbaum et al. | Dec 2014 | A1 |
| 20140379991 | Lomet et al. | Dec 2014 | A1 |
| 20150006908 | Mori et al. | Jan 2015 | A1 |
| 20150010147 | Takashima et al. | Jan 2015 | A1 |
| 20150033033 | Halevi et al. | Jan 2015 | A1 |
| 20150033120 | Cooke et al. | Jan 2015 | A1 |
| 20150039586 | Kerschbaum et al. | Feb 2015 | A1 |
| 20150039912 | Payton et al. | Feb 2015 | A1 |
| 20150046450 | Yoshino et al. | Feb 2015 | A1 |
| 20150046708 | Yasuda et al. | Feb 2015 | A1 |
| 20150063563 | Vaya | Mar 2015 | A1 |
| 20150067336 | Ding | Mar 2015 | A1 |
| 20150067874 | Johnson et al. | Mar 2015 | A1 |
| 20150067875 | Johnson et al. | Mar 2015 | A1 |
| 20150074803 | Johnson et al. | Mar 2015 | A1 |
| 20150082425 | Johnson et al. | Mar 2015 | A1 |
| 20150089243 | Veugen | Mar 2015 | A1 |
| 20150089589 | Cucinotta et al. | Mar 2015 | A1 |
| 20150092667 | Beser et al. | Apr 2015 | A1 |
| 20150098566 | Takashima et al. | Apr 2015 | A1 |
| 20150100785 | Joye et al. | Apr 2015 | A1 |
| 20150100794 | Joye et al. | Apr 2015 | A1 |
| 20150111591 | Hoffberg | Apr 2015 | A1 |
| 20150121062 | Gajek et al. | Apr 2015 | A1 |
| 20150124962 | Gentry et al. | May 2015 | A1 |
| 20150135329 | Aghasaryan et al. | May 2015 | A1 |
| 20150143111 | Parann-Nissany et al. | May 2015 | A1 |
| 20150149767 | Oualha et al. | May 2015 | A1 |
| 20150149773 | Kerschbaum et al. | May 2015 | A1 |
| 20150154357 | Biswas et al. | Jun 2015 | A1 |
| 20150161398 | De Cristofaro et al. | Jun 2015 | A1 |
| 20150169889 | Swaminathan et al. | Jun 2015 | A1 |
| 20150170197 | Smith et al. | Jun 2015 | A1 |
| 20150172049 | Chida et al. | Jun 2015 | A1 |
| 20150172258 | Komano et al. | Jun 2015 | A1 |
| 20150172260 | Brenner | Jun 2015 | A1 |
| 20150181308 | Ducharme | Jun 2015 | A1 |
| 20150186683 | Fiske | Jul 2015 | A1 |
| 20150188949 | Mahaffey et al. | Jul 2015 | A1 |
| 20150193628 | Maniatakos et al. | Jul 2015 | A1 |
| 20150193633 | Chida et al. | Jul 2015 | A1 |
| 20150195083 | Jacquin et al. | Jul 2015 | A1 |
| 20150200840 | Beser | Jul 2015 | A1 |
| 20150205967 | Naedele et al. | Jul 2015 | A1 |
| 20150207630 | Shimoyama et al. | Jul 2015 | A1 |
| 20150207846 | Famaey et al. | Jul 2015 | A1 |
| 20150213239 | Johnson et al. | Jul 2015 | A1 |
| 20150215123 | Kipnis et al. | Jul 2015 | A1 |
| 20150215669 | Cholas et al. | Jul 2015 | A1 |
| 20150222422 | Yung et al. | Aug 2015 | A1 |
| 20150222648 | Kim et al. | Aug 2015 | A1 |
| 20150222938 | Hasek | Aug 2015 | A1 |
| 20150227930 | Quigley et al. | Aug 2015 | A1 |
| 20150229472 | Takashima et al. | Aug 2015 | A1 |
| 20150229480 | Joye et al. | Aug 2015 | A1 |
| 20150229619 | Costa et al. | Aug 2015 | A1 |
| 20150236849 | Ayday et al. | Aug 2015 | A1 |
| 20150237519 | Ghai | Aug 2015 | A1 |
| 20150244517 | Nita | Aug 2015 | A1 |
| 20150244710 | Koster et al. | Aug 2015 | A1 |
| 20150264626 | Perdomo | Sep 2015 | A1 |
| 20150264627 | Perdomo | Sep 2015 | A1 |
| 20150270952 | Sethumadhavan et al. | Sep 2015 | A1 |
| 20150270967 | Susella et al. | Sep 2015 | A1 |
| 20150271541 | Gonder et al. | Sep 2015 | A1 |
| 20150288519 | Tuyls et al. | Oct 2015 | A1 |
| 20150288662 | Bilogrevic et al. | Oct 2015 | A1 |
| 20150288665 | El Emam et al. | Oct 2015 | A1 |
| 20150294117 | Cucinotta et al. | Oct 2015 | A1 |
| 20150295712 | Veugen | Oct 2015 | A1 |
| 20150304329 | Yan et al. | Oct 2015 | A1 |
| 20150304851 | Chen et al. | Oct 2015 | A1 |
| 20150309863 | Shi et al. | Oct 2015 | A1 |
| 20150310228 | Benz et al. | Oct 2015 | A1 |
| 20150312031 | Seo et al. | Oct 2015 | A1 |
| 20150317362 | Teranishi | Nov 2015 | A1 |
| 20150326389 | Johnson et al. | Nov 2015 | A1 |
| 20150326392 | Cheng et al. | Nov 2015 | A1 |
| 20150333905 | Parann-Nissany et al. | Nov 2015 | A1 |
| 20150341173 | Camenisch et al. | Nov 2015 | A1 |
| 20150341174 | Mandal et al. | Nov 2015 | A1 |
| 20150341326 | Premnath et al. | Nov 2015 | A1 |
| 20150341335 | Camenisch et al. | Nov 2015 | A1 |
| 20150347435 | Pavlov et al. | Dec 2015 | A1 |
| 20150348087 | Cordery et al. | Dec 2015 | A1 |
| 20150356281 | Van Deventer et al. | Dec 2015 | A1 |
| 20150358153 | Gentry | Dec 2015 | A1 |
| 20150358167 | Wang et al. | Dec 2015 | A1 |
| 20150365227 | Billau et al. | Dec 2015 | A1 |
| 20150365435 | Billau et al. | Dec 2015 | A1 |
| 20150365440 | Billau et al. | Dec 2015 | A1 |
| 20150372809 | Lima et al. | Dec 2015 | A1 |
| 20150379301 | Lesavich et al. | Dec 2015 | A1 |
| 20150381348 | Takenaka et al. | Dec 2015 | A1 |
| 20150381349 | Nikolaenko et al. | Dec 2015 | A1 |
| 20150381350 | Joye et al. | Dec 2015 | A1 |
| 20150381588 | Huang et al. | Dec 2015 | A1 |
| 20160004874 | Ioannidis et al. | Jan 2016 | A1 |
| 20160004879 | Fisher et al. | Jan 2016 | A1 |
| 20160012238 | Ioannidis et al. | Jan 2016 | A1 |
| 20160012240 | Smith et al. | Jan 2016 | A1 |
| 20160013930 | Ducharme | Jan 2016 | A1 |
| 20160014456 | Ducharme | Jan 2016 | A1 |
| 20160019279 | Sengupta et al. | Jan 2016 | A1 |
| 20160020898 | Nikolaenko et al. | Jan 2016 | A1 |
| 20160020904 | Ioannidis et al. | Jan 2016 | A1 |
| 20160026807 | Antipa et al. | Jan 2016 | A1 |
| 20160028698 | Antipa et al. | Jan 2016 | A1 |
| 20160029076 | Huber et al. | Jan 2016 | A1 |
| 20160036584 | Nikolaenko et al. | Feb 2016 | A1 |
| 20160044003 | Raykova et al. | Feb 2016 | A1 |
| 20160063189 | Soon-Shiong et al. | Mar 2016 | A1 |
| 20160066027 | Ellis et al. | Mar 2016 | A1 |
| 20160072623 | Joye et al. | Mar 2016 | A1 |
| 20160072800 | Soon-Shiong et al. | Mar 2016 | A1 |
| 20160088012 | Casey et al. | Mar 2016 | A1 |
| 20160098198 | Bosshart et al. | Apr 2016 | A1 |
| 20160099872 | Kim et al. | Apr 2016 | A1 |
| 20160105400 | Straub | Apr 2016 | A1 |
| 20160105402 | Soon-Shiong et al. | Apr 2016 | A1 |
| 20160105414 | Bringer et al. | Apr 2016 | A1 |
| 20160110403 | Lomet et al. | Apr 2016 | A1 |
| 20160110500 | Wang et al. | Apr 2016 | A1 |
| 20160112197 | Johnston | Apr 2016 | A1 |
| 20160112396 | Paya et al. | Apr 2016 | A1 |
| 20160119119 | Calapodescu et al. | Apr 2016 | A1 |
| 20160125141 | Raisaro et al. | May 2016 | A1 |
| 20160127125 | Yagisawa | May 2016 | A1 |
| 20160127128 | Chen et al. | May 2016 | A1 |
| 20160127335 | Yamamoto et al. | May 2016 | A1 |
| 20160132317 | Mitchell et al. | May 2016 | A1 |
| 20160132692 | Kerschbaum et al. | May 2016 | A1 |
| 20160133164 | Yoshida et al. | May 2016 | A1 |
| 20160140348 | Nawaz et al. | May 2016 | A1 |
| 20160142750 | Huber et al. | May 2016 | A1 |
| 20160149866 | Dolev et al. | May 2016 | A1 |
| 20160154971 | Swaminathan et al. | Jun 2016 | A9 |
| 20160156595 | Wu et al. | Jun 2016 | A1 |
| 20160164670 | Gentry et al. | Jun 2016 | A1 |
| 20160164671 | Gentry et al. | Jun 2016 | A1 |
| 20160164676 | Gentry et al. | Jun 2016 | A1 |
| 20160165268 | Williamson et al. | Jun 2016 | A1 |
| 20160167164 | Rosario et al. | Jun 2016 | A9 |
| 20160170996 | Frank et al. | Jun 2016 | A1 |
| 20160171212 | Majumdar et al. | Jun 2016 | A1 |
| 20160173275 | Yasuda et al. | Jun 2016 | A1 |
| 20160182222 | Rane et al. | Jun 2016 | A1 |
| 20160182226 | Yasuda et al. | Jun 2016 | A1 |
| 20160189461 | Kanon et al. | Jun 2016 | A1 |
| 20160191233 | Loftus et al. | Jun 2016 | A1 |
| 20160197726 | Yasuda | Jul 2016 | A1 |
| 20160204917 | Lindh et al. | Jul 2016 | A1 |
| 20160204936 | Sakemi et al. | Jul 2016 | A1 |
| 20160205074 | Mitchell | Jul 2016 | A1 |
| 20160210131 | Vangelov et al. | Jul 2016 | A1 |
| 20160212103 | Rhoads et al. | Jul 2016 | A1 |
| 20160224735 | Ayday et al. | Aug 2016 | A1 |
| 20160224803 | Frank et al. | Aug 2016 | A1 |
| 20160224951 | Hoffberg | Aug 2016 | A1 |
| 20160224964 | Vergari et al. | Aug 2016 | A1 |
| 20160232553 | Reddy K et al. | Aug 2016 | A1 |
| 20160234010 | Kipnis et al. | Aug 2016 | A1 |
| 20160234686 | Bone et al. | Aug 2016 | A1 |
| 20160239647 | Johnson et al. | Aug 2016 | A1 |
| 20160239653 | Loughlin-Mchugh et al. | Aug 2016 | A1 |
| 20160239657 | Loughlin-Mchugh et al. | Aug 2016 | A1 |
| 20160239658 | Loughlin-Mchugh et al. | Aug 2016 | A1 |
| 20160241531 | Loughlin-Mchugh et al. | Aug 2016 | A1 |
| 20160241532 | Loughlin-Mchugh et al. | Aug 2016 | A1 |
| 20160254911 | Manchepalli et al. | Sep 2016 | A1 |
| 20160254914 | Saito et al. | Sep 2016 | A1 |
| 20160255498 | Jager et al. | Sep 2016 | A1 |
| 20160261404 | Ford et al. | Sep 2016 | A1 |
| 20160261592 | Hubert et al. | Sep 2016 | A1 |
| 20160269174 | Yasuda | Sep 2016 | A1 |
| 20160269775 | Cholas et al. | Sep 2016 | A1 |
| 20160275308 | Hubaux et al. | Sep 2016 | A1 |
| 20160285836 | Kaliski, Jr. | Sep 2016 | A1 |
| 20160292430 | Antonopoulos et al. | Oct 2016 | A1 |
| 20160293172 | Sharma et al. | Oct 2016 | A1 |
| 20160300252 | Frank et al. | Oct 2016 | A1 |
| 20160315761 | Gorissen et al. | Oct 2016 | A1 |
| 20160321654 | Lesavich et al. | Nov 2016 | A1 |
| 20160323098 | Bathen | Nov 2016 | A1 |
| 20160330018 | Miyata et al. | Nov 2016 | A1 |
| 20160330026 | Joye et al. | Nov 2016 | A1 |
| 20160330034 | Back et al. | Nov 2016 | A1 |
| 20160330209 | Iacob et al. | Nov 2016 | A1 |
| 20160335440 | Clark et al. | Nov 2016 | A1 |
| 20160335450 | Yoshino et al. | Nov 2016 | A1 |
| 20160337319 | Vaya et al. | Nov 2016 | A1 |
| 20160337464 | Eriksson et al. | Nov 2016 | A1 |
| 20160344557 | Chabanne et al. | Nov 2016 | A1 |
| 20160350552 | Matsuzaki et al. | Dec 2016 | A1 |
| 20160350648 | Gilad-Bachrach et al. | Dec 2016 | A1 |
| 20160352510 | Morikawa et al. | Dec 2016 | A1 |
| 20160352710 | Hibshoosh et al. | Dec 2016 | A1 |
| 20160357791 | Levandoski et al. | Dec 2016 | A1 |
| 20160357869 | Hang et al. | Dec 2016 | A1 |
| 20160358165 | Maxwell | Dec 2016 | A1 |
| 20160359617 | Patel et al. | Dec 2016 | A1 |
| 20160365973 | van Deventer et al. | Dec 2016 | A1 |
| 20160371064 | Rougerie et al. | Dec 2016 | A1 |
| 20160371771 | Serrano | Dec 2016 | A1 |
| 20160373440 | Mather et al. | Dec 2016 | A1 |
| 20160381405 | Smith et al. | Dec 2016 | A1 |
| 20170005787 | Weaver et al. | Jan 2017 | A1 |
| 20170012970 | Mandal et al. | Jan 2017 | A1 |
| 20170012996 | Hu et al. | Jan 2017 | A1 |
| 20170019248 | Mustafa et al. | Jan 2017 | A1 |
| 20170024585 | Mooij et al. | Jan 2017 | A1 |
| 20170039377 | Nicholls | Feb 2017 | A1 |
| 20170039386 | Lehnhardt et al. | Feb 2017 | A1 |
| 20170041132 | Nicholls | Feb 2017 | A1 |
| 20170041298 | Lehnhardt et al. | Feb 2017 | A1 |
| 20170041300 | Kim et al. | Feb 2017 | A1 |
| 20170041395 | Kupcu et al. | Feb 2017 | A1 |
| 20170048208 | Raykova et al. | Feb 2017 | A1 |
| 20170053249 | Tunnell et al. | Feb 2017 | A1 |
| 20170053282 | Olumofin et al. | Feb 2017 | A1 |
| 20170061833 | Joye et al. | Mar 2017 | A1 |
| 20170063526 | Kahrobaei et al. | Mar 2017 | A1 |
| 20170070340 | Hibshoosh et al. | Mar 2017 | A1 |
| 20170070351 | Yan | Mar 2017 | A1 |
| 20170077950 | Pavlov et al. | Mar 2017 | A1 |
| 20170078438 | Yamaura et al. | Mar 2017 | A1 |
| 20170085382 | Kamakari et al. | Mar 2017 | A1 |
| 20170089291 | Suzuki | Mar 2017 | A1 |
| 20170099133 | Gu et al. | Apr 2017 | A1 |
| 20170099262 | Kerschbaum | Apr 2017 | A1 |
| 20170099263 | Matsuzaki et al. | Apr 2017 | A1 |
| 20170103217 | Arasu et al. | Apr 2017 | A1 |
| 20170103227 | Kerschbaum et al. | Apr 2017 | A1 |
| 20170103391 | Wilson, Jr. et al. | Apr 2017 | A1 |
| 20170103457 | Acuna-Rohter et al. | Apr 2017 | A1 |
| 20170104582 | Yamamoto et al. | Apr 2017 | A1 |
| 20170104583 | Yamamoto et al. | Apr 2017 | A1 |
| 20170104752 | Sakemi et al. | Apr 2017 | A1 |
| 20170111165 | Yamamoto et al. | Apr 2017 | A1 |
| 20170116396 | Gu et al. | Apr 2017 | A1 |
| 20170116410 | Wajs et al. | Apr 2017 | A1 |
| 20170124348 | Pourzandi et al. | May 2017 | A1 |
| 20170132279 | Teranishi | May 2017 | A1 |
| 20170132537 | Chavez | May 2017 | A1 |
| 20170133022 | Gurijala et al. | May 2017 | A1 |
| 20170134158 | Pasol et al. | May 2017 | A1 |
| 20170142109 | Mandal et al. | May 2017 | A1 |
| 20170147835 | Bacon et al. | May 2017 | A1 |
| 20170149558 | Patel et al. | May 2017 | A1 |
| 20170149796 | Gvili | May 2017 | A1 |
| 20170155515 | Androulaki et al. | Jun 2017 | A1 |
| 20170155628 | Rohloff et al. | Jun 2017 | A1 |
| 20170161314 | Joosten | Jun 2017 | A1 |
| 20170161829 | Mazier | Jun 2017 | A1 |
| 20170169241 | Unagami et al. | Jun 2017 | A1 |
| 20170169425 | Metral | Jun 2017 | A1 |
| 20170170960 | Shaked et al. | Jun 2017 | A1 |
| 20170173262 | Veltz | Jun 2017 | A1 |
| 20170177899 | Ng et al. | Jun 2017 | A1 |
| 20170186255 | Fuji et al. | Jun 2017 | A1 |
| 20170199818 | Lomet et al. | Jul 2017 | A1 |
| 20170206512 | Hoffberg | Jul 2017 | A1 |
| 20170207919 | Mandal et al. | Jul 2017 | A1 |
| 20170208043 | Bohli et al. | Jul 2017 | A1 |
| 20170213287 | Bruno | Jul 2017 | A1 |
| 20170214666 | Hybertson | Jul 2017 | A1 |
| 20170220617 | Bortnikov et al. | Aug 2017 | A1 |
| 20170222800 | Haber et al. | Aug 2017 | A1 |
| 20170223008 | Camenisch et al. | Aug 2017 | A1 |
| 20170228559 | Jackson | Aug 2017 | A1 |
| 20170230171 | Gadepally et al. | Aug 2017 | A1 |
| 20170230344 | Dhar et al. | Aug 2017 | A1 |
| 20170232300 | Tran et al. | Aug 2017 | A1 |
| 20170235736 | Swaminathan et al. | Aug 2017 | A1 |
| 20170235969 | Kamara et al. | Aug 2017 | A1 |
| 20170237551 | Van Foreest et al. | Aug 2017 | A1 |
| 20170237725 | Camenisch et al. | Aug 2017 | A1 |
| 20170242961 | Shukla et al. | Aug 2017 | A1 |
| 20170243028 | LaFever et al. | Aug 2017 | A1 |
| 20170243284 | Rubman et al. | Aug 2017 | A1 |
| 20170244553 | Savry et al. | Aug 2017 | A1 |
| 20170244988 | Hasek | Aug 2017 | A1 |
| 20170249460 | Lipton et al. | Aug 2017 | A1 |
| 20170250796 | Samid | Aug 2017 | A1 |
| 20170250799 | Stueve et al. | Aug 2017 | A1 |
| 20170250819 | Hoffstein et al. | Aug 2017 | A1 |
| 20170255769 | Loughlin-Mchugh et al. | Sep 2017 | A1 |
| 20170262651 | Kaliski, Jr. | Sep 2017 | A1 |
| 20170264426 | Joye et al. | Sep 2017 | A1 |
| 20170277773 | Iasi et al. | Sep 2017 | A1 |
| 20170277774 | Eigner et al. | Sep 2017 | A1 |
| 20170277775 | Eigner et al. | Sep 2017 | A1 |
| 20170277906 | Camenisch et al. | Sep 2017 | A1 |
| 20170287068 | Nugent | Oct 2017 | A1 |
| 20170288856 | Payton et al. | Oct 2017 | A1 |
| 20170289008 | Lau | Oct 2017 | A1 |
| 20170289111 | Voell et al. | Oct 2017 | A1 |
| 20170293913 | Gulak et al. | Oct 2017 | A1 |
| 20170295143 | Bone et al. | Oct 2017 | A1 |
| 20170295226 | Basta et al. | Oct 2017 | A1 |
| 20170301052 | Abt, Jr. et al. | Oct 2017 | A1 |
| 20170308580 | Naganuma et al. | Oct 2017 | A1 |
| 20170316391 | Peikert et al. | Nov 2017 | A1 |
| 20170322800 | Mitchell et al. | Nov 2017 | A1 |
| 20170322977 | Naganuma et al. | Nov 2017 | A1 |
| 20170323118 | Fink et al. | Nov 2017 | A1 |
| 20170329980 | Hu et al. | Nov 2017 | A1 |
| 20170346627 | Alleaume | Nov 2017 | A1 |
| 20170353296 | Yamamoto et al. | Dec 2017 | A1 |
| 20170353310 | Guasch Castello et al. | Dec 2017 | A1 |
| 20170357826 | Gouget et al. | Dec 2017 | A1 |
| 20170358161 | Hao et al. | Dec 2017 | A1 |
| 20170359321 | Rindal et al. | Dec 2017 | A1 |
| 20170359323 | Weis et al. | Dec 2017 | A1 |
| 20170366338 | Gajek | Dec 2017 | A1 |
| 20170372201 | Gupta et al. | Dec 2017 | A1 |
| 20170372226 | Costa et al. | Dec 2017 | A1 |
| 20180004743 | Shuman et al. | Jan 2018 | A1 |
| 20180011801 | Sengupta et al. | Jan 2018 | A1 |
| 20180011996 | Dolev et al. | Jan 2018 | A1 |
| 20180013748 | Paya et al. | Jan 2018 | A1 |
| 20180013828 | Kupcu et al. | Jan 2018 | A1 |
| 20180014241 | Perdomo | Jan 2018 | A1 |
| 20180019983 | Tissot et al. | Jan 2018 | A1 |
| 20180025435 | Karame et al. | Jan 2018 | A1 |
| 20180041345 | Maim | Feb 2018 | A1 |
| 20180041481 | Paz de Araujo | Feb 2018 | A1 |
| 20180046812 | Kaushik et al. | Feb 2018 | A1 |
| 20180048459 | Ding | Feb 2018 | A1 |
| 20180048467 | Yoshino et al. | Feb 2018 | A1 |
| 20180048628 | Soon-Shiong et al. | Feb 2018 | A1 |
| 20180049043 | Hoffberg | Feb 2018 | A1 |
| 20180060604 | Bent et al. | Mar 2018 | A1 |
| 20180068358 | Hoffberg | Mar 2018 | A1 |
| 20180068359 | Preston et al. | Mar 2018 | A1 |
| 20180071789 | Kingston et al. | Mar 2018 | A1 |
| 20180074481 | Kingston et al. | Mar 2018 | A1 |
| 20180075386 | Kingston et al. | Mar 2018 | A1 |
| 20180075406 | Kingston et al. | Mar 2018 | A1 |
| 20180075421 | Serrano | Mar 2018 | A1 |
| 20180076956 | Camenisch et al. | Mar 2018 | A1 |
| 20180078843 | Tran et al. | Mar 2018 | A1 |
| 20180082043 | Witchey et al. | Mar 2018 | A1 |
| 20180089419 | Loughlin-McHugh et al. | Mar 2018 | A1 |
| 20180089644 | Chen | Mar 2018 | A1 |
| 20180091306 | Antonopoulos et al. | Mar 2018 | A1 |
| 20180096166 | Rogers et al. | Apr 2018 | A1 |
| 20180101697 | Rane et al. | Apr 2018 | A1 |
| 20180109376 | Gentry et al. | Apr 2018 | A1 |
| 20180109541 | Gleichauf | Apr 2018 | A1 |
| 20180109831 | Smith et al. | Apr 2018 | A1 |
| 20180115412 | Smeets et al. | Apr 2018 | A1 |
| 20180117446 | Tran et al. | May 2018 | A1 |
| 20180117447 | Tran et al. | May 2018 | A1 |
| 20180123802 | Graul et al. | May 2018 | A1 |
| 20180131507 | Payton et al. | May 2018 | A1 |
| 20180131512 | Gajek | May 2018 | A1 |
| 20180137549 | Vadura et al. | May 2018 | A1 |
| 20180139190 | Chaum | May 2018 | A1 |
| 20180139481 | Cross | May 2018 | A1 |
| 20180145825 | Isshiki et al. | May 2018 | A1 |
| 20180150642 | Kiribuchi et al. | May 2018 | A1 |
| 20180152299 | Rossi | May 2018 | A1 |
| 20180152300 | Rossi | May 2018 | A1 |
| 20180152426 | Rossi | May 2018 | A1 |
| 20180157558 | Karame et al. | Jun 2018 | A1 |
| 20180157854 | Smith et al. | Jun 2018 | A1 |
| 20180159680 | Jost et al. | Jun 2018 | A1 |
| 20180165470 | Nachenberg | Jun 2018 | A1 |
| 20180165781 | Rodriguez et al. | Jun 2018 | A1 |
| 20180167197 | Anderson | Jun 2018 | A1 |
| 20180173890 | Lehnhardt et al. | Jun 2018 | A1 |
| 20180173906 | Rodriguez et al. | Jun 2018 | A1 |
| 20180176017 | Rodriguez et al. | Jun 2018 | A1 |
| 20180176216 | Mather et al. | Jun 2018 | A1 |
| 20180181964 | Zagarese et al. | Jun 2018 | A1 |
| 20180182036 | Thorpe et al. | Jun 2018 | A1 |
| 20180183570 | Zheng | Jun 2018 | A1 |
| 20180183571 | Gajek | Jun 2018 | A1 |
| 20180183572 | Kahrobaei et al. | Jun 2018 | A1 |
| 20180183768 | Lobban et al. | Jun 2018 | A1 |
| 20180189753 | Konda et al. | Jul 2018 | A1 |
| 20180191692 | Frank | Jul 2018 | A1 |
| 20180198601 | Laine et al. | Jul 2018 | A1 |
| 20180198613 | Anderson et al. | Jul 2018 | A1 |
| 20180198630 | Androulaki et al. | Jul 2018 | A1 |
| 20180198632 | Gajek et al. | Jul 2018 | A1 |
| 20180203808 | Unagami et al. | Jul 2018 | A1 |
| 20180204111 | Zadeh et al. | Jul 2018 | A1 |
| 20180204284 | Cerezo Sanchez | Jul 2018 | A1 |
| 20180211673 | Sharma et al. | Jul 2018 | A1 |
| 20180212750 | Hoffstein et al. | Jul 2018 | A1 |
| 20180212751 | Williams et al. | Jul 2018 | A1 |
| 20180212752 | Williams et al. | Jul 2018 | A1 |
| 20180212753 | Williams | Jul 2018 | A1 |
| 20180212755 | Williams et al. | Jul 2018 | A1 |
| 20180212764 | Shi et al. | Jul 2018 | A1 |
| 20180212775 | Williams | Jul 2018 | A1 |
| 20180212933 | Williams | Jul 2018 | A1 |
| 20180219913 | Manasse et al. | Aug 2018 | A1 |
| 20180227121 | Schneider et al. | Aug 2018 | A1 |
| 20180227278 | Camenisch et al. | Aug 2018 | A1 |
| 20180232381 | Tormasov et al. | Aug 2018 | A1 |
| 20180234253 | Camenisch et al. | Aug 2018 | A1 |
| 20180234254 | Camenisch et al. | Aug 2018 | A1 |
| 20180240191 | Aronson | Aug 2018 | A1 |
| 20180248684 | Oliver et al. | Aug 2018 | A1 |
| 20180254893 | Saxena et al. | Sep 2018 | A1 |
| 20180260576 | Miguel | Sep 2018 | A1 |
| 20180262485 | Roth et al. | Sep 2018 | A1 |
| 20180264347 | Tran et al. | Sep 2018 | A1 |
| 20180267981 | Sirdey et al. | Sep 2018 | A1 |
| 20180268062 | Gilula | Sep 2018 | A1 |
| 20180276400 | Lehnhardt et al. | Sep 2018 | A1 |
| 20180276409 | Hubaux et al. | Sep 2018 | A1 |
| 20180276417 | Cerezo Sanchez | Sep 2018 | A1 |
| 20180276626 | Laiben | Sep 2018 | A1 |
| 20180278410 | Hirano et al. | Sep 2018 | A1 |
| 20180278421 | Karabina et al. | Sep 2018 | A1 |
| 20180285576 | Cannings et al. | Oct 2018 | A1 |
| 20180285840 | Hasan | Oct 2018 | A1 |
| 20180285970 | Snow et al. | Oct 2018 | A1 |
| 20180285996 | Ma | Oct 2018 | A1 |
| 20180288023 | Hibshoosh et al. | Oct 2018 | A1 |
| 20180288039 | Haase et al. | Oct 2018 | A1 |
| 20180294951 | Paz de Araujo et al. | Oct 2018 | A1 |
| 20180294952 | Yuan et al. | Oct 2018 | A1 |
| 20180300497 | Carpov et al. | Oct 2018 | A1 |
| 20180302380 | Lehmann et al. | Oct 2018 | A1 |
| 20180302382 | Lehmann et al. | Oct 2018 | A1 |
| 20180303420 | Mauro et al. | Oct 2018 | A1 |
| 20180303421 | Mauro et al. | Oct 2018 | A1 |
| 20180303422 | Mauro et al. | Oct 2018 | A1 |
| 20180303423 | Mauro et al. | Oct 2018 | A1 |
| 20180303424 | Mauro et al. | Oct 2018 | A1 |
| 20180307859 | LaFever et al. | Oct 2018 | A1 |
| 20180316495 | Wall et al. | Nov 2018 | A1 |
| 20180316676 | Gilpin et al. | Nov 2018 | A1 |
| 20180326291 | Tran et al. | Nov 2018 | A1 |
| 20180329783 | Karame et al. | Nov 2018 | A1 |
| 20180330077 | Gray | Nov 2018 | A1 |
| 20180330078 | Gray | Nov 2018 | A1 |
| 20180330079 | Gray | Nov 2018 | A1 |
| 20180330125 | Gray | Nov 2018 | A1 |
| 20180330179 | Streit | Nov 2018 | A1 |
| 20180330343 | Gray | Nov 2018 | A1 |
| 20180331821 | Gray | Nov 2018 | A1 |
| 20180331835 | Jackson | Nov 2018 | A1 |
| 20180332011 | Gray | Nov 2018 | A1 |
| 20180337775 | Camenisch et al. | Nov 2018 | A1 |
| 20180337860 | Kim et al. | Nov 2018 | A1 |
| 20180337899 | Becker et al. | Nov 2018 | A1 |
| 20180343109 | Koseki et al. | Nov 2018 | A1 |
| 20180349577 | Goldwasser et al. | Dec 2018 | A1 |
| 20180349632 | Bent et al. | Dec 2018 | A1 |
| 20180349636 | Bhowmick et al. | Dec 2018 | A1 |
| 20180349637 | Decker et al. | Dec 2018 | A1 |
| 20180349638 | Barraclough et al. | Dec 2018 | A1 |
| 20180349740 | Schneider et al. | Dec 2018 | A1 |
| 20180351745 | Hamada et al. | Dec 2018 | A1 |
| 20180351922 | Hybertson | Dec 2018 | A1 |
| 20180357434 | Roy | Dec 2018 | A1 |
| 20180359078 | Jain et al. | Dec 2018 | A1 |
| 20180359079 | Hu et al. | Dec 2018 | A1 |
| 20180359084 | Jain et al. | Dec 2018 | A1 |
| 20180359097 | Lindell | Dec 2018 | A1 |
| 20180365201 | Hunn et al. | Dec 2018 | A1 |
| 20180365764 | Nelson | Dec 2018 | A1 |
| 20180366036 | Furukawa | Dec 2018 | A1 |
| 20180367294 | Hu et al. | Dec 2018 | A1 |
| 20180373834 | Cho et al. | Dec 2018 | A1 |
| 20180373849 | Gidley et al. | Dec 2018 | A1 |
| 20180373882 | Veugen | Dec 2018 | A1 |
| 20180375639 | Lauter et al. | Dec 2018 | A1 |
| 20180375640 | Laine et al. | Dec 2018 | A1 |
| 20190004999 | Kawamoto | Jan 2019 | A1 |
| 20190005254 | Arasu et al. | Jan 2019 | A1 |
| 20190005471 | Chandaria | Jan 2019 | A1 |
| 20190007059 | Lagunas | Jan 2019 | A1 |
| 20190007197 | Laine et al. | Jan 2019 | A1 |
| 20190007212 | Neve de Mevergnies et al. | Jan 2019 | A1 |
| 20190012660 | Masters | Jan 2019 | A1 |
| 20190012663 | Masters | Jan 2019 | A1 |
| 20190013943 | Maim | Jan 2019 | A1 |
| 20190013950 | Becker et al. | Jan 2019 | A1 |
| 20190014176 | Tormasov et al. | Jan 2019 | A1 |
| 20190019183 | Karame et al. | Jan 2019 | A1 |
| 20190020470 | Shamee et al. | Jan 2019 | A1 |
| 20190020651 | Soon-Shiong et al. | Jan 2019 | A1 |
| 20190020712 | Basta et al. | Jan 2019 | A1 |
| 20190026146 | Peffers et al. | Jan 2019 | A1 |
| 20190026730 | Moy et al. | Jan 2019 | A1 |
| 20190036678 | Ahmed | Jan 2019 | A1 |
| 20190044697 | Paz de Araujo et al. | Feb 2019 | A1 |
| 20190044703 | Smith | Feb 2019 | A1 |
| 20190050589 | Rane et al. | Feb 2019 | A1 |
| 20190050591 | Rane et al. | Feb 2019 | A1 |
| 20190052458 | Wright et al. | Feb 2019 | A1 |
| 20190058580 | Tormasov et al. | Feb 2019 | A1 |
| 20190068374 | Veeningen et al. | Feb 2019 | A1 |
| 20190080392 | Youb et al. | Mar 2019 | A1 |
| 20190081783 | Bohli et al. | Mar 2019 | A1 |
| 20190087600 | Sion et al. | Mar 2019 | A1 |
| 20190089372 | Roth et al. | Mar 2019 | A1 |
| 20190089526 | Locher et al. | Mar 2019 | A1 |
| 20190089537 | Gray | Mar 2019 | A1 |
| 20190089547 | Simplicio, Jr. et al. | Mar 2019 | A1 |
| 20190095880 | Glover et al. | Mar 2019 | A1 |
| 20190095995 | Rohlfs | Mar 2019 | A1 |
| 20190097787 | Schneider et al. | Mar 2019 | A1 |
| 20190097985 | Torres et al. | Mar 2019 | A1 |
| 20190102163 | Witherspoon | Apr 2019 | A1 |
| 20190108350 | Bohli et al. | Apr 2019 | A1 |
| 20190109701 | Paz de Araujo et al. | Apr 2019 | A1 |
| 20190109712 | Blass et al. | Apr 2019 | A1 |
| 20190109828 | Song | Apr 2019 | A1 |
| 20190114706 | Bell et al. | Apr 2019 | A1 |
| 20190116035 | Mustafa et al. | Apr 2019 | A1 |
| 20190116174 | Gray | Apr 2019 | A1 |
| 20190116180 | Teranishi et al. | Apr 2019 | A1 |
| 20190118767 | Britt | Apr 2019 | A1 |
| 20190122297 | Goto | Apr 2019 | A1 |
| 20190124051 | Soon-Shiong et al. | Apr 2019 | A1 |
| 20190130125 | Yoshino et al. | May 2019 | A1 |
| 20190130483 | de Jong | May 2019 | A1 |
| 20190130698 | Simons | May 2019 | A1 |
| 20190130701 | Simons | May 2019 | A1 |
| 20190132295 | Lenz et al. | May 2019 | A1 |
| 20190139007 | Rahn | May 2019 | A1 |
| 20190140818 | Bent et al. | May 2019 | A1 |
| 20190141051 | Ikarashi | May 2019 | A1 |
| 20190141568 | Balakrishnan et al. | May 2019 | A1 |
| 20190146917 | Lomet et al. | May 2019 | A1 |
| 20190147143 | Zweig et al. | May 2019 | A1 |
| 20190147415 | Peikert et al. | May 2019 | A1 |
| 20190149317 | Payton et al. | May 2019 | A1 |
| 20190152435 | Ujkashevic et al. | May 2019 | A1 |
| 20190155643 | Bhageria et al. | May 2019 | A1 |
| 20190156078 | Hale et al. | May 2019 | A1 |
| 20190158272 | Chopra et al. | May 2019 | A1 |
| 20190158594 | Shadmon et al. | May 2019 | A1 |
| 20190158906 | Gonder et al. | May 2019 | A1 |
| 20190164152 | Bucher | May 2019 | A1 |
| 20190164153 | Agrawal et al. | May 2019 | A1 |
| 20190166113 | Paya et al. | May 2019 | A1 |
| 20190166161 | Anand et al. | May 2019 | A1 |
| 20190166162 | Anand et al. | May 2019 | A1 |
| 20190171847 | Schneider et al. | Jun 2019 | A1 |
| 20190182027 | Kipnis et al. | Jun 2019 | A1 |
| 20190182035 | Chari et al. | Jun 2019 | A1 |
| 20190182216 | Gulak et al. | Jun 2019 | A1 |
| 20190183255 | Louks et al. | Jun 2019 | A1 |
| 20190188708 | Shah | Jun 2019 | A1 |
| 20190188711 | Wu et al. | Jun 2019 | A1 |
| 20190188712 | Fedorov et al. | Jun 2019 | A1 |
| 20190188732 | Hill | Jun 2019 | A1 |
| 20190188787 | Besanson Tuma et al. | Jun 2019 | A1 |
| 20190188790 | Lovato et al. | Jun 2019 | A1 |
| 20190188793 | Molinari et al. | Jun 2019 | A1 |
| 20190188806 | Torrenegra et al. | Jun 2019 | A1 |
| 20190188941 | Campero et al. | Jun 2019 | A1 |
| 20190190261 | Valkov | Jun 2019 | A1 |
| 20190190694 | Joye et al. | Jun 2019 | A1 |
| 20190190695 | Kaul et al. | Jun 2019 | A1 |
| 20190190698 | Nuzzi | Jun 2019 | A1 |
| 20190190701 | Mitra et al. | Jun 2019 | A1 |
| 20190190713 | Hirano et al. | Jun 2019 | A1 |
| 20190190714 | Joye et al. | Jun 2019 | A1 |
| 20190190719 | van de Ruit et al. | Jun 2019 | A1 |
| 20190190742 | Reinelt et al. | Jun 2019 | A1 |
| 20190190987 | Waffner | Jun 2019 | A1 |
| 20190197094 | Warstler | Jun 2019 | A1 |
| 20190197249 | Jancosek et al. | Jun 2019 | A1 |
| 20190197378 | Garner | Jun 2019 | A1 |
| 20190197534 | Alastair | Jun 2019 | A1 |
| 20190197589 | Singh et al. | Jun 2019 | A1 |
| 20190197600 | Chang | Jun 2019 | A1 |
| 20190197622 | Molinari et al. | Jun 2019 | A1 |
| 20190197635 | Kim | Jun 2019 | A1 |
| 20190197831 | Batton | Jun 2019 | A1 |
| 20190197835 | Keilwert et al. | Jun 2019 | A1 |
| 20190198144 | Blackley et al. | Jun 2019 | A1 |
| 20190199511 | Kyakuno et al. | Jun 2019 | A1 |
| 20190199514 | Hari et al. | Jun 2019 | A1 |
| 20190199516 | Carver et al. | Jun 2019 | A1 |
| 20190199518 | Rady | Jun 2019 | A1 |
| 20190199531 | Staples et al. | Jun 2019 | A1 |
| 20190199535 | Falk | Jun 2019 | A1 |
| 20190199693 | Vityaz | Jun 2019 | A1 |
| 20190199695 | Bhardwaj et al. | Jun 2019 | A1 |
| 20190199700 | Abramowitz | Jun 2019 | A1 |
| 20190204881 | Plavsic | Jul 2019 | A1 |
| 20190205066 | Warstler | Jul 2019 | A1 |
| 20190205115 | Gomes | Jul 2019 | A1 |
| 20190205317 | Tobias et al. | Jul 2019 | A1 |
| 20190205486 | Santarone et al. | Jul 2019 | A1 |
| 20190205547 | Horvath | Jul 2019 | A1 |
| 20190205558 | Gonzales, Jr. | Jul 2019 | A1 |
| 20190205563 | Gonzales, Jr. | Jul 2019 | A1 |
| 20190205568 | Veugen | Jul 2019 | A1 |
| 20190205773 | Ackerman et al. | Jul 2019 | A1 |
| 20190205832 | Henderson | Jul 2019 | A1 |
| 20190205844 | Nuzzi | Jul 2019 | A1 |
| 20190205849 | Nuzzi | Jul 2019 | A1 |
| 20190205853 | Kassemi et al. | Jul 2019 | A1 |
| 20190205870 | Kamalsky et al. | Jul 2019 | A1 |
| 20190205873 | Kamalsky et al. | Jul 2019 | A1 |
| 20190205875 | Gulak et al. | Jul 2019 | A1 |
| 20190205881 | Borzilleri et al. | Jul 2019 | A1 |
| 20190205886 | Ramakrishnan et al. | Jul 2019 | A1 |
| 20190205894 | Gonzales, Jr. et al. | Jul 2019 | A1 |
| 20190205932 | Ericson | Jul 2019 | A1 |
| 20190205943 | Candelore | Jul 2019 | A1 |
| 20190205970 | McHale et al. | Jul 2019 | A1 |
| 20190205980 | Pierce et al. | Jul 2019 | A1 |
| 20190206182 | Hiten et al. | Jul 2019 | A1 |
| 20190206183 | Hiten et al. | Jul 2019 | A1 |
| 20190206191 | Halvorson | Jul 2019 | A1 |
| 20190206272 | Isozu | Jul 2019 | A1 |
| 20190207757 | Hennebert | Jul 2019 | A1 |
| 20190207760 | Hennebert | Jul 2019 | A1 |
| 20190207763 | Jin et al. | Jul 2019 | A1 |
| 20190207767 | Ahn | Jul 2019 | A1 |
| 20190207770 | Zhou et al. | Jul 2019 | A1 |
| 20190207781 | Harpur et al. | Jul 2019 | A1 |
| 20190207951 | Oberhauser et al. | Jul 2019 | A1 |
| 20190207955 | El-Moussa et al. | Jul 2019 | A1 |
| 20190207969 | Brown | Jul 2019 | A1 |
| 20190207995 | Gonzales, Jr. | Jul 2019 | A1 |
| 20190208354 | Raduchel et al. | Jul 2019 | A1 |
| 20190208414 | Roennow et al. | Jul 2019 | A1 |
| 20190208422 | Haleem et al. | Jul 2019 | A1 |
| 20190212159 | Petersen et al. | Jul 2019 | A1 |
| 20190213311 | Tussy | Jul 2019 | A1 |
| 20190213312 | Tussy | Jul 2019 | A1 |
| 20190213333 | Williams et al. | Jul 2019 | A1 |
| 20190213335 | Unitt | Jul 2019 | A1 |
| 20190213371 | Endress et al. | Jul 2019 | A1 |
| 20190213462 | McDonald et al. | Jul 2019 | A1 |
| 20190213573 | Zelten et al. | Jul 2019 | A1 |
| 20190213584 | Shanmugam | Jul 2019 | A1 |
| 20190213586 | Baratam | Jul 2019 | A1 |
| 20190213590 | Eagleton | Jul 2019 | A1 |
| 20190213633 | Kokernak | Jul 2019 | A1 |
| 20190213699 | Branscomb et al. | Jul 2019 | A1 |
| 20190213751 | Bradski | Jul 2019 | A1 |
| 20190213840 | Alexander | Jul 2019 | A1 |
| 20190214848 | Waffner | Jul 2019 | A1 |
| 20190215159 | Notani | Jul 2019 | A1 |
| 20190215311 | Cox et al. | Jul 2019 | A1 |
| 20190215404 | Stocker et al. | Jul 2019 | A1 |
| 20190215670 | Ameixieira | Jul 2019 | A1 |
| 20190217022 | Gentz et al. | Jul 2019 | A1 |
| 20190220010 | Leonard et al. | Jul 2019 | A1 |
| 20190220324 | Carver et al. | Jul 2019 | A1 |
| 20190220603 | Gopalakrishnan et al. | Jul 2019 | A1 |
| 20190220624 | Uhr et al. | Jul 2019 | A1 |
| 20190220768 | Li et al. | Jul 2019 | A1 |
| 20190220813 | Madisetti et al. | Jul 2019 | A1 |
| 20190220836 | Caldwell | Jul 2019 | A1 |
| 20190220851 | Barnes et al. | Jul 2019 | A1 |
| 20190220852 | Black et al. | Jul 2019 | A1 |
| 20190220854 | Pesci et al. | Jul 2019 | A1 |
| 20190220856 | Li et al. | Jul 2019 | A1 |
| 20190220857 | Black et al. | Jul 2019 | A1 |
| 20190220858 | Weight et al. | Jul 2019 | A1 |
| 20190220859 | Weight et al. | Jul 2019 | A1 |
| 20190220860 | Whitmyer, Jr. | Jul 2019 | A1 |
| 20190220861 | Silver et al. | Jul 2019 | A1 |
| 20190220886 | Le et al. | Jul 2019 | A1 |
| 20190220919 | Martinez et al. | Jul 2019 | A1 |
| 20190220922 | Barkas et al. | Jul 2019 | A1 |
| 20190221076 | Simons | Jul 2019 | A1 |
| 20190222424 | Lindemann | Jul 2019 | A1 |
| 20190222567 | Caldera et al. | Jul 2019 | A1 |
| 20190222575 | Oberhauser et al. | Jul 2019 | A1 |
| 20190222586 | Sachkov et al. | Jul 2019 | A1 |
| 20190226850 | Young et al. | Jul 2019 | A1 |
| 20190227515 | Fink et al. | Jul 2019 | A1 |
| 20190227553 | Kentley-Klay et al. | Jul 2019 | A1 |
| 20190228019 | Madisetti et al. | Jul 2019 | A1 |
| 20190228133 | Ansari et al. | Jul 2019 | A1 |
| 20190228174 | Withrow et al. | Jul 2019 | A1 |
| 20190228178 | Sharma et al. | Jul 2019 | A1 |
| 20190228351 | Simpson et al. | Jul 2019 | A1 |
| 20190228386 | Onnainty | Jul 2019 | A1 |
| 20190228387 | Chu et al. | Jul 2019 | A1 |
| 20190228397 | Madden | Jul 2019 | A1 |
| 20190228407 | Wu | Jul 2019 | A1 |
| 20190228409 | Madisetti et al. | Jul 2019 | A1 |
| 20190228413 | Naganuma et al. | Jul 2019 | A1 |
| 20190228461 | Domokos et al. | Jul 2019 | A1 |
| 20190228469 | Yu et al. | Jul 2019 | A1 |
| 20190228484 | Sheppard et al. | Jul 2019 | A1 |
| 20190228612 | Pierce et al. | Jul 2019 | A1 |
| 20190229887 | Ding et al. | Jul 2019 | A1 |
| 20190229889 | Kounavis | Jul 2019 | A1 |
| 20190229891 | Naqvi et al. | Jul 2019 | A1 |
| 20190229892 | Jevans | Jul 2019 | A1 |
| 20190229909 | Patel et al. | Jul 2019 | A1 |
| 20190229911 | Allen | Jul 2019 | A1 |
| 20190229914 | Patel et al. | Jul 2019 | A1 |
| 20190229918 | Naqvi et al. | Jul 2019 | A1 |
| 20190229920 | Naqvi et al. | Jul 2019 | A1 |
| 20190229921 | Pulsifer | Jul 2019 | A1 |
| 20190229927 | Guo et al. | Jul 2019 | A1 |
| 20190229930 | Haque et al. | Jul 2019 | A1 |
| 20190230054 | Kassemi et al. | Jul 2019 | A1 |
| 20190230070 | Isaacson et al. | Jul 2019 | A1 |
| 20190230073 | Patel et al. | Jul 2019 | A1 |
| 20190230092 | Patel et al. | Jul 2019 | A1 |
| 20190230114 | Grebovich | Jul 2019 | A1 |
| 20190232161 | Fortuna, Jr. | Aug 2019 | A1 |
| 20190233060 | Moffat et al. | Aug 2019 | A1 |
| 20190235933 | Levandoski et al. | Aug 2019 | A1 |
| 20190235946 | Guo et al. | Aug 2019 | A1 |
| 20190236214 | Kokernak | Aug 2019 | A1 |
| 20190236286 | Scriber et al. | Aug 2019 | A1 |
| 20190236298 | Agarwal | Aug 2019 | A1 |
| 20190236300 | Guo et al. | Aug 2019 | A1 |
| 20190236559 | Padmanabhan | Aug 2019 | A1 |
| 20190236561 | Hamilton et al. | Aug 2019 | A1 |
| 20190236562 | Padmanabhan | Aug 2019 | A1 |
| 20190236563 | Tan | Aug 2019 | A1 |
| 20190236564 | Cantrell et al. | Aug 2019 | A1 |
| 20190236591 | Iaremenko et al. | Aug 2019 | A1 |
| 20190236593 | Vorobyev et al. | Aug 2019 | A1 |
| 20190236594 | Ehrlich-Quinn | Aug 2019 | A1 |
| 20190236598 | Padmanabhan | Aug 2019 | A1 |
| 20190236606 | Padmanabhan et al. | Aug 2019 | A1 |
| 20190236627 | Christensen | Aug 2019 | A1 |
| 20190236665 | Liberty et al. | Aug 2019 | A1 |
| 20190236698 | Postrel | Aug 2019 | A1 |
| 20190236699 | Newton | Aug 2019 | A1 |
| 20190236716 | Kasper et al. | Aug 2019 | A1 |
| 20190236879 | Ivanov et al. | Aug 2019 | A1 |
| 20190236880 | Ivanov et al. | Aug 2019 | A1 |
| 20190236881 | Ivanov et al. | Aug 2019 | A1 |
| 20190236893 | Halvorson | Aug 2019 | A1 |
| 20190237095 | Duguid et al. | Aug 2019 | A1 |
| 20190237171 | Kain et al. | Aug 2019 | A1 |
| 20190238311 | Zheng | Aug 2019 | A1 |
| 20190238316 | Padmanabhan | Aug 2019 | A1 |
| 20190238319 | Beck | Aug 2019 | A1 |
| 20190238327 | Li et al. | Aug 2019 | A1 |
| 20190238337 | Laremenko et al. | Aug 2019 | A1 |
| 20190238344 | Kaga et al. | Aug 2019 | A1 |
| 20190238487 | Ciano et al. | Aug 2019 | A1 |
| 20190238525 | Padmanabhan et al. | Aug 2019 | A1 |
| 20190243611 | Martin et al. | Aug 2019 | A1 |
| 20190243820 | Shen et al. | Aug 2019 | A1 |
| 20190243912 | Duraisamy Soundrapandian et al. | Aug 2019 | A1 |
| 20190243988 | Khi et al. | Aug 2019 | A1 |
| 20190244138 | Bhowmick et al. | Aug 2019 | A1 |
| 20190244195 | Ma et al. | Aug 2019 | A1 |
| 20190244215 | Watanabe et al. | Aug 2019 | A1 |
| 20190244227 | Inoue | Aug 2019 | A1 |
| 20190244255 | Cohen | Aug 2019 | A1 |
| 20190244287 | Prasad Datta et al. | Aug 2019 | A1 |
| 20190244290 | Massacci et al. | Aug 2019 | A1 |
| 20190244294 | Shao et al. | Aug 2019 | A1 |
| 20190244298 | Doney | Aug 2019 | A1 |
| 20190244483 | Collins | Aug 2019 | A1 |
| 20190244531 | Jones et al. | Aug 2019 | A1 |
| 20190245680 | Boutaba et al. | Aug 2019 | A1 |
| 20190245917 | Mendiola et al. | Aug 2019 | A1 |
| 20190251018 | Jin et al. | Aug 2019 | A1 |
| 20190251075 | Yan | Aug 2019 | A1 |
| 20190251077 | Yang | Aug 2019 | A1 |
| 20190251078 | Yan | Aug 2019 | A1 |
| 20190251079 | Yan | Aug 2019 | A1 |
| 20190251080 | Lu et al. | Aug 2019 | A1 |
| 20190251124 | Pan et al. | Aug 2019 | A1 |
| 20190251187 | Lin | Aug 2019 | A1 |
| 20190251199 | Klianev | Aug 2019 | A1 |
| 20190251249 | Sprague et al. | Aug 2019 | A1 |
| 20190251262 | Fiske | Aug 2019 | A1 |
| 20190251270 | Liu et al. | Aug 2019 | A1 |
| 20190251271 | Roets et al. | Aug 2019 | A1 |
| 20190251284 | Anton et al. | Aug 2019 | A1 |
| 20190251296 | Maneval et al. | Aug 2019 | A1 |
| 20190251489 | Berti et al. | Aug 2019 | A1 |
| 20190251503 | Simpson | Aug 2019 | A1 |
| 20190251509 | Simpson | Aug 2019 | A1 |
| 20190251523 | Rittman et al. | Aug 2019 | A1 |
| 20190251524 | Sadrizadeh et al. | Aug 2019 | A1 |
| 20190251526 | Jackson | Aug 2019 | A1 |
| 20190251527 | Surdak | Aug 2019 | A1 |
| 20190251551 | Mousavi | Aug 2019 | A1 |
| 20190251552 | Kurian | Aug 2019 | A1 |
| 20190251553 | Ma et al. | Aug 2019 | A1 |
| 20190251554 | Ma et al. | Aug 2019 | A1 |
| 20190251557 | Jin et al. | Aug 2019 | A1 |
| 20190251558 | Liu et al. | Aug 2019 | A1 |
| 20190251563 | Yan | Aug 2019 | A1 |
| 20190251566 | Pan et al. | Aug 2019 | A1 |
| 20190251573 | Toyota et al. | Aug 2019 | A1 |
| 20190251575 | Berti et al. | Aug 2019 | A1 |
| 20190251576 | Saab et al. | Aug 2019 | A1 |
| 20190251603 | Jaatinen et al. | Aug 2019 | A1 |
| 20190251624 | Tsuboi | Aug 2019 | A1 |
| 20190251627 | Wang | Aug 2019 | A1 |
| 20190251629 | Gordon et al. | Aug 2019 | A1 |
| 20190251648 | Liu et al. | Aug 2019 | A1 |
| 20190253235 | Zhang et al. | Aug 2019 | A1 |
| 20190253239 | Shao et al. | Aug 2019 | A1 |
| 20190253244 | Hamel et al. | Aug 2019 | A1 |
| 20190253245 | Zhang et al. | Aug 2019 | A1 |
| 20190253250 | Bruner et al. | Aug 2019 | A1 |
| 20190253252 | Qiu | Aug 2019 | A1 |
| 20190253254 | Brownlee et al. | Aug 2019 | A1 |
| 20190253256 | Saab et al. | Aug 2019 | A1 |
| 20190253257 | Yan | Aug 2019 | A1 |
| 20190253258 | Thekadath et al. | Aug 2019 | A1 |
| 20190253259 | Qiu | Aug 2019 | A1 |
| 20190253260 | Uehara et al. | Aug 2019 | A1 |
| 20190253261 | Gero et al. | Aug 2019 | A1 |
| 20190253263 | Qiu | Aug 2019 | A1 |
| 20190253265 | Pan et al. | Aug 2019 | A1 |
| 20190253523 | Raduchel et al. | Aug 2019 | A1 |
| 20190253524 | Hoshizuki | Aug 2019 | A1 |
| 20190258523 | Tappeiner et al. | Aug 2019 | A1 |
| 20190258610 | Dang et al. | Aug 2019 | A1 |
| 20190258687 | Spangenberg et al. | Aug 2019 | A1 |
| 20190258807 | DiMaggio et al. | Aug 2019 | A1 |
| 20190258828 | Rice | Aug 2019 | A1 |
| 20190258953 | Lang et al. | Aug 2019 | A1 |
| 20190258971 | Winarski | Aug 2019 | A1 |
| 20190259008 | Lindsey | Aug 2019 | A1 |
| 20190259013 | Armstrong et al. | Aug 2019 | A1 |
| 20190259025 | Hilton et al. | Aug 2019 | A1 |
| 20190259029 | Chilton et al. | Aug 2019 | A1 |
| 20190259093 | Turato | Aug 2019 | A1 |
| 20190259095 | Templeton | Aug 2019 | A1 |
| 20190259099 | Katsuyama et al. | Aug 2019 | A1 |
| 20190259114 | Spangenberg et al. | Aug 2019 | A1 |
| 20190259120 | Mattingly et al. | Aug 2019 | A1 |
| 20190260574 | Shi et al. | Aug 2019 | A1 |
| 20190260579 | Hamel et al. | Aug 2019 | A1 |
| 20190260585 | Kawai et al. | Aug 2019 | A1 |
| 20190260715 | Suzuki et al. | Aug 2019 | A1 |
| 20190260761 | Wilson | Aug 2019 | A1 |
| 20190260788 | Torkelson et al. | Aug 2019 | A1 |
| 20190260829 | Cencini et al. | Aug 2019 | A1 |
| 20190266128 | Maeda et al. | Aug 2019 | A1 |
| 20190266146 | Rose et al. | Aug 2019 | A1 |
| 20190266178 | Madhavan et al. | Aug 2019 | A1 |
| 20190266235 | Northrup et al. | Aug 2019 | A1 |
| 20190266263 | Jiang et al. | Aug 2019 | A1 |
| 20190266327 | Satpathy | Aug 2019 | A1 |
| 20190266576 | McCauley et al. | Aug 2019 | A1 |
| 20190266577 | Baldet et al. | Aug 2019 | A1 |
| 20190266597 | Mohtar | Aug 2019 | A1 |
| 20190266601 | Allen | Aug 2019 | A1 |
| 20190266612 | McHale et al. | Aug 2019 | A1 |
| 20190266897 | Turato | Aug 2019 | A1 |
| 20190267119 | Witchey | Aug 2019 | A1 |
| 20190268138 | Mankovskii et al. | Aug 2019 | A1 |
| 20190268141 | Pandurangan et al. | Aug 2019 | A1 |
| 20190268147 | Baird | Aug 2019 | A1 |
| 20190268163 | Nadeau et al. | Aug 2019 | A1 |
| 20190268165 | Monica et al. | Aug 2019 | A1 |
| 20190268284 | Karame et al. | Aug 2019 | A1 |
| 20190268312 | Ma et al. | Aug 2019 | A1 |
| 20190268466 | Inoue | Aug 2019 | A1 |
| 20190271959 | Firu et al. | Sep 2019 | A1 |
| 20190272393 | Rodriguez De Castro et al. | Sep 2019 | A1 |
| 20190272512 | Dwivedi et al. | Sep 2019 | A1 |
| 20190272534 | Griffith | Sep 2019 | A1 |
| 20190272537 | Miller et al. | Sep 2019 | A1 |
| 20190272538 | Arneson et al. | Sep 2019 | A1 |
| 20190272589 | Simpson | Sep 2019 | A1 |
| 20190272721 | Dwivedi et al. | Sep 2019 | A1 |
| 20190273610 | Fan et al. | Sep 2019 | A1 |
| 20190273616 | Bres | Sep 2019 | A1 |
| 20190273619 | Campagna et al. | Sep 2019 | A1 |
| 20190273725 | Allen | Sep 2019 | A1 |
| 20190273739 | Pemmaraju | Sep 2019 | A1 |
| 20190275894 | Amacker et al. | Sep 2019 | A1 |
| 20190278765 | Ying et al. | Sep 2019 | A1 |
| 20190278907 | Boivie et al. | Sep 2019 | A1 |
| 20190278918 | Boivie et al. | Sep 2019 | A1 |
| 20190278920 | Black et al. | Sep 2019 | A1 |
| 20190278921 | Unitt | Sep 2019 | A1 |
| 20190279143 | Rinzler et al. | Sep 2019 | A1 |
| 20190279160 | Whitney et al. | Sep 2019 | A1 |
| 20190279172 | Duffield et al. | Sep 2019 | A1 |
| 20190279181 | Kelly et al. | Sep 2019 | A1 |
| 20190279197 | Wright et al. | Sep 2019 | A1 |
| 20190279204 | Norton et al. | Sep 2019 | A1 |
| 20190279206 | Song et al. | Sep 2019 | A1 |
| 20190279210 | Pen | Sep 2019 | A1 |
| 20190279215 | Kuchar et al. | Sep 2019 | A1 |
| 20190279247 | Finken et al. | Sep 2019 | A1 |
| 20190279257 | Kokernak | Sep 2019 | A1 |
| 20190279321 | Sheets et al. | Sep 2019 | A1 |
| 20190280856 | Yeap et al. | Sep 2019 | A1 |
| 20190280861 | Smith et al. | Sep 2019 | A1 |
| 20190280864 | Cheng et al. | Sep 2019 | A1 |
| 20190280872 | Falk | Sep 2019 | A1 |
| 20190280873 | Yang | Sep 2019 | A1 |
| 20190280880 | Zhang et al. | Sep 2019 | A1 |
| 20190281026 | Mitchell et al. | Sep 2019 | A1 |
| 20190281028 | Gillan et al. | Sep 2019 | A1 |
| 20190281030 | Isaacson et al. | Sep 2019 | A1 |
| 20190281066 | Simons | Sep 2019 | A1 |
| 20190281259 | Palazzolo | Sep 2019 | A1 |
| 20190281465 | Moshir et al. | Sep 2019 | A1 |
| 20190281857 | Cocchi et al. | Sep 2019 | A1 |
| 20190282906 | Yong | Sep 2019 | A1 |
| 20190283239 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190283240 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190283252 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190283648 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190283962 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190286102 | Carbone et al. | Sep 2019 | A1 |
| 20190286138 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190286139 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190286152 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190286164 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190286490 | Wang | Sep 2019 | A1 |
| 20190286532 | Guo et al. | Sep 2019 | A1 |
| 20190286805 | Law et al. | Sep 2019 | A1 |
| 20190287046 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190287047 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190287059 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190287062 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190287063 | Skaaksrud et al. | Sep 2019 | A1 |
| 20190287069 | Kassemi et al. | Sep 2019 | A1 |
| 20190287102 | Cocchi et al. | Sep 2019 | A1 |
| 20190287105 | Fedorov et al. | Sep 2019 | A1 |
| 20190287107 | Gaur et al. | Sep 2019 | A1 |
| 20190287149 | Papp et al. | Sep 2019 | A1 |
| 20190287174 | Black et al. | Sep 2019 | A1 |
| 20190287175 | Hill et al. | Sep 2019 | A1 |
| 20190287199 | Messerges et al. | Sep 2019 | A1 |
| 20190287200 | Schuler et al. | Sep 2019 | A1 |
| 20190288832 | Dang et al. | Sep 2019 | A1 |
| 20190288850 | Beecham et al. | Sep 2019 | A1 |
| 20190288853 | Gray | Sep 2019 | A1 |
| 20190289068 | Ma et al. | Sep 2019 | A1 |
| 20190289454 | Inoue | Sep 2019 | A1 |
| 20190290964 | Oren | Sep 2019 | A1 |
| 20190290965 | Oren | Sep 2019 | A1 |
| 20190290991 | Pasternak et al. | Sep 2019 | A1 |
| 20190294513 | Marripudi et al. | Sep 2019 | A1 |
| 20190294689 | Mathur et al. | Sep 2019 | A1 |
| 20190294805 | Taylor et al. | Sep 2019 | A1 |
| 20190294817 | Hennebert et al. | Sep 2019 | A1 |
| 20190294822 | Hennebert | Sep 2019 | A1 |
| 20190294956 | Cheung et al. | Sep 2019 | A1 |
| 20190295038 | Kozloski et al. | Sep 2019 | A1 |
| 20190295045 | Stocker et al. | Sep 2019 | A1 |
| 20190295049 | Karame et al. | Sep 2019 | A1 |
| 20190295050 | Chalkias | Sep 2019 | A1 |
| 20190295069 | Pala et al. | Sep 2019 | A1 |
| 20190295073 | Cabre et al. | Sep 2019 | A1 |
| 20190295078 | Bae | Sep 2019 | A1 |
| 20190295079 | Bae | Sep 2019 | A1 |
| 20190295114 | Pavletic et al. | Sep 2019 | A1 |
| 20190295126 | Madden | Sep 2019 | A1 |
| 20190295159 | Samid | Sep 2019 | A1 |
| 20190295176 | Parker, Jr. | Sep 2019 | A1 |
| 20190295177 | Parker, Jr. | Sep 2019 | A1 |
| 20190295182 | Kfir et al. | Sep 2019 | A1 |
| 20190295193 | Winand et al. | Sep 2019 | A1 |
| 20190295350 | Wegelin | Sep 2019 | A1 |
| 20190295371 | Simons | Sep 2019 | A1 |
| 20190295415 | Haneda | Sep 2019 | A1 |
| 20190295547 | Gandhi et al. | Sep 2019 | A1 |
| 20190295722 | Abramoff | Sep 2019 | A1 |
| 20190296895 | Banks et al. | Sep 2019 | A1 |
| 20190296896 | Resch et al. | Sep 2019 | A1 |
| 20190296897 | Resch et al. | Sep 2019 | A1 |
| 20190296902 | Kumar et al. | Sep 2019 | A1 |
| 20190296903 | Ramesh | Sep 2019 | A1 |
| 20190296904 | Smith et al. | Sep 2019 | A1 |
| 20190296907 | Versteeg et al. | Sep 2019 | A1 |
| 20190296910 | Cheung | Sep 2019 | A1 |
| 20190296915 | Lancashire | Sep 2019 | A1 |
| 20190296916 | Qiu | Sep 2019 | A1 |
| 20190296920 | Uhr et al. | Sep 2019 | A1 |
| 20190296958 | Cencini et al. | Sep 2019 | A1 |
| 20190297031 | Basheer et al. | Sep 2019 | A1 |
| 20190297062 | Chaum | Sep 2019 | A1 |
| 20190297064 | Resch et al. | Sep 2019 | A1 |
| 20190297101 | Dhakshinamoorthy et al. | Sep 2019 | A1 |
| 20190297109 | Guo et al. | Sep 2019 | A1 |
| 20190297134 | Gold | Sep 2019 | A1 |
| 20190297442 | Lyren et al. | Sep 2019 | A1 |
| 20190297544 | Crawford | Sep 2019 | A1 |
| 20190299105 | Knight et al. | Oct 2019 | A1 |
| 20190301875 | Ringer et al. | Oct 2019 | A1 |
| 20190301883 | Xia | Oct 2019 | A1 |
| 20190302249 | High et al. | Oct 2019 | A1 |
| 20190302717 | Pelton | Oct 2019 | A1 |
| 20190302993 | Francis | Oct 2019 | A1 |
| 20190303111 | Warstler | Oct 2019 | A1 |
| 20190303121 | Padmanabhan | Oct 2019 | A1 |
| 20190303250 | Smith et al. | Oct 2019 | A1 |
| 20190303296 | Jagtap | Oct 2019 | A1 |
| 20190303349 | Burshteyn | Oct 2019 | A1 |
| 20190303353 | Letz et al. | Oct 2019 | A1 |
| 20190303362 | Yang et al. | Oct 2019 | A1 |
| 20190303363 | Leung et al. | Oct 2019 | A1 |
| 20190303413 | Colangelo | Oct 2019 | A1 |
| 20190303441 | Bacarella et al. | Oct 2019 | A1 |
| 20190303445 | Padmanabhan | Oct 2019 | A1 |
| 20190303448 | Colangelo | Oct 2019 | A1 |
| 20190303463 | Catalano et al. | Oct 2019 | A1 |
| 20190303540 | Shirasaka et al. | Oct 2019 | A1 |
| 20190303541 | Reddy et al. | Oct 2019 | A1 |
| 20190303543 | Savanah et al. | Oct 2019 | A1 |
| 20190303550 | Ibrahim et al. | Oct 2019 | A1 |
| 20190303551 | Tussy | Oct 2019 | A1 |
| 20190303552 | Houseworth et al. | Oct 2019 | A1 |
| 20190303559 | Hamel et al. | Oct 2019 | A1 |
| 20190303579 | Reddy et al. | Oct 2019 | A1 |
| 20190303587 | Hamel et al. | Oct 2019 | A1 |
| 20190303590 | Hamel et al. | Oct 2019 | A1 |
| 20190303600 | Hamel et al. | Oct 2019 | A1 |
| 20190303603 | Courtney et al. | Oct 2019 | A1 |
| 20190303620 | Jacobs | Oct 2019 | A1 |
| 20190303621 | Baset et al. | Oct 2019 | A1 |
| 20190303622 | Versteeg et al. | Oct 2019 | A1 |
| 20190303623 | Reddy et al. | Oct 2019 | A1 |
| 20190303670 | Bryden | Oct 2019 | A1 |
| 20190303781 | Clark et al. | Oct 2019 | A1 |
| 20190303790 | Harvilla et al. | Oct 2019 | A1 |
| 20190303805 | Mizutani et al. | Oct 2019 | A1 |
| 20190303807 | Gueye | Oct 2019 | A1 |
| 20190303834 | Paul et al. | Oct 2019 | A1 |
| 20190303843 | O'Brien et al. | Oct 2019 | A1 |
| 20190303853 | Cantrell et al. | Oct 2019 | A1 |
| 20190303854 | O'Brien et al. | Oct 2019 | A1 |
| 20190303867 | Nair | Oct 2019 | A1 |
| 20190303879 | Mankovskii et al. | Oct 2019 | A1 |
| 20190303882 | Purushothaman et al. | Oct 2019 | A1 |
| 20190303886 | Kikinis | Oct 2019 | A1 |
| 20190303887 | Wright et al. | Oct 2019 | A1 |
| 20190303888 | Hamasni et al. | Oct 2019 | A1 |
| 20190303892 | Yantis et al. | Oct 2019 | A1 |
| 20190303893 | Ramasamy et al. | Oct 2019 | A1 |
| 20190303913 | Muchang et al. | Oct 2019 | A1 |
| 20190303920 | Balaraman et al. | Oct 2019 | A1 |
| 20190303921 | Mutter | Oct 2019 | A1 |
| 20190303922 | Hamasni et al. | Oct 2019 | A1 |
| 20190303926 | Yantis et al. | Oct 2019 | A1 |
| 20190303927 | Shao et al. | Oct 2019 | A1 |
| 20190303929 | Brown et al. | Oct 2019 | A1 |
| 20190303931 | Valencia | Oct 2019 | A1 |
| 20190303932 | Klaedtke | Oct 2019 | A1 |
| 20190303933 | Lindsay et al. | Oct 2019 | A1 |
| 20190303935 | Cantrell et al. | Oct 2019 | A1 |
| 20190303939 | Kurian et al. | Oct 2019 | A1 |
| 20190303942 | Balaraman et al. | Oct 2019 | A1 |
| 20190303951 | Bakalis | Oct 2019 | A1 |
| 20190303960 | Walsh | Oct 2019 | A1 |
| 20190304005 | Ward et al. | Oct 2019 | A1 |
| 20190304012 | Ramirez et al. | Oct 2019 | A1 |
| 20190304027 | Hu et al. | Oct 2019 | A1 |
| 20190304038 | Purushothaman et al. | Oct 2019 | A1 |
| 20190304165 | Jacobs | Oct 2019 | A1 |
| 20190304253 | Dabrowski | Oct 2019 | A1 |
| 20190304259 | Joao | Oct 2019 | A1 |
| 20190304260 | Bosak | Oct 2019 | A1 |
| 20190304578 | Kain et al. | Oct 2019 | A1 |
| 20190304582 | Blumenthal et al. | Oct 2019 | A1 |
| 20190305931 | Borst et al. | Oct 2019 | A1 |
| 20190305932 | Townsend | Oct 2019 | A1 |
| 20190305933 | Miyamae et al. | Oct 2019 | A1 |
| 20190305934 | Cantrell et al. | Oct 2019 | A1 |
| 20190305935 | Qiu | Oct 2019 | A1 |
| 20190305936 | King | Oct 2019 | A1 |
| 20190305937 | Baykaner et al. | Oct 2019 | A1 |
| 20190305938 | Sandberg-Maitland et al. | Oct 2019 | A1 |
| 20190305943 | Hoersten et al. | Oct 2019 | A1 |
| 20190305949 | Hamel et al. | Oct 2019 | A1 |
| 20190305950 | Treat et al. | Oct 2019 | A1 |
| 20190305952 | Hamel et al. | Oct 2019 | A1 |
| 20190305954 | Hamel et al. | Oct 2019 | A1 |
| 20190305956 | Irani | Oct 2019 | A1 |
| 20190305957 | Reddy et al. | Oct 2019 | A1 |
| 20190305958 | Qiu | Oct 2019 | A1 |
| 20190305959 | Reddy et al. | Oct 2019 | A1 |
| 20190305960 | Szollosi | Oct 2019 | A1 |
| 20190305964 | Hamel et al. | Oct 2019 | A1 |
| 20190305965 | Hamel et al. | Oct 2019 | A1 |
| 20190305966 | Qiu | Oct 2019 | A1 |
| 20190305967 | Hamel et al. | Oct 2019 | A1 |
| 20190305968 | Versteeg et al. | Oct 2019 | A1 |
| 20190306124 | Bild et al. | Oct 2019 | A1 |
| 20190306128 | Kothavale et al. | Oct 2019 | A1 |
| 20190306137 | Isaacson et al. | Oct 2019 | A1 |
| 20190306143 | Hamel et al. | Oct 2019 | A1 |
| 20190306147 | Uhr et al. | Oct 2019 | A1 |
| 20190306148 | Uhr et al. | Oct 2019 | A1 |
| 20190306150 | Letz et al. | Oct 2019 | A1 |
| 20190306151 | Hamel et al. | Oct 2019 | A1 |
| 20190306173 | Reddy et al. | Oct 2019 | A1 |
| 20190306176 | Gleichauf | Oct 2019 | A1 |
| 20190306190 | Suraparaju | Oct 2019 | A1 |
| 20190306230 | Purushothaman et al. | Oct 2019 | A1 |
| 20190306232 | Brock | Oct 2019 | A1 |
| 20190306235 | Veale et al. | Oct 2019 | A1 |
| 20190306463 | Zuckerman et al. | Oct 2019 | A1 |
| 20190306549 | Dietz et al. | Oct 2019 | A1 |
| 20190306552 | Wood et al. | Oct 2019 | A1 |
| 20190306574 | Eccles et al. | Oct 2019 | A1 |
| 20190306647 | Lyren et al. | Oct 2019 | A1 |
| 20190306757 | Husain et al. | Oct 2019 | A1 |
| 20190307388 | Bobo et al. | Oct 2019 | A1 |
| 20190308806 | Gathman et al. | Oct 2019 | A1 |
| 20190310137 | Pop | Oct 2019 | A1 |
| 20190310695 | North et al. | Oct 2019 | A1 |
| 20190310878 | Qiu | Oct 2019 | A1 |
| 20190310900 | Lee et al. | Oct 2019 | A1 |
| 20190310943 | Noll et al. | Oct 2019 | A1 |
| 20190310980 | Zhang et al. | Oct 2019 | A1 |
| 20190311006 | Yelton et al. | Oct 2019 | A1 |
| 20190311033 | Evans | Oct 2019 | A1 |
| 20190311054 | Pundir et al. | Oct 2019 | A1 |
| 20190311090 | Nishida et al. | Oct 2019 | A1 |
| 20190311096 | Eldefrawy | Oct 2019 | A1 |
| 20190311100 | Lindell et al. | Oct 2019 | A1 |
| 20190311102 | Tussy | Oct 2019 | A1 |
| 20190311108 | Achkir et al. | Oct 2019 | A1 |
| 20190311116 | Li | Oct 2019 | A1 |
| 20190311125 | Mulgaonkar et al. | Oct 2019 | A1 |
| 20190311147 | Gollogly | Oct 2019 | A1 |
| 20190311148 | Andrade | Oct 2019 | A1 |
| 20190311153 | Hollinger et al. | Oct 2019 | A1 |
| 20190311196 | Chandrashekar et al. | Oct 2019 | A1 |
| 20190311296 | Fan et al. | Oct 2019 | A1 |
| 20190311336 | Kim et al. | Oct 2019 | A1 |
| 20190311337 | Madisetti et al. | Oct 2019 | A1 |
| 20190311341 | Rice | Oct 2019 | A1 |
| 20190311343 | Cantrell et al. | Oct 2019 | A1 |
| 20190311351 | Zhang et al. | Oct 2019 | A1 |
| 20190311352 | Lui et al. | Oct 2019 | A1 |
| 20190311353 | Solis | Oct 2019 | A1 |
| 20190311357 | Madisetti et al. | Oct 2019 | A1 |
| 20190311358 | Bhagavatha et al. | Oct 2019 | A1 |
| 20190311359 | Fett | Oct 2019 | A1 |
| 20190311392 | Swamidurai | Oct 2019 | A1 |
| 20190311417 | Randisi et al. | Oct 2019 | A1 |
| 20190311428 | Adjaoute | Oct 2019 | A1 |
| 20190311429 | Barkas et al. | Oct 2019 | A1 |
| 20190311431 | Simpson | Oct 2019 | A1 |
| 20190311437 | Sivakumar et al. | Oct 2019 | A1 |
| 20190311443 | Blades | Oct 2019 | A1 |
| 20190311447 | Strnad | Oct 2019 | A1 |
| 20190311571 | Halvorson et al. | Oct 2019 | A1 |
| 20190312440 | Pignier et al. | Oct 2019 | A1 |
| 20190312719 | Cheon et al. | Oct 2019 | A1 |
| 20190312727 | Del Pino et al. | Oct 2019 | A1 |
| 20190312728 | Poeppelmann | Oct 2019 | A1 |
| 20190312731 | Eldefrawy et al. | Oct 2019 | A1 |
| 20190312734 | Wentz et al. | Oct 2019 | A1 |
| 20190312736 | Dickenson et al. | Oct 2019 | A1 |
| 20190312792 | Srinivasan | Oct 2019 | A1 |
| 20190312831 | Gupta et al. | Oct 2019 | A1 |
| 20190312848 | Chennupalli et al. | Oct 2019 | A1 |
| 20190312852 | Hogan et al. | Oct 2019 | A1 |
| 20190312855 | Sharma et al. | Oct 2019 | A1 |
| 20190312863 | Chow et al. | Oct 2019 | A1 |
| 20190312869 | Han et al. | Oct 2019 | A1 |
| 20190312875 | Sardesai et al. | Oct 2019 | A1 |
| 20190312877 | Zhang et al. | Oct 2019 | A1 |
| 20190312878 | Brown et al. | Oct 2019 | A1 |
| 20190312879 | Agrawal et al. | Oct 2019 | A1 |
| 20190312886 | Ford et al. | Oct 2019 | A1 |
| 20190312915 | LaJoie et al. | Oct 2019 | A1 |
| 20190312928 | D'Ercoli et al. | Oct 2019 | A1 |
| 20190312939 | Noble | Oct 2019 | A1 |
| 20190312941 | Maccini et al. | Oct 2019 | A1 |
| 20190313576 | Haneda et al. | Oct 2019 | A1 |
| 20190314726 | Masini | Oct 2019 | A1 |
| 20190315314 | Haneda et al. | Oct 2019 | A1 |
| 20190316912 | Maggiore et al. | Oct 2019 | A1 |
| 20190317220 | Kocer et al. | Oct 2019 | A1 |
| 20190317651 | Chopra et al. | Oct 2019 | A1 |
| 20190317677 | Tanaka et al. | Oct 2019 | A1 |
| 20190317810 | Nguyen et al. | Oct 2019 | A1 |
| 20190317924 | Alimi et al. | Oct 2019 | A1 |
| 20190317934 | Jentzsch et al. | Oct 2019 | A1 |
| 20190317935 | Berti et al. | Oct 2019 | A1 |
| 20190317936 | Keskar | Oct 2019 | A1 |
| 20190317961 | Brener et al. | Oct 2019 | A1 |
| 20190317964 | O'Brien | Oct 2019 | A1 |
| 20190317968 | De Los Santos Vilchez et al. | Oct 2019 | A1 |
| 20190318012 | Danilov et al. | Oct 2019 | A1 |
| 20190318043 | Leka | Oct 2019 | A1 |
| 20190318066 | Davis et al. | Oct 2019 | A1 |
| 20190318109 | Thomas | Oct 2019 | A1 |
| 20190318117 | Beecham et al. | Oct 2019 | A1 |
| 20190318122 | Hockey et al. | Oct 2019 | A1 |
| 20190318128 | Ackerman et al. | Oct 2019 | A1 |
| 20190318129 | David et al. | Oct 2019 | A1 |
| 20190318243 | Margaglia et al. | Oct 2019 | A1 |
| 20190318257 | Gould et al. | Oct 2019 | A1 |
| 20190318265 | Gould et al. | Oct 2019 | A1 |
| 20190318286 | Simpson | Oct 2019 | A1 |
| 20190318291 | Diriye et al. | Oct 2019 | A1 |
| 20190318302 | Lawler, Jr. et al. | Oct 2019 | A1 |
| 20190318326 | Russell et al. | Oct 2019 | A1 |
| 20190318327 | Sowell et al. | Oct 2019 | A1 |
| 20190318328 | Castinado et al. | Oct 2019 | A1 |
| 20190318329 | Castinado et al. | Oct 2019 | A1 |
| 20190318332 | Whelan et al. | Oct 2019 | A1 |
| 20190318333 | Castinado et al. | Oct 2019 | A1 |
| 20190318338 | Verma et al. | Oct 2019 | A1 |
| 20190318346 | Ben-David et al. | Oct 2019 | A1 |
| 20190318348 | Brenner et al. | Oct 2019 | A1 |
| 20190318349 | Palombo et al. | Oct 2019 | A1 |
| 20190318350 | Hinkel et al. | Oct 2019 | A1 |
| 20190318351 | Ardashev et al. | Oct 2019 | A1 |
| 20190318353 | Castinado et al. | Oct 2019 | A1 |
| 20190318356 | Martin et al. | Oct 2019 | A1 |
| 20190318358 | Chamberlain et al. | Oct 2019 | A1 |
| 20190318359 | Arora | Oct 2019 | A1 |
| 20190318367 | Myles | Oct 2019 | A1 |
| 20190318377 | Sundaram et al. | Oct 2019 | A1 |
| 20190318399 | Davis et al. | Oct 2019 | A1 |
| 20190318408 | Chao et al. | Oct 2019 | A1 |
| 20190318423 | Kajicek et al. | Oct 2019 | A1 |
| 20190318424 | McWilliams et al. | Oct 2019 | A1 |
| 20190318425 | Tilley et al. | Oct 2019 | A1 |
| 20190318427 | Doney | Oct 2019 | A1 |
| 20190318433 | McGee et al. | Oct 2019 | A1 |
| 20190318631 | Seaman et al. | Oct 2019 | A1 |
| 20190318807 | O'Hara et al. | Oct 2019 | A1 |
| 20190318814 | Unwin | Oct 2019 | A1 |
| 20190318816 | Witchey | Oct 2019 | A1 |
| 20190319780 | Teo et al. | Oct 2019 | A1 |
| 20190319791 | Bos et al. | Oct 2019 | A1 |
| 20190319792 | Irwan et al. | Oct 2019 | A1 |
| 20190319794 | Haldar | Oct 2019 | A1 |
| 20190319798 | Chalkias | Oct 2019 | A1 |
| 20190319806 | Cheng et al. | Oct 2019 | A1 |
| 20190319808 | Fallah et al. | Oct 2019 | A1 |
| 20190319809 | Rowley | Oct 2019 | A1 |
| 20190319861 | Pan et al. | Oct 2019 | A1 |
| 20190319927 | Levine et al. | Oct 2019 | A1 |
| 20190319928 | Nesbit | Oct 2019 | A1 |
| 20190319932 | Kandregula | Oct 2019 | A1 |
| 20190319938 | Castinado et al. | Oct 2019 | A1 |
| 20190319939 | Hamel et al. | Oct 2019 | A1 |
| 20190319940 | Hamel et al. | Oct 2019 | A1 |
| 20190319945 | Levy et al. | Oct 2019 | A1 |
| 20190319948 | Triola et al. | Oct 2019 | A1 |
| 20190319961 | Levy et al. | Oct 2019 | A1 |
| 20190319964 | Smith et al. | Oct 2019 | A1 |
| 20190319968 | Mehta | Oct 2019 | A1 |
| 20190319971 | Levy et al. | Oct 2019 | A1 |
| 20190319980 | Levy et al. | Oct 2019 | A1 |
| 20190319987 | Levy et al. | Oct 2019 | A1 |
| 20190319993 | Christmas et al. | Oct 2019 | A1 |
| 20190320004 | Allen et al. | Oct 2019 | A1 |
| 20190320006 | Allen et al. | Oct 2019 | A1 |
| 20190320014 | Allen et al. | Oct 2019 | A1 |
| 20190320037 | Nair | Oct 2019 | A1 |
| 20190320061 | Salandy-Defour et al. | Oct 2019 | A1 |
| 20190320070 | Adams et al. | Oct 2019 | A1 |
| 20190320210 | Ilhan et al. | Oct 2019 | A1 |
| 20190320242 | Vaughn et al. | Oct 2019 | A1 |
| 20190320580 | Haneda et al. | Oct 2019 | A1 |
| 20190320898 | Dirghangi et al. | Oct 2019 | A1 |
| 20190321132 | Weir et al. | Oct 2019 | A1 |
| 20190322187 | Winkler et al. | Oct 2019 | A1 |
| 20190322426 | Verma et al. | Oct 2019 | A1 |
| 20190323858 | Wilkinson et al. | Oct 2019 | A1 |
| 20190324431 | Cella et al. | Oct 2019 | A1 |
| 20190324432 | Cella et al. | Oct 2019 | A1 |
| 20190324433 | Cella et al. | Oct 2019 | A1 |
| 20190324434 | Cella et al. | Oct 2019 | A1 |
| 20190324435 | Cella et al. | Oct 2019 | A1 |
| 20190324436 | Cella et al. | Oct 2019 | A1 |
| 20190324437 | Cella et al. | Oct 2019 | A1 |
| 20190324438 | Cella et al. | Oct 2019 | A1 |
| 20190324439 | Cella et al. | Oct 2019 | A1 |
| 20190324440 | Cella et al. | Oct 2019 | A1 |
| 20190324441 | Cella et al. | Oct 2019 | A1 |
| 20190324442 | Cella et al. | Oct 2019 | A1 |
| 20190324443 | Cella et al. | Oct 2019 | A1 |
| 20190324444 | Cella et al. | Oct 2019 | A1 |
| 20190324772 | Fan et al. | Oct 2019 | A1 |
| 20190324867 | Tang | Oct 2019 | A1 |
| 20190324958 | Ow et al. | Oct 2019 | A1 |
| 20190324989 | Borochoff et al. | Oct 2019 | A1 |
| 20190324995 | Jakobsson | Oct 2019 | A1 |
| 20190325038 | Finlow-Bates | Oct 2019 | A1 |
| 20190325044 | Gray | Oct 2019 | A1 |
| 20190325048 | Watkins et al. | Oct 2019 | A1 |
| 20190325082 | Laine et al. | Oct 2019 | A1 |
| 20190325085 | Stein et al. | Oct 2019 | A1 |
| 20190325115 | Wilkinson et al. | Oct 2019 | A1 |
| 20190325148 | Chen et al. | Oct 2019 | A1 |
| 20190325161 | Zavesky et al. | Oct 2019 | A1 |
| 20190325162 | Gireesan et al. | Oct 2019 | A1 |
| 20190325165 | Rodriguez De Castro et al. | Oct 2019 | A1 |
| 20190325227 | Smith et al. | Oct 2019 | A1 |
| 20190325258 | Stein et al. | Oct 2019 | A1 |
| 20190325262 | Stein et al. | Oct 2019 | A1 |
| 20190325367 | Tovey et al. | Oct 2019 | A1 |
| 20190325402 | Kassemi et al. | Oct 2019 | A1 |
| 20190325403 | Srinivasan | Oct 2019 | A1 |
| 20190325405 | Melika et al. | Oct 2019 | A1 |
| 20190325406 | Melika et al. | Oct 2019 | A1 |
| 20190325407 | Zhou et al. | Oct 2019 | A1 |
| 20190325408 | Goroff et al. | Oct 2019 | A1 |
| 20190325420 | Gardner | Oct 2019 | A1 |
| 20190325430 | Cui et al. | Oct 2019 | A1 |
| 20190325431 | Mann | Oct 2019 | A1 |
| 20190325432 | Ow et al. | Oct 2019 | A1 |
| 20190325433 | Hirsch et al. | Oct 2019 | A1 |
| 20190325436 | Cheng et al. | Oct 2019 | A1 |
| 20190325447 | Studnitzer | Oct 2019 | A1 |
| 20190325452 | Farjami | Oct 2019 | A1 |
| 20190325468 | Nagarajan | Oct 2019 | A1 |
| 20190325473 | Swamidurai | Oct 2019 | A1 |
| 20190325478 | Forsblom | Oct 2019 | A1 |
| 20190325495 | Stark | Oct 2019 | A1 |
| 20190325498 | Clark | Oct 2019 | A1 |
| 20190325502 | Tovey et al. | Oct 2019 | A1 |
| 20190325507 | Rowley et al. | Oct 2019 | A1 |
| 20190325512 | Watson et al. | Oct 2019 | A1 |
| 20190325515 | Weisberger et al. | Oct 2019 | A1 |
| 20190325517 | Jayaram et al. | Oct 2019 | A1 |
| 20190325522 | Bathia et al. | Oct 2019 | A1 |
| 20190325523 | Demetry et al. | Oct 2019 | A1 |
| 20190325526 | Slavin | Oct 2019 | A1 |
| 20190325528 | Adjaoute | Oct 2019 | A1 |
| 20190325532 | Torrenegra et al. | Oct 2019 | A1 |
| 20190325541 | Simpson | Oct 2019 | A1 |
| 20190325642 | Martinet | Oct 2019 | A1 |
| 20190325684 | Hackmann | Oct 2019 | A1 |
| 20190325691 | Tovey et al. | Oct 2019 | A1 |
| 20190325692 | Tovey et al. | Oct 2019 | A1 |
| 20190325700 | Jayachandran | Oct 2019 | A1 |
| 20190325719 | Bender et al. | Oct 2019 | A1 |
| 20190325794 | Huang | Oct 2019 | A1 |
| 20190327077 | Mandal et al. | Oct 2019 | A1 |
| 20190327078 | Zhang et al. | Oct 2019 | A1 |
| 20190327079 | Nandakumar et al. | Oct 2019 | A1 |
| 20190327080 | Liu et al. | Oct 2019 | A1 |
| 20190327081 | Ow et al. | Oct 2019 | A1 |
| 20190327082 | Ow et al. | Oct 2019 | A1 |
| 20190327083 | De Filippi | Oct 2019 | A1 |
| 20190327084 | Oh et al. | Oct 2019 | A1 |
| 20190327088 | Camenisch et al. | Oct 2019 | A1 |
| 20190327090 | Innes et al. | Oct 2019 | A1 |
| 20190327094 | Kan et al. | Oct 2019 | A1 |
| 20190327097 | Tang | Oct 2019 | A1 |
| 20190327102 | Ashwood-Smith et al. | Oct 2019 | A1 |
| 20190327180 | Todd et al. | Oct 2019 | A1 |
| 20190327200 | Buckingham et al. | Oct 2019 | A1 |
| 20190327216 | Walters | Oct 2019 | A1 |
| 20190327218 | Altenhofen et al. | Oct 2019 | A1 |
| 20190327234 | Smith et al. | Oct 2019 | A1 |
| 20190327239 | Ferguson | Oct 2019 | A1 |
| 20190327259 | DeFelice | Oct 2019 | A1 |
| 20190327292 | Ziebell et al. | Oct 2019 | A1 |
| 20190327299 | Diamanti et al. | Oct 2019 | A1 |
| 20190327328 | Smith et al. | Oct 2019 | A1 |
| 20190327329 | Kouru et al. | Oct 2019 | A1 |
| 20190328227 | Eades et al. | Oct 2019 | A1 |
| 20190328457 | Villongco et al. | Oct 2019 | A1 |
| 20190329669 | Soeda et al. | Oct 2019 | A1 |
| 20190331505 | Probst et al. | Oct 2019 | A1 |
| 20190331702 | Menhardt et al. | Oct 2019 | A1 |
| 20190332430 | Qiu | Oct 2019 | A1 |
| 20190332431 | Bhageria et al. | Oct 2019 | A1 |
| 20190332552 | Rodriguez De Castro | Oct 2019 | A1 |
| 20190332586 | Wang | Oct 2019 | A1 |
| 20190332608 | Qiu | Oct 2019 | A1 |
| 20190332691 | Beadles et al. | Oct 2019 | A1 |
| 20190332702 | Manamohan et al. | Oct 2019 | A1 |
| 20190332718 | Keskar et al. | Oct 2019 | A1 |
| 20190332719 | Keskar | Oct 2019 | A1 |
| 20190332729 | Villongco | Oct 2019 | A1 |
| 20190332783 | Bhardwaj et al. | Oct 2019 | A1 |
| 20190332791 | Mahalle | Oct 2019 | A1 |
| 20190332807 | LaFever et al. | Oct 2019 | A1 |
| 20190332809 | Uhr et al. | Oct 2019 | A1 |
| 20190332810 | Uhr et al. | Oct 2019 | A1 |
| 20190332817 | Rodriguez De Castro | Oct 2019 | A1 |
| 20190332818 | Rodriguez De Castro | Oct 2019 | A1 |
| 20190332821 | Ebert et al. | Oct 2019 | A1 |
| 20190332921 | Rodriguez | Oct 2019 | A1 |
| 20190332931 | Montantes | Oct 2019 | A1 |
| 20190332955 | Manamohan et al. | Oct 2019 | A1 |
| 20190332966 | Gidney | Oct 2019 | A1 |
| 20190332974 | Karatekeli et al. | Oct 2019 | A1 |
| 20190332995 | Tseng | Oct 2019 | A1 |
| 20190333029 | Kravitz | Oct 2019 | A1 |
| 20190333030 | Ramasamy et al. | Oct 2019 | A1 |
| 20190333031 | Kravitz | Oct 2019 | A1 |
| 20190333032 | Jayachandran et al. | Oct 2019 | A1 |
| 20190333033 | Finlow-Bates | Oct 2019 | A1 |
| 20190333048 | DiCross et al. | Oct 2019 | A1 |
| 20190333051 | Brogger | Oct 2019 | A1 |
| 20190333054 | Cona et al. | Oct 2019 | A1 |
| 20190333056 | Wilkinson et al. | Oct 2019 | A1 |
| 20190333057 | Miller | Oct 2019 | A1 |
| 20190333058 | Hong et al. | Oct 2019 | A1 |
| 20190333059 | Fallah et al. | Oct 2019 | A1 |
| 20190333066 | Kassemi et al. | Oct 2019 | A1 |
| 20190333096 | Johnson et al. | Oct 2019 | A1 |
| 20190333097 | Sohum et al. | Oct 2019 | A1 |
| 20190333116 | Bhardwaj et al. | Oct 2019 | A1 |
| 20190333142 | Thomas | Oct 2019 | A1 |
| 20190333143 | Williams | Oct 2019 | A1 |
| 20190333146 | Nuti | Oct 2019 | A1 |
| 20190333147 | Oved et al. | Oct 2019 | A1 |
| 20190333148 | Nuti | Oct 2019 | A1 |
| 20190333149 | Kim | Oct 2019 | A1 |
| 20190333166 | Simpson | Oct 2019 | A1 |
| 20190333169 | Povar et al. | Oct 2019 | A1 |
| 20190333171 | Tokhtabaev | Oct 2019 | A1 |
| 20190333181 | Simpson | Oct 2019 | A1 |
| 20190333214 | Haneda et al. | Oct 2019 | A1 |
| 20190333304 | Flynn et al. | Oct 2019 | A1 |
| 20190334694 | Chen et al. | Oct 2019 | A1 |
| 20190334695 | Veeningen | Oct 2019 | A1 |
| 20190334697 | Winslow et al. | Oct 2019 | A1 |
| 20190334698 | Singh | Oct 2019 | A1 |
| 20190334699 | Tang | Oct 2019 | A1 |
| 20190334700 | Callan et al. | Oct 2019 | A1 |
| 20190334703 | Keskar | Oct 2019 | A1 |
| 20190334704 | Keskar | Oct 2019 | A1 |
| 20190334708 | Carpov et al. | Oct 2019 | A1 |
| 20190334711 | Rodriguez De Castro | Oct 2019 | A1 |
| 20190334715 | Gray | Oct 2019 | A1 |
| 20190334716 | Kocsis et al. | Oct 2019 | A1 |
| 20190334717 | Lelcuk et al. | Oct 2019 | A1 |
| 20190334719 | Naqvi et al. | Oct 2019 | A1 |
| 20190334723 | Endress et al. | Oct 2019 | A1 |
| 20190334724 | Anton et al. | Oct 2019 | A1 |
| 20190334725 | Zhuang et al. | Oct 2019 | A1 |
| 20190334726 | Kelly | Oct 2019 | A1 |
| 20190334728 | Zhang | Oct 2019 | A1 |
| 20190334730 | Endress et al. | Oct 2019 | A1 |
| 20190334859 | Kannan et al. | Oct 2019 | A1 |
| 20190334886 | Lelcuk et al. | Oct 2019 | A1 |
| 20190334904 | Lelcuk et al. | Oct 2019 | A1 |
| 20190334905 | Lelcuk et al. | Oct 2019 | A1 |
| 20190334912 | Sloane et al. | Oct 2019 | A1 |
| 20190334920 | Kelly | Oct 2019 | A1 |
| 20190334954 | Manamohan et al. | Oct 2019 | A1 |
| 20190334957 | Davis et al. | Oct 2019 | A1 |
| 20190334997 | Yang | Oct 2019 | A1 |
| 20190335551 | Williams et al. | Oct 2019 | A1 |
| 20190335715 | Hicks et al. | Nov 2019 | A1 |
| 20190336401 | Hsu | Nov 2019 | A1 |
| 20190338962 | Minnoy | Nov 2019 | A1 |
| 20190339668 | Biernat et al. | Nov 2019 | A1 |
| 20190339678 | Biernat et al. | Nov 2019 | A1 |
| 20190339684 | Cella et al. | Nov 2019 | A1 |
| 20190339685 | Cella et al. | Nov 2019 | A1 |
| 20190339686 | Cella et al. | Nov 2019 | A1 |
| 20190339687 | Cella et al. | Nov 2019 | A1 |
| 20190339688 | Cella et al. | Nov 2019 | A1 |
| 20190339712 | Williams et al. | Nov 2019 | A1 |
| 20190339756 | Lewis et al. | Nov 2019 | A1 |
| 20190339974 | Wallach | Nov 2019 | A1 |
| 20190339975 | Wallach | Nov 2019 | A1 |
| 20190339977 | Wallach | Nov 2019 | A1 |
| 20190339978 | Wallach | Nov 2019 | A1 |
| 20190340013 | Cella | Nov 2019 | A1 |
| 20190340042 | Li | Nov 2019 | A1 |
| 20190340110 | Kupitman et al. | Nov 2019 | A1 |
| 20190340136 | Irwin et al. | Nov 2019 | A1 |
| 20190340169 | Shima et al. | Nov 2019 | A1 |
| 20190340170 | Pierce et al. | Nov 2019 | A1 |
| 20190340216 | Dutta et al. | Nov 2019 | A1 |
| 20190340264 | Yu et al. | Nov 2019 | A1 |
| 20190340266 | Vo et al. | Nov 2019 | A1 |
| 20190340267 | Vo et al. | Nov 2019 | A1 |
| 20190340269 | Biernat et al. | Nov 2019 | A1 |
| 20190340306 | Harrison et al. | Nov 2019 | A1 |
| 20190340350 | Campbell | Nov 2019 | A1 |
| 20190340352 | Peeters et al. | Nov 2019 | A1 |
| 20190340361 | Daniel et al. | Nov 2019 | A1 |
| 20190340362 | Wright et al. | Nov 2019 | A1 |
| 20190340369 | Hadi | Nov 2019 | A1 |
| 20190340371 | Williams | Nov 2019 | A1 |
| 20190340379 | Beecham | Nov 2019 | A1 |
| 20190340467 | Cella | Nov 2019 | A1 |
| 20190340575 | Kankaria et al. | Nov 2019 | A1 |
| 20190340584 | Arora et al. | Nov 2019 | A1 |
| 20190340586 | Sheng et al. | Nov 2019 | A1 |
| 20190340587 | Batton | Nov 2019 | A1 |
| 20190340588 | Haldenby et al. | Nov 2019 | A1 |
| 20190340594 | Peterson | Nov 2019 | A1 |
| 20190340597 | Carlyle et al. | Nov 2019 | A1 |
| 20190340600 | Hudson et al. | Nov 2019 | A1 |
| 20190340605 | Lewis et al. | Nov 2019 | A1 |
| 20190340607 | Lynn et al. | Nov 2019 | A1 |
| 20190340608 | Lindsay et al. | Nov 2019 | A1 |
| 20190340609 | Mayadas et al. | Nov 2019 | A1 |
| 20190340619 | Leong et al. | Nov 2019 | A1 |
| 20190340623 | Rivkind et al. | Nov 2019 | A1 |
| 20190340627 | Cella | Nov 2019 | A1 |
| 20190340645 | Cella | Nov 2019 | A1 |
| 20190340673 | Noviello et al. | Nov 2019 | A1 |
| 20190340683 | Kundu | Nov 2019 | A1 |
| 20190340685 | Wade et al. | Nov 2019 | A1 |
| 20190340686 | Cella | Nov 2019 | A1 |
| 20190340689 | Gordon et al. | Nov 2019 | A1 |
| 20190340703 | West et al. | Nov 2019 | A1 |
| 20190340707 | Cella | Nov 2019 | A1 |
| 20190340715 | Cella | Nov 2019 | A1 |
| 20190340716 | Cella | Nov 2019 | A1 |
| 20190340885 | Kehoe | Nov 2019 | A1 |
| 20190340888 | Hartl | Nov 2019 | A1 |
| 20190340906 | Williams | Nov 2019 | A1 |
| 20190340946 | Elmessiry et al. | Nov 2019 | A1 |
| 20190341134 | Shah | Nov 2019 | A1 |
| 20190342073 | Dai | Nov 2019 | A1 |
| 20190342074 | Housholder et al. | Nov 2019 | A1 |
| 20190342076 | O'Connor | Nov 2019 | A1 |
| 20190342077 | McMurdie et al. | Nov 2019 | A1 |
| 20190342078 | Li | Nov 2019 | A1 |
| 20190342084 | Mehedy et al. | Nov 2019 | A1 |
| 20190342085 | Kube et al. | Nov 2019 | A1 |
| 20190342087 | Rodriguez De Castro | Nov 2019 | A1 |
| 20190342094 | Davis | Nov 2019 | A1 |
| 20190342095 | Simons | Nov 2019 | A1 |
| 20190342099 | Rodriguez De Castro | Nov 2019 | A1 |
| 20190342143 | Lin | Nov 2019 | A1 |
| 20190342149 | Guo et al. | Nov 2019 | A1 |
| 20190342270 | Laine et al. | Nov 2019 | A1 |
| 20190342290 | Mittal et al. | Nov 2019 | A1 |
| 20190342295 | Peterson | Nov 2019 | A1 |
| 20190342336 | Finkelstein et al. | Nov 2019 | A1 |
| 20190342344 | Anton et al. | Nov 2019 | A1 |
| 20190342382 | Tang et al. | Nov 2019 | A1 |
| 20190342407 | Ma et al. | Nov 2019 | A1 |
| 20190342415 | Lu | Nov 2019 | A1 |
| 20190342422 | Li | Nov 2019 | A1 |
| 20190342528 | Broaddus | Nov 2019 | A1 |
| 20190342731 | Krishnamoorth et al. | Nov 2019 | A1 |
| 20190343317 | Cantrell et al. | Nov 2019 | A1 |
| 20190343429 | Elhawary et al. | Nov 2019 | A1 |
| 20190347105 | Cella | Nov 2019 | A1 |
| 20190347243 | Wilkinson et al. | Nov 2019 | A1 |
| 20190347268 | Griffith | Nov 2019 | A1 |
| 20190347290 | Yang | Nov 2019 | A1 |
| 20190347347 | Griffith | Nov 2019 | A1 |
| 20190347368 | Duff et al. | Nov 2019 | A1 |
| 20190347397 | Cramer | Nov 2019 | A1 |
| 20190347398 | Cramer | Nov 2019 | A1 |
| 20190347399 | Cramer | Nov 2019 | A1 |
| 20190347420 | Schultz et al. | Nov 2019 | A1 |
| 20190347433 | Chakravorty et al. | Nov 2019 | A1 |
| 20190347442 | Marlin et al. | Nov 2019 | A1 |
| 20190347444 | Lowagie | Nov 2019 | A1 |
| 20190347601 | Aborishade | Nov 2019 | A1 |
| 20190347605 | Wan et al. | Nov 2019 | A1 |
| 20190347624 | Pustizzi | Nov 2019 | A1 |
| 20190347625 | Neron | Nov 2019 | A1 |
| 20190347626 | Wullschleger et al. | Nov 2019 | A1 |
| 20190347627 | Lin et al. | Nov 2019 | A1 |
| 20190347628 | Al-Naji et al. | Nov 2019 | A1 |
| 20190347651 | Moreno | Nov 2019 | A1 |
| 20190347652 | Johnson | Nov 2019 | A1 |
| 20190347653 | Lu et al. | Nov 2019 | A1 |
| 20190347654 | Lu et al. | Nov 2019 | A1 |
| 20190347655 | Sewell | Nov 2019 | A1 |
| 20190347656 | Lu et al. | Nov 2019 | A1 |
| 20190347657 | Guo et al. | Nov 2019 | A1 |
| 20190347658 | Haimes et al. | Nov 2019 | A1 |
| 20190347660 | Wilkinson et al. | Nov 2019 | A1 |
| 20190347661 | Grenader et al. | Nov 2019 | A1 |
| 20190347663 | Li | Nov 2019 | A1 |
| 20190347685 | Glazier et al. | Nov 2019 | A1 |
| 20190347699 | Bradley et al. | Nov 2019 | A1 |
| 20190347724 | Krupp | Nov 2019 | A1 |
| 20190347725 | de Jong | Nov 2019 | A1 |
| 20190347738 | Ledesma et al. | Nov 2019 | A1 |
| 20190348158 | Livesay et al. | Nov 2019 | A1 |
| 20190348174 | Spirer | Nov 2019 | A1 |
| 20190349185 | Kim et al. | Nov 2019 | A1 |
| 20190349188 | Guo et al. | Nov 2019 | A1 |
| 20190349190 | Smith et al. | Nov 2019 | A1 |
| 20190349191 | Soriente et al. | Nov 2019 | A1 |
| 20190349195 | Finlow-Bates | Nov 2019 | A1 |
| 20190349199 | Wang et al. | Nov 2019 | A1 |
| 20190349200 | Wang et al. | Nov 2019 | A1 |
| 20190349201 | Fuerstner | Nov 2019 | A1 |
| 20190349203 | Scherrer et al. | Nov 2019 | A1 |
| 20190349205 | Brady et al. | Nov 2019 | A1 |
| 20190349254 | Nolan et al. | Nov 2019 | A1 |
| 20190349261 | Smith et al. | Nov 2019 | A1 |
| 20190349321 | Cai et al. | Nov 2019 | A1 |
| 20190349343 | Gollogly | Nov 2019 | A1 |
| 20190349346 | Curtis et al. | Nov 2019 | A1 |
| 20190349347 | Curtis et al. | Nov 2019 | A1 |
| 20190349356 | McElwee et al. | Nov 2019 | A1 |
| 20190349361 | Brown et al. | Nov 2019 | A1 |
| 20190349371 | Smith et al. | Nov 2019 | A1 |
| 20190349372 | Smith et al. | Nov 2019 | A1 |
| 20190349426 | Smith et al. | Nov 2019 | A1 |
| 20190349433 | Smith et al. | Nov 2019 | A1 |
| 20190349628 | Cholas et al. | Nov 2019 | A1 |
| 20190349680 | Sculley et al. | Nov 2019 | A1 |
| 20190349708 | Jones | Nov 2019 | A1 |
| 20190349733 | Nolan et al. | Nov 2019 | A1 |
| 20190349794 | Tavares Coutinho et al. | Nov 2019 | A1 |
| 20190351694 | Trexler et al. | Nov 2019 | A1 |
| 20190353139 | Sheldon-Coulson et al. | Nov 2019 | A1 |
| 20190353629 | Jung et al. | Nov 2019 | A1 |
| 20190353685 | Almeida Cavoto et al. | Nov 2019 | A1 |
| 20190353709 | Kaisers | Nov 2019 | A1 |
| 20190354076 | Henson et al. | Nov 2019 | A1 |
| 20190354170 | Rosedale | Nov 2019 | A1 |
| 20190354189 | Rosedale | Nov 2019 | A1 |
| 20190354191 | Reynolds | Nov 2019 | A1 |
| 20190354374 | Cella | Nov 2019 | A1 |
| 20190354397 | Goel et al. | Nov 2019 | A1 |
| 20190354398 | Aggarwal et al. | Nov 2019 | A1 |
| 20190354450 | Grunwald et al. | Nov 2019 | A1 |
| 20190354518 | Zochowski | Nov 2019 | A1 |
| 20190354523 | Kheterpal et al. | Nov 2019 | A1 |
| 20190354606 | Snow | Nov 2019 | A1 |
| 20190354607 | Snow | Nov 2019 | A1 |
| 20190354611 | Snow | Nov 2019 | A1 |
| 20190354614 | Chui et al. | Nov 2019 | A1 |
| 20190354628 | Grunwald et al. | Nov 2019 | A1 |
| 20190354693 | Yoon et al. | Nov 2019 | A1 |
| 20190354694 | Azoulay | Nov 2019 | A1 |
| 20190354708 | Fisher et al. | Nov 2019 | A1 |
| 20190354723 | Dassenno | Nov 2019 | A1 |
| 20190354724 | Lowagie | Nov 2019 | A1 |
| 20190354725 | Lowagie | Nov 2019 | A1 |
| 20190354771 | Kleinrock et al. | Nov 2019 | A1 |
| 20190354829 | McDonald et al. | Nov 2019 | A1 |
| 20190354887 | Subramanian et al. | Nov 2019 | A1 |
| 20190354922 | Berti et al. | Nov 2019 | A1 |
| 20190354943 | Mulye et al. | Nov 2019 | A1 |
| 20190354944 | Russinovich | Nov 2019 | A1 |
| 20190354945 | Mahajan et al. | Nov 2019 | A1 |
| 20190354962 | Spector | Nov 2019 | A1 |
| 20190354963 | Di Iorio et al. | Nov 2019 | A1 |
| 20190354964 | Snow | Nov 2019 | A1 |
| 20190354966 | Himura et al. | Nov 2019 | A1 |
| 20190354967 | Lee et al. | Nov 2019 | A1 |
| 20190354968 | Sato et al. | Nov 2019 | A1 |
| 20190354969 | Spector et al. | Nov 2019 | A1 |
| 20190354970 | Di Iorio et al. | Nov 2019 | A1 |
| 20190354971 | Ettensohn et al. | Nov 2019 | A1 |
| 20190354972 | Di Nicola | Nov 2019 | A1 |
| 20190354975 | Wettan | Nov 2019 | A1 |
| 20190354976 | Vincent | Nov 2019 | A1 |
| 20190354977 | Tang | Nov 2019 | A1 |
| 20190354989 | Saket et al. | Nov 2019 | A1 |
| 20190355005 | Kappagantu et al. | Nov 2019 | A1 |
| 20190355025 | Yang | Nov 2019 | A1 |
| 20190355031 | Cella | Nov 2019 | A1 |
| 20190355053 | Hwang | Nov 2019 | A1 |
| 20190355057 | Phillips et al. | Nov 2019 | A1 |
| 20190355059 | Liberman et al. | Nov 2019 | A1 |
| 20190355060 | Collins et al. | Nov 2019 | A1 |
| 20190355076 | Marcinkowski et al. | Nov 2019 | A1 |
| 20190355113 | Wirch et al. | Nov 2019 | A1 |
| 20190355450 | Altstadter et al. | Nov 2019 | A1 |
| 20190355460 | Mann | Nov 2019 | A1 |
| 20190355472 | Kutzko | Nov 2019 | A1 |
| 20190355483 | Smurro | Nov 2019 | A1 |
| 20190356164 | Ghaemi et al. | Nov 2019 | A1 |
| 20190356467 | Vincent | Nov 2019 | A1 |
| 20190356469 | Deshpande et al. | Nov 2019 | A1 |
| 20190356470 | Deshpande et al. | Nov 2019 | A1 |
| 20190356471 | Vaughn et al. | Nov 2019 | A1 |
| 20190356472 | Allen | Nov 2019 | A1 |
| 20190356473 | Rosenoer et al. | Nov 2019 | A1 |
| 20190356475 | Resch et al. | Nov 2019 | A1 |
| 20190356481 | Spector et al. | Nov 2019 | A1 |
| 20190356484 | Ettensohn et al. | Nov 2019 | A1 |
| 20190356491 | Herder et al. | Nov 2019 | A1 |
| 20190356493 | Fisher et al. | Nov 2019 | A1 |
| 20190356539 | Soon-Shiong et al. | Nov 2019 | A1 |
| 20190356609 | Grunwald et al. | Nov 2019 | A1 |
| 20190356638 | Filter et al. | Nov 2019 | A1 |
| 20190356641 | Isaacson et al. | Nov 2019 | A1 |
| 20190356657 | Andrade | Nov 2019 | A1 |
| 20190356658 | Arana et al. | Nov 2019 | A1 |
| 20190356662 | Scott et al. | Nov 2019 | A1 |
| 20190356672 | Bondugula et al. | Nov 2019 | A1 |
| 20190356674 | Irazabal et al. | Nov 2019 | A1 |
| 20190356680 | Dogu et al. | Nov 2019 | A1 |
| 20190356733 | Snow | Nov 2019 | A1 |
| 20190356736 | Narayanaswamy et al. | Nov 2019 | A1 |
| 20190356745 | Rosedale | Nov 2019 | A1 |
| 20190356775 | Patel et al. | Nov 2019 | A1 |
| 20190356945 | Ellis et al. | Nov 2019 | A1 |
| 20190357049 | Tali et al. | Nov 2019 | A1 |
| 20190358428 | Wang | Nov 2019 | A1 |
| 20190358515 | Tran et al. | Nov 2019 | A1 |
| 20190358543 | Turner et al. | Nov 2019 | A1 |
| 20190359056 | Wilson et al. | Nov 2019 | A1 |
| 20190361626 | East | Nov 2019 | A1 |
| 20190361663 | De Angelis et al. | Nov 2019 | A1 |
| 20190361697 | Hu et al. | Nov 2019 | A1 |
| 20190361731 | Qiu | Nov 2019 | A1 |
| 20190361842 | Wood et al. | Nov 2019 | A1 |
| 20190361867 | Nilsson et al. | Nov 2019 | A1 |
| 20190361869 | Krabbenhoft et al. | Nov 2019 | A1 |
| 20190361874 | Fukuchi et al. | Nov 2019 | A1 |
| 20190361891 | Griffith et al. | Nov 2019 | A1 |
| 20190361917 | Tran et al. | Nov 2019 | A1 |
| 20190361992 | Kaguma et al. | Nov 2019 | A1 |
| 20190362054 | Diehl | Nov 2019 | A1 |
| 20190362068 | Wang | Nov 2019 | A1 |
| 20190362287 | Achkir | Nov 2019 | A1 |
| 20190362305 | Johnson | Nov 2019 | A1 |
| 20190362323 | Singleton | Nov 2019 | A1 |
| 20190362340 | Strong et al. | Nov 2019 | A1 |
| 20190362348 | Wong et al. | Nov 2019 | A1 |
| 20190362352 | Kumawat et al. | Nov 2019 | A1 |
| 20190362361 | Irazabal et al. | Nov 2019 | A1 |
| 20190362376 | Newell et al. | Nov 2019 | A1 |
| 20190362388 | Bugga et al. | Nov 2019 | A1 |
| 20190362389 | Turner et al. | Nov 2019 | A1 |
| 20190362392 | Kim | Nov 2019 | A1 |
| 20190362400 | Onizuka | Nov 2019 | A1 |
| 20190362430 | Jass | Nov 2019 | A1 |
| 20190362443 | McCoy et al. | Nov 2019 | A1 |
| 20190362446 | Navarro | Nov 2019 | A1 |
| 20190362457 | Mozarkar | Nov 2019 | A1 |
| 20190362616 | Hermann et al. | Nov 2019 | A1 |
| 20190362716 | Tran et al. | Nov 2019 | A1 |
| 20190362826 | Viskovich et al. | Nov 2019 | A1 |
| 20190362828 | Laxer | Nov 2019 | A1 |
| 20190363854 | Wang et al. | Nov 2019 | A1 |
| 20190363870 | Wagner | Nov 2019 | A1 |
| 20190363871 | Cheon et al. | Nov 2019 | A1 |
| 20190363872 | Shim et al. | Nov 2019 | A1 |
| 20190363873 | Fry et al. | Nov 2019 | A1 |
| 20190363874 | Shirley et al. | Nov 2019 | A1 |
| 20190363875 | Iseminger | Nov 2019 | A1 |
| 20190363877 | Figueira | Nov 2019 | A1 |
| 20190363878 | Sato et al. | Nov 2019 | A1 |
| 20190363881 | Bakalis et al. | Nov 2019 | A1 |
| 20190363882 | Levy | Nov 2019 | A1 |
| 20190363883 | Rao et al. | Nov 2019 | A1 |
| 20190363884 | Johnson | Nov 2019 | A1 |
| 20190363889 | Wang | Nov 2019 | A1 |
| 20190363890 | Johnson | Nov 2019 | A1 |
| 20190363892 | Wang | Nov 2019 | A1 |
| 20190363896 | Finlow-Bates | Nov 2019 | A1 |
| 20190363905 | Yarvis et al. | Nov 2019 | A1 |
| 20190363938 | Liebinger Portela et al. | Nov 2019 | A1 |
| 20190364021 | Mitchell | Nov 2019 | A1 |
| 20190364045 | Armknecht et al. | Nov 2019 | A1 |
| 20190364046 | Kurian et al. | Nov 2019 | A1 |
| 20190364055 | Ford | Nov 2019 | A1 |
| 20190364056 | Ford | Nov 2019 | A1 |
| 20190364057 | Hazay et al. | Nov 2019 | A1 |
| 20190364426 | Muthukrishnan et al. | Nov 2019 | A1 |
| 20190364698 | Johnson et al. | Nov 2019 | A1 |
| 20190365014 | Andon | Dec 2019 | A1 |
| 20190365016 | Andon et al. | Dec 2019 | A1 |
| 20190365063 | Nyfeler et al. | Dec 2019 | A1 |
| 20190365282 | Gibson | Dec 2019 | A1 |
| 20190365592 | Norton et al. | Dec 2019 | A1 |
| 20190366475 | Scarselli et al. | Dec 2019 | A1 |
| 20190368233 | Gengler et al. | Dec 2019 | A1 |
| 20190369644 | Goudy et al. | Dec 2019 | A1 |
| 20190369721 | Rajasingham | Dec 2019 | A1 |
| 20190370012 | Sears et al. | Dec 2019 | A1 |
| 20190370058 | Gupta et al. | Dec 2019 | A1 |
| 20190370223 | Yang et al. | Dec 2019 | A1 |
| 20190370241 | Miraldo et al. | Dec 2019 | A1 |
| 20190370250 | Tipton et al. | Dec 2019 | A1 |
| 20190370286 | Bertsch et al. | Dec 2019 | A1 |
| 20190370330 | Chen et al. | Dec 2019 | A1 |
| 20190370334 | Bhowmick et al. | Dec 2019 | A1 |
| 20190370358 | Nation et al. | Dec 2019 | A1 |
| 20190370366 | Scott et al. | Dec 2019 | A1 |
| 20190370446 | Davis et al. | Dec 2019 | A1 |
| 20190370479 | Uhr et al. | Dec 2019 | A1 |
| 20190370484 | Klein | Dec 2019 | A1 |
| 20190370486 | Wang et al. | Dec 2019 | A1 |
| 20190370500 | Lee et al. | Dec 2019 | A1 |
| 20190370504 | Edwardsson | Dec 2019 | A1 |
| 20190370624 | Khoche | Dec 2019 | A1 |
| 20190370634 | Ferreira Moreno et al. | Dec 2019 | A1 |
| 20190370652 | Shen et al. | Dec 2019 | A1 |
| 20190370732 | Luzada et al. | Dec 2019 | A1 |
| 20190370740 | Brow | Dec 2019 | A1 |
| 20190370760 | Kundu et al. | Dec 2019 | A1 |
| 20190370761 | Iwanami | Dec 2019 | A1 |
| 20190370762 | Byington et al. | Dec 2019 | A1 |
| 20190370788 | Aronson | Dec 2019 | A1 |
| 20190370789 | McCallum | Dec 2019 | A1 |
| 20190370791 | Stark et al. | Dec 2019 | A1 |
| 20190370792 | Lam | Dec 2019 | A1 |
| 20190370793 | Zhu et al. | Dec 2019 | A1 |
| 20190370797 | Jevans et al. | Dec 2019 | A1 |
| 20190370798 | Hu et al. | Dec 2019 | A1 |
| 20190370799 | Vivas et al. | Dec 2019 | A1 |
| 20190370806 | Wang et al. | Dec 2019 | A1 |
| 20190370807 | Hu et al. | Dec 2019 | A1 |
| 20190370808 | Jackman et al. | Dec 2019 | A1 |
| 20190370809 | Hu et al. | Dec 2019 | A1 |
| 20190370810 | Hu et al. | Dec 2019 | A1 |
| 20190370811 | Zhang et al. | Dec 2019 | A1 |
| 20190370813 | Bravick et al. | Dec 2019 | A1 |
| 20190370816 | Hu | Dec 2019 | A1 |
| 20190370839 | Fahmie et al. | Dec 2019 | A1 |
| 20190370842 | Boyapally et al. | Dec 2019 | A1 |
| 20190370847 | Khan | Dec 2019 | A1 |
| 20190370855 | Boyapally et al. | Dec 2019 | A1 |
| 20190370857 | Boyapally et al. | Dec 2019 | A1 |
| 20190370866 | Lawbaugh et al. | Dec 2019 | A1 |
| 20190370905 | Hu | Dec 2019 | A1 |
| 20190370919 | Woodrow et al. | Dec 2019 | A1 |
| 20190370925 | Edwards | Dec 2019 | A1 |
| 20190371102 | Prostko et al. | Dec 2019 | A1 |
| 20190371106 | Kaye | Dec 2019 | A1 |
| 20190371117 | Hiten et al. | Dec 2019 | A1 |
| 20190371129 | Hall | Dec 2019 | A1 |
| 20190371176 | Montemurro et al. | Dec 2019 | A1 |
| 20190371335 | Shastry et al. | Dec 2019 | A1 |
| 20190371457 | Paffel et al. | Dec 2019 | A1 |
| 20190372345 | Bain et al. | Dec 2019 | A1 |
| 20190372754 | Gou et al. | Dec 2019 | A1 |
| 20190372755 | Tadie | Dec 2019 | A1 |
| 20190372756 | Kim et al. | Dec 2019 | A1 |
| 20190372759 | Rix | Dec 2019 | A1 |
| 20190372760 | Zheng et al. | Dec 2019 | A1 |
| 20190372762 | Shainski et al. | Dec 2019 | A1 |
| 20190372763 | Yang et al. | Dec 2019 | A1 |
| 20190372765 | Tegeder et al. | Dec 2019 | A1 |
| 20190372768 | Veeningen | Dec 2019 | A1 |
| 20190372769 | Fisher et al. | Dec 2019 | A1 |
| 20190372770 | Xu et al. | Dec 2019 | A1 |
| 20190372772 | Novotny et al. | Dec 2019 | A1 |
| 20190372773 | Bertsch et al. | Dec 2019 | A1 |
| 20190372776 | Kroneisen et al. | Dec 2019 | A1 |
| 20190372778 | Palaniappan et al. | Dec 2019 | A1 |
| 20190372779 | Monica et al. | Dec 2019 | A1 |
| 20190372781 | Ra et al. | Dec 2019 | A1 |
| 20190372786 | Ra et al. | Dec 2019 | A1 |
| 20190372825 | Suga | Dec 2019 | A1 |
| 20190372834 | Patil et al. | Dec 2019 | A1 |
| 20190372882 | Imai | Dec 2019 | A1 |
| 20190372931 | Irwan et al. | Dec 2019 | A1 |
| 20190372938 | Pasdar | Dec 2019 | A1 |
| 20190372950 | McClure | Dec 2019 | A1 |
| 20190372956 | Breu | Dec 2019 | A1 |
| 20190372965 | Kravitz et al. | Dec 2019 | A1 |
| 20190372985 | Zamora Duran et al. | Dec 2019 | A1 |
| 20190372987 | He et al. | Dec 2019 | A1 |
| 20190373015 | Kozloski et al. | Dec 2019 | A1 |
| 20190373047 | Ziebell et al. | Dec 2019 | A1 |
| 20190373051 | Binotto et al. | Dec 2019 | A1 |
| 20190373134 | Arakawa | Dec 2019 | A1 |
| 20190373136 | Diaz et al. | Dec 2019 | A1 |
| 20190373137 | Krukar et al. | Dec 2019 | A1 |
| 20190373339 | Bradley et al. | Dec 2019 | A1 |
| 20190373459 | Barkan | Dec 2019 | A1 |
| 20190373472 | Smith et al. | Dec 2019 | A1 |
| 20190373521 | Crawford | Dec 2019 | A1 |
| 20190373862 | Hummer et al. | Dec 2019 | A1 |
| 20190375373 | Pepe et al. | Dec 2019 | A1 |
| 20190377029 | Shiiyama et al. | Dec 2019 | A1 |
| 20190377336 | Avery et al. | Dec 2019 | A1 |
| 20190377394 | Klaba | Dec 2019 | A1 |
| 20190377461 | Akhanov et al. | Dec 2019 | A1 |
| 20190377617 | Jacobs et al. | Dec 2019 | A1 |
| 20190377645 | Abraham et al. | Dec 2019 | A1 |
| 20190377648 | Abraham et al. | Dec 2019 | A1 |
| 20190377660 | Huang | Dec 2019 | A1 |
| 20190377712 | Miller et al. | Dec 2019 | A1 |
| 20190377722 | Stefferud et al. | Dec 2019 | A1 |
| 20190377724 | Pennington et al. | Dec 2019 | A1 |
| 20190377805 | Chilakamarri et al. | Dec 2019 | A1 |
| 20190377806 | Padmanabhan et al. | Dec 2019 | A1 |
| 20190377811 | Aleksander et al. | Dec 2019 | A1 |
| 20190377889 | Mertens et al. | Dec 2019 | A1 |
| 20190377899 | Stecher | Dec 2019 | A1 |
| 20190377904 | Sinha et al. | Dec 2019 | A1 |
| 20190378024 | Singh et al. | Dec 2019 | A1 |
| 20190378069 | Deshpande et al. | Dec 2019 | A1 |
| 20190378073 | Lopez et al. | Dec 2019 | A1 |
| 20190378080 | Srinivasan et al. | Dec 2019 | A1 |
| 20190378081 | Swartz et al. | Dec 2019 | A1 |
| 20190378092 | Alexander et al. | Dec 2019 | A1 |
| 20190378094 | Quinn | Dec 2019 | A1 |
| 20190378096 | Bielak, Sr. | Dec 2019 | A1 |
| 20190378098 | Lam et al. | Dec 2019 | A1 |
| 20190378106 | Bonestell et al. | Dec 2019 | A1 |
| 20190378119 | Hyuga et al. | Dec 2019 | A1 |
| 20190378121 | Marshall et al. | Dec 2019 | A1 |
| 20190378122 | Furukawa | Dec 2019 | A1 |
| 20190378127 | Dudar et al. | Dec 2019 | A1 |
| 20190378128 | Moore et al. | Dec 2019 | A1 |
| 20190378133 | Deshpande et al. | Dec 2019 | A1 |
| 20190378134 | Asari | Dec 2019 | A1 |
| 20190378136 | Efraim et al. | Dec 2019 | A1 |
| 20190378137 | Honey et al. | Dec 2019 | A1 |
| 20190378139 | Stribady et al. | Dec 2019 | A1 |
| 20190378140 | Sarkissian et al. | Dec 2019 | A1 |
| 20190378142 | Darnell et al. | Dec 2019 | A1 |
| 20190378152 | Zhang et al. | Dec 2019 | A1 |
| 20190378153 | Eich et al. | Dec 2019 | A1 |
| 20190378162 | Goldberg et al. | Dec 2019 | A1 |
| 20190378164 | Eich et al. | Dec 2019 | A1 |
| 20190378165 | Frutschy | Dec 2019 | A1 |
| 20190378166 | Eich et al. | Dec 2019 | A1 |
| 20190378176 | O'Brien | Dec 2019 | A1 |
| 20190378192 | Fox | Dec 2019 | A1 |
| 20190378207 | Dibner-Dunlap et al. | Dec 2019 | A1 |
| 20190378220 | Ibrahim | Dec 2019 | A1 |
| 20190378224 | Krych | Dec 2019 | A1 |
| 20190378227 | Vanzetta | Dec 2019 | A1 |
| 20190378230 | Lawrenson et al. | Dec 2019 | A1 |
| 20190378352 | Dey et al. | Dec 2019 | A1 |
| 20190378386 | Bender et al. | Dec 2019 | A1 |
| 20190378418 | Menadue | Dec 2019 | A1 |
| 20190378619 | Meyer et al. | Dec 2019 | A1 |
| 20190379529 | Meyer et al. | Dec 2019 | A1 |
| 20190379530 | Suthar et al. | Dec 2019 | A1 |
| 20190379531 | Aleksander et al. | Dec 2019 | A1 |
| 20190379538 | Oh et al. | Dec 2019 | A1 |
| 20190379543 | Sethi et al. | Dec 2019 | A1 |
| 20190379544 | Suthar et al. | Dec 2019 | A1 |
| 20190379545 | Wong | Dec 2019 | A1 |
| 20190379546 | Chang et al. | Dec 2019 | A1 |
| 20190379619 | Pierini et al. | Dec 2019 | A1 |
| 20190379639 | Corning | Dec 2019 | A1 |
| 20190379642 | Simons et al. | Dec 2019 | A1 |
| 20190379646 | Mandal et al. | Dec 2019 | A1 |
| 20190379649 | Fuchs et al. | Dec 2019 | A1 |
| 20190379653 | Mead | Dec 2019 | A1 |
| 20190379660 | Thirumavalava | Dec 2019 | A1 |
| 20190379664 | Suthar et al. | Dec 2019 | A1 |
| 20190379673 | Coonrod | Dec 2019 | A1 |
| 20190379699 | Katragadda et al. | Dec 2019 | A1 |
| 20190379724 | Roche, Jr. | Dec 2019 | A1 |
| 20190379727 | Kurian et al. | Dec 2019 | A1 |
| 20190379754 | Krishnaswamy | Dec 2019 | A1 |
| 20190379761 | Acosta et al. | Dec 2019 | A1 |
| 20190379768 | Amicangioli et al. | Dec 2019 | A1 |
| 20190379797 | Sahagun | Dec 2019 | A1 |
| 20190379925 | Wexler et al. | Dec 2019 | A1 |
| 20190380030 | Suthar et al. | Dec 2019 | A1 |
| 20190380031 | Suthar et al. | Dec 2019 | A1 |
| 20190380032 | Newman et al. | Dec 2019 | A1 |
| 20190381242 | Ambrosina et al. | Dec 2019 | A1 |
| 20190381654 | Oleynik | Dec 2019 | A1 |
| 20190384250 | Cella et al. | Dec 2019 | A1 |
| 20190384263 | Kono et al. | Dec 2019 | A1 |
| 20190384385 | Idris et al. | Dec 2019 | A1 |
| 20190384587 | Rao et al. | Dec 2019 | A1 |
| 20190384593 | Michiyama et al. | Dec 2019 | A1 |
| 20190384594 | Michiyama et al. | Dec 2019 | A1 |
| 20190384595 | Mills | Dec 2019 | A1 |
| 20190384627 | De Caro et al. | Dec 2019 | A1 |
| 20190384639 | Gustafsson et al. | Dec 2019 | A1 |
| 20190384686 | Estes et al. | Dec 2019 | A1 |
| 20190384748 | Roennow et al. | Dec 2019 | A1 |
| 20190384832 | Estes et al. | Dec 2019 | A1 |
| 20190384833 | Estes et al. | Dec 2019 | A1 |
| 20190384834 | Nelluri et al. | Dec 2019 | A1 |
| 20190384839 | Esposito et al. | Dec 2019 | A1 |
| 20190384842 | Rao | Dec 2019 | A1 |
| 20190384892 | Holland et al. | Dec 2019 | A1 |
| 20190384895 | Jin et al. | Dec 2019 | A1 |
| 20190384927 | Bhatnagar et al. | Dec 2019 | A1 |
| 20190384932 | Pratt et al. | Dec 2019 | A1 |
| 20190384933 | Lebel et al. | Dec 2019 | A1 |
| 20190384935 | Miller | Dec 2019 | A1 |
| 20190384968 | Brown et al. | Dec 2019 | A1 |
| 20190385096 | Ibrahim | Dec 2019 | A1 |
| 20190385100 | Zaman et al. | Dec 2019 | A1 |
| 20190385115 | Biermann et al. | Dec 2019 | A1 |
| 20190385120 | Yund et al. | Dec 2019 | A1 |
| 20190385130 | Mossoba et al. | Dec 2019 | A1 |
| 20190385136 | Blagov et al. | Dec 2019 | A1 |
| 20190385153 | Cui et al. | Dec 2019 | A1 |
| 20190385154 | Cui et al. | Dec 2019 | A1 |
| 20190385156 | Liu | Dec 2019 | A1 |
| 20190385157 | Mallela et al. | Dec 2019 | A1 |
| 20190385160 | Safak et al. | Dec 2019 | A1 |
| 20190385162 | Zhang et al. | Dec 2019 | A1 |
| 20190385165 | Castinado et al. | Dec 2019 | A1 |
| 20190385167 | Subhedar et al. | Dec 2019 | A1 |
| 20190385170 | Arrabothu et al. | Dec 2019 | A1 |
| 20190385172 | Jayaram et al. | Dec 2019 | A1 |
| 20190385175 | Chamberlain et al. | Dec 2019 | A1 |
| 20190385182 | Price et al. | Dec 2019 | A1 |
| 20190385183 | Ryu | Dec 2019 | A1 |
| 20190385215 | Ferenczi et al. | Dec 2019 | A1 |
| 20190385223 | Sharma | Dec 2019 | A1 |
| 20190385229 | Leonard et al. | Dec 2019 | A1 |
| 20190385236 | McConnell et al. | Dec 2019 | A1 |
| 20190385240 | Lee et al. | Dec 2019 | A1 |
| 20190385244 | Stelmar Netto et al. | Dec 2019 | A1 |
| 20190385256 | Nahamoo et al. | Dec 2019 | A1 |
| 20190385269 | Zachary | Dec 2019 | A1 |
| 20190385407 | Hiten et al. | Dec 2019 | A1 |
| 20190385711 | Shriberg et al. | Dec 2019 | A1 |
| 20190385748 | Thomas | Dec 2019 | A1 |
| 20190386814 | Ahmed | Dec 2019 | A1 |
| 20190386817 | Carson et al. | Dec 2019 | A1 |
| 20190386818 | Cran | Dec 2019 | A1 |
| 20190386829 | Karame et al. | Dec 2019 | A1 |
| 20190386832 | Palyutina et al. | Dec 2019 | A1 |
| 20190386833 | Alger et al. | Dec 2019 | A1 |
| 20190386834 | Furukawa | Dec 2019 | A1 |
| 20190386940 | Hong et al. | Dec 2019 | A1 |
| 20190386951 | Uhll | Dec 2019 | A1 |
| 20190386968 | Good et al. | Dec 2019 | A1 |
| 20190386969 | Verzun et al. | Dec 2019 | A1 |
| 20190386970 | Signorini et al. | Dec 2019 | A1 |
| 20190386975 | Li | Dec 2019 | A1 |
| 20190386986 | O'Brien et al. | Dec 2019 | A1 |
| 20190386990 | Liu et al. | Dec 2019 | A1 |
| 20190386995 | Chafe et al. | Dec 2019 | A1 |
| 20190387000 | Zavesky et al. | Dec 2019 | A1 |
| 20190387058 | Heller | Dec 2019 | A1 |
| 20190387060 | Kentley-Klay et al. | Dec 2019 | A1 |
| 20190387281 | Turley et al. | Dec 2019 | A1 |
| 20190387341 | Lyren et al. | Dec 2019 | A1 |
| 20190387356 | Branscomb et al. | Dec 2019 | A1 |
| 20190387832 | Andon et al. | Dec 2019 | A1 |
| 20190389323 | Winkler et al. | Dec 2019 | A1 |
| 20190391268 | Houts et al. | Dec 2019 | A1 |
| 20190391540 | Velt et al. | Dec 2019 | A1 |
| 20190391550 | Cella et al. | Dec 2019 | A1 |
| 20190391551 | Cella et al. | Dec 2019 | A1 |
| 20190391552 | Cella et al. | Dec 2019 | A1 |
| 20190391663 | Richter et al. | Dec 2019 | A1 |
| 20190391829 | Cronie et al. | Dec 2019 | A1 |
| 20190391845 | Gasser et al. | Dec 2019 | A1 |
| 20190391971 | Bernat et al. | Dec 2019 | A1 |
| 20190391972 | Bates et al. | Dec 2019 | A1 |
| 20190391973 | Qiu | Dec 2019 | A1 |
| 20190391979 | Bistram | Dec 2019 | A1 |
| 20190391980 | Mundar | Dec 2019 | A1 |
| 20190392019 | Brannon et al. | Dec 2019 | A1 |
| 20190392049 | Estes et al. | Dec 2019 | A1 |
| 20190392064 | Swope et al. | Dec 2019 | A1 |
| 20190392088 | Duff et al. | Dec 2019 | A1 |
| 20190392118 | Elden et al. | Dec 2019 | A1 |
| 20190392119 | Rahiman et al. | Dec 2019 | A1 |
| 20190392123 | Larsen et al. | Dec 2019 | A1 |
| 20190392138 | Rice | Dec 2019 | A1 |
| 20190392159 | Wojcik | Dec 2019 | A1 |
| 20190392162 | Stern et al. | Dec 2019 | A1 |
| 20190392164 | Dutta | Dec 2019 | A1 |
| 20190392178 | Rice | Dec 2019 | A1 |
| 20190392361 | Paul et al. | Dec 2019 | A1 |
| 20190392386 | Wilkinson et al. | Dec 2019 | A1 |
| 20190392392 | Elden et al. | Dec 2019 | A1 |
| 20190392403 | Rainaldi et al. | Dec 2019 | A1 |
| 20190392406 | Deshpande et al. | Dec 2019 | A1 |
| 20190392407 | Keskar | Dec 2019 | A1 |
| 20190392429 | Keskar et al. | Dec 2019 | A1 |
| 20190392432 | Keskar et al. | Dec 2019 | A1 |
| 20190392434 | Castinado et al. | Dec 2019 | A1 |
| 20190392437 | Castagna et al. | Dec 2019 | A1 |
| 20190392438 | Rice | Dec 2019 | A1 |
| 20190392439 | Perullo | Dec 2019 | A1 |
| 20190392457 | Kuntagod et al. | Dec 2019 | A1 |
| 20190392468 | Stanciu et al. | Dec 2019 | A1 |
| 20190392470 | Blanton et al. | Dec 2019 | A1 |
| 20190392489 | Tietzen et al. | Dec 2019 | A1 |
| 20190392511 | Mahajan et al. | Dec 2019 | A1 |
| 20190392530 | Kursun | Dec 2019 | A1 |
| 20190392536 | Rice | Dec 2019 | A1 |
| 20190392659 | Seenivasagam et al. | Dec 2019 | A1 |
| 20190392677 | Halvorson | Dec 2019 | A1 |
| 20190392683 | Halvorson | Dec 2019 | A1 |
| 20190392684 | McDonald et al. | Dec 2019 | A1 |
| 20190392928 | Hosseini et al. | Dec 2019 | A1 |
| 20190393627 | Etsunagi et al. | Dec 2019 | A1 |
| 20190393699 | Shastri et al. | Dec 2019 | A1 |
| 20190393701 | Saynevirta | Dec 2019 | A1 |
| 20190393721 | Pignier et al. | Dec 2019 | A1 |
| 20190393722 | Stocker et al. | Dec 2019 | A1 |
| 20190394018 | Isshiki et al. | Dec 2019 | A1 |
| 20190394019 | Gao | Dec 2019 | A1 |
| 20190394023 | Menon et al. | Dec 2019 | A1 |
| 20190394025 | Maim | Dec 2019 | A1 |
| 20190394026 | Bookman et al. | Dec 2019 | A1 |
| 20190394027 | Falk | Dec 2019 | A1 |
| 20190394039 | Higo et al. | Dec 2019 | A1 |
| 20190394044 | Snow et al. | Dec 2019 | A1 |
| 20190394046 | Su | Dec 2019 | A1 |
| 20190394047 | Karame et al. | Dec 2019 | A1 |
| 20190394048 | Deery et al. | Dec 2019 | A1 |
| 20190394050 | Goeringer et al. | Dec 2019 | A1 |
| 20190394052 | Li et al. | Dec 2019 | A1 |
| 20190394091 | Sevindik | Dec 2019 | A1 |
| 20190394100 | Lamba et al. | Dec 2019 | A1 |
| 20190394113 | Huang | Dec 2019 | A1 |
| 20190394175 | Zhang et al. | Dec 2019 | A1 |
| 20190394176 | Haldenby et al. | Dec 2019 | A1 |
| 20190394179 | Androulaki et al. | Dec 2019 | A1 |
| 20190394203 | Estes et al. | Dec 2019 | A1 |
| 20190394222 | Smelker et al. | Dec 2019 | A1 |
| 20190394242 | Wig et al. | Dec 2019 | A1 |
| 20190394243 | Wiig et al. | Dec 2019 | A1 |
| 20190394257 | Estes et al. | Dec 2019 | A1 |
| 20190394267 | Bistram | Dec 2019 | A1 |
| 20190394302 | Kristiansson et al. | Dec 2019 | A1 |
| 20190394511 | Kalaboukis et al. | Dec 2019 | A1 |
| 20190394637 | Viswanathan et al. | Dec 2019 | A1 |
| 20190394648 | Tipton et al. | Dec 2019 | A1 |
| 20200000366 | Katabi et al. | Jan 2020 | A1 |
| 20200001185 | Eatedali et al. | Jan 2020 | A1 |
| 20200001836 | Koketsu et al. | Jan 2020 | A1 |
| 20200004016 | Gross et al. | Jan 2020 | A1 |
| 20200004500 | Guttmann | Jan 2020 | A1 |
| 20200004611 | Sarin | Jan 2020 | A1 |
| 20200004643 | Yang | Jan 2020 | A1 |
| 20200004732 | Childress et al. | Jan 2020 | A1 |
| 20200004737 | Qiu | Jan 2020 | A1 |
| 20200004771 | Keskar et al. | Jan 2020 | A1 |
| 20200004788 | Qiu | Jan 2020 | A1 |
| 20200004846 | Camenisch et al. | Jan 2020 | A1 |
| 20200004854 | Inturi et al. | Jan 2020 | A1 |
| 20200004855 | Chepak, Jr. et al. | Jan 2020 | A1 |
| 20200004932 | Eatedali et al. | Jan 2020 | A1 |
| 20200004945 | Anderson et al. | Jan 2020 | A1 |
| 20200004946 | Gilpin et al. | Jan 2020 | A1 |
| 20200004951 | Speak et al. | Jan 2020 | A1 |
| 20200004962 | Araujo et al. | Jan 2020 | A1 |
| 20200004969 | Benke et al. | Jan 2020 | A1 |
| 20200004973 | Li et al. | Jan 2020 | A1 |
| 20200004981 | Miyaji | Jan 2020 | A1 |
| 20200004986 | Brannon et al. | Jan 2020 | A1 |
| 20200004987 | Brannon et al. | Jan 2020 | A1 |
| 20200004988 | Brannon et al. | Jan 2020 | A1 |
| 20200004995 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200004996 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200004997 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200004998 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200004999 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200005031 | DeWitt | Jan 2020 | A1 |
| 20200005107 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200005168 | Bhargava et al. | Jan 2020 | A1 |
| 20200005173 | del Pino et al. | Jan 2020 | A1 |
| 20200005180 | Fritchman et al. | Jan 2020 | A1 |
| 20200005189 | Cuomo et al. | Jan 2020 | A1 |
| 20200005207 | Lee et al. | Jan 2020 | A1 |
| 20200005212 | Stevens | Jan 2020 | A1 |
| 20200005213 | Clemens | Jan 2020 | A1 |
| 20200005219 | Stevens | Jan 2020 | A1 |
| 20200005224 | O'Brien et al. | Jan 2020 | A1 |
| 20200005253 | Rangarajan et al. | Jan 2020 | A1 |
| 20200005254 | Wright et al. | Jan 2020 | A1 |
| 20200005255 | Wu | Jan 2020 | A1 |
| 20200005264 | Patterson et al. | Jan 2020 | A1 |
| 20200005267 | Siefken et al. | Jan 2020 | A1 |
| 20200005271 | Baar et al. | Jan 2020 | A1 |
| 20200005281 | Patel | Jan 2020 | A1 |
| 20200005282 | Kim | Jan 2020 | A1 |
| 20200005283 | Zimmerman et al. | Jan 2020 | A1 |
| 20200005284 | Vijayan | Jan 2020 | A1 |
| 20200005285 | Jimenez-Delgado | Jan 2020 | A1 |
| 20200005286 | Sewell et al. | Jan 2020 | A1 |
| 20200005290 | Madisetti et al. | Jan 2020 | A1 |
| 20200005292 | Mao et al. | Jan 2020 | A1 |
| 20200005293 | Opeola | Jan 2020 | A1 |
| 20200005295 | Murphy | Jan 2020 | A1 |
| 20200005296 | Green | Jan 2020 | A1 |
| 20200005299 | Castinado et al. | Jan 2020 | A1 |
| 20200005302 | Baar et al. | Jan 2020 | A1 |
| 20200005307 | Snyder et al. | Jan 2020 | A1 |
| 20200005308 | Snyder et al. | Jan 2020 | A1 |
| 20200005316 | Wagner | Jan 2020 | A1 |
| 20200005332 | Gadol | Jan 2020 | A1 |
| 20200005349 | Brody et al. | Jan 2020 | A1 |
| 20200005388 | Lim et al. | Jan 2020 | A1 |
| 20200005390 | Minsley et al. | Jan 2020 | A1 |
| 20200005398 | Castinado et al. | Jan 2020 | A1 |
| 20200005403 | Patterson et al. | Jan 2020 | A1 |
| 20200005404 | Patterson et al. | Jan 2020 | A1 |
| 20200005410 | McKee | Jan 2020 | A1 |
| 20200005415 | Schuler et al. | Jan 2020 | A1 |
| 20200005559 | Grunbok et al. | Jan 2020 | A1 |
| 20200005587 | Hartl et al. | Jan 2020 | A1 |
| 20200005589 | Halvorson | Jan 2020 | A1 |
| 20200005590 | Halvorson | Jan 2020 | A1 |
| 20200005591 | Halvorson | Jan 2020 | A1 |
| 20200005597 | Halvorson | Jan 2020 | A1 |
| 20200005767 | Ye et al. | Jan 2020 | A1 |
| 20200005777 | Wittke | Jan 2020 | A1 |
| 20200005912 | Saliman et al. | Jan 2020 | A1 |
| 20200007311 | Oberhofer et al. | Jan 2020 | A1 |
| 20200007312 | Vouk et al. | Jan 2020 | A1 |
| 20200007313 | Vouk et al. | Jan 2020 | A1 |
| 20200007314 | Vouk et al. | Jan 2020 | A1 |
| 20200007315 | Vouk et al. | Jan 2020 | A1 |
| 20200007316 | Krishnamacharya et al. | Jan 2020 | A1 |
| 20200007317 | Thompson | Jan 2020 | A1 |
| 20200007318 | Camenisch et al. | Jan 2020 | A1 |
| 20200007322 | Weldemariam et al. | Jan 2020 | A1 |
| 20200007331 | Wentz | Jan 2020 | A1 |
| 20200007333 | Young | Jan 2020 | A1 |
| 20200007336 | Wengel | Jan 2020 | A1 |
| 20200007338 | Oh | Jan 2020 | A1 |
| 20200007342 | Liem et al. | Jan 2020 | A1 |
| 20200007343 | Evans | Jan 2020 | A1 |
| 20200007344 | Chepak, Jr. et al. | Jan 2020 | A1 |
| 20200007345 | Barry et al. | Jan 2020 | A1 |
| 20200007346 | Callan et al. | Jan 2020 | A1 |
| 20200007393 | Davis | Jan 2020 | A1 |
| 20200007414 | Smith et al. | Jan 2020 | A1 |
| 20200007464 | Lo et al. | Jan 2020 | A1 |
| 20200007511 | Van de Groenendaal et al. | Jan 2020 | A1 |
| 20200007513 | Gleichauf | Jan 2020 | A1 |
| 20200007514 | Li et al. | Jan 2020 | A1 |
| 20200007525 | Castinado et al. | Jan 2020 | A1 |
| 20200007540 | Kawaguchi et al. | Jan 2020 | A1 |
| 20200007544 | Wang et al. | Jan 2020 | A1 |
| 20200007558 | Inokuchi et al. | Jan 2020 | A1 |
| 20200007581 | Vouk et al. | Jan 2020 | A1 |
| 20200007918 | Frank | Jan 2020 | A1 |
| 20200008299 | Tran et al. | Jan 2020 | A1 |
| 20200008320 | Yu et al. | Jan 2020 | A1 |
| 20200009983 | Oshima et al. | Jan 2020 | A1 |
| 20200009990 | Shiiyama et al. | Jan 2020 | A1 |
| 20200010080 | Weldemariam et al. | Jan 2020 | A1 |
| 20200011557 | Thomas, Sr. | Jan 2020 | A1 |
| 20200011683 | Simpson | Jan 2020 | A1 |
| 20200012248 | Cella et al. | Jan 2020 | A1 |
| 20200012527 | Hartsock | Jan 2020 | A1 |
| 20200012579 | Anokhin et al. | Jan 2020 | A1 |
| 20200012625 | Nelluri et al. | Jan 2020 | A1 |
| 20200012634 | Eberhardt | Jan 2020 | A1 |
| 20200012676 | Singh Narang et al. | Jan 2020 | A1 |
| 20200012703 | Burzlaff | Jan 2020 | A1 |
| 20200012731 | Deshpande et al. | Jan 2020 | A1 |
| 20200012763 | Arngren et al. | Jan 2020 | A1 |
| 20200012765 | Smaiely et al. | Jan 2020 | A1 |
| 20200012767 | Votaw et al. | Jan 2020 | A1 |
| 20200012768 | Votaw et al. | Jan 2020 | A1 |
| 20200012779 | Chandrasekaran et al. | Jan 2020 | A1 |
| 20200012805 | Winarski | Jan 2020 | A1 |
| 20200012806 | Bates et al. | Jan 2020 | A1 |
| 20200012809 | Winarski | Jan 2020 | A1 |
| 20200012810 | Chavez | Jan 2020 | A1 |
| 20200013025 | Verma et al. | Jan 2020 | A1 |
| 20200013026 | Noonan et al. | Jan 2020 | A1 |
| 20200013027 | Zhu | Jan 2020 | A1 |
| 20200013028 | Black et al. | Jan 2020 | A1 |
| 20200013029 | Gu et al. | Jan 2020 | A1 |
| 20200013045 | Spalding et al. | Jan 2020 | A1 |
| 20200013046 | Joao | Jan 2020 | A1 |
| 20200013047 | Weissenmayer et al. | Jan 2020 | A1 |
| 20200013048 | Love | Jan 2020 | A1 |
| 20200013049 | Ingram et al. | Jan 2020 | A1 |
| 20200013050 | Finlow-Bates et al. | Jan 2020 | A1 |
| 20200013053 | Amin | Jan 2020 | A1 |
| 20200013055 | Sandor | Jan 2020 | A1 |
| 20200013062 | Pratt et al. | Jan 2020 | A1 |
| 20200013063 | Kurian et al. | Jan 2020 | A1 |
| 20200013073 | Bakalis | Jan 2020 | A1 |
| 20200013083 | Narayanam et al. | Jan 2020 | A1 |
| 20200013093 | Brooks | Jan 2020 | A1 |
| 20200013118 | Treat et al. | Jan 2020 | A1 |
| 20200013229 | Lee et al. | Jan 2020 | A1 |
| 20200013250 | Jakubek et al. | Jan 2020 | A1 |
| 20200013251 | Ivanov et al. | Jan 2020 | A1 |
| 20200013268 | Jarvis et al. | Jan 2020 | A1 |
| 20200013302 | Lawrenson et al. | Jan 2020 | A1 |
| 20200014527 | Subramaniam | Jan 2020 | A1 |
| 20200014528 | Nandakumar et al. | Jan 2020 | A1 |
| 20200014529 | Kanza et al. | Jan 2020 | A1 |
| 20200014531 | Falco et al. | Jan 2020 | A1 |
| 20200014536 | Walden et al. | Jan 2020 | A1 |
| 20200014537 | Ortiz et al. | Jan 2020 | A1 |
| 20200014542 | McIver et al. | Jan 2020 | A1 |
| 20200014546 | Karame et al. | Jan 2020 | A1 |
| 20200014632 | Way | Jan 2020 | A1 |
| 20200014664 | Brown et al. | Jan 2020 | A1 |
| 20200014668 | Statica et al. | Jan 2020 | A1 |
| 20200014671 | Isaacson et al. | Jan 2020 | A1 |
| 20200014691 | Ortiz et al. | Jan 2020 | A1 |
| 20200014720 | Giura | Jan 2020 | A1 |
| 20200014745 | Thurimella et al. | Jan 2020 | A1 |
| 20200014759 | Wunderlich | Jan 2020 | A1 |
| 20200014816 | Speasl et al. | Jan 2020 | A1 |
| 20200015034 | Ahn et al. | Jan 2020 | A1 |
| 20200015078 | He et al. | Jan 2020 | A1 |
| 20200016363 | Macri et al. | Jan 2020 | A1 |
| 20200017117 | Milton | Jan 2020 | A1 |
| 20200018800 | Oshima et al. | Jan 2020 | A1 |
| 20200019154 | Cella et al. | Jan 2020 | A1 |
| 20200019155 | Cella et al. | Jan 2020 | A1 |
| 20200019288 | D'Amore et al. | Jan 2020 | A1 |
| 20200019397 | Duran et al. | Jan 2020 | A1 |
| 20200019421 | Sun | Jan 2020 | A1 |
| 20200019450 | Patton et al. | Jan 2020 | A1 |
| 20200019538 | Lauriston | Jan 2020 | A1 |
| 20200019545 | Ye | Jan 2020 | A1 |
| 20200019613 | Bacarella et al. | Jan 2020 | A1 |
| 20200019616 | Sukhija et al. | Jan 2020 | A1 |
| 20200019626 | Todd et al. | Jan 2020 | A1 |
| 20200019677 | Pangaev | Jan 2020 | A1 |
| 20200019680 | Frederick et al. | Jan 2020 | A1 |
| 20200019706 | Zhu et al. | Jan 2020 | A1 |
| 20200019707 | Zhu et al. | Jan 2020 | A1 |
| 20200019723 | Binsztok | Jan 2020 | A1 |
| 20200019821 | Baracaldo-Angel et al. | Jan 2020 | A1 |
| 20200019864 | Gu et al. | Jan 2020 | A1 |
| 20200019865 | Wang et al. | Jan 2020 | A1 |
| 20200019867 | Nandakumar et al. | Jan 2020 | A1 |
| 20200019894 | Jin et al. | Jan 2020 | A1 |
| 20200019898 | Harrison | Jan 2020 | A1 |
| 20200019923 | Santhar et al. | Jan 2020 | A1 |
| 20200019931 | Prabhakar et al. | Jan 2020 | A1 |
| 20200019936 | Irazabal | Jan 2020 | A1 |
| 20200019937 | Edwards et al. | Jan 2020 | A1 |
| 20200019938 | Wang et al. | Jan 2020 | A1 |
| 20200019946 | Walker et al. | Jan 2020 | A1 |
| 20200019959 | Fan et al. | Jan 2020 | A1 |
| 20200019961 | Silvestre | Jan 2020 | A1 |
| 20200019963 | Nakamura | Jan 2020 | A1 |
| 20200019966 | Abdi Taghi Abad et al. | Jan 2020 | A1 |
| 20200019967 | Abdi Taghi Abad et al. | Jan 2020 | A1 |
| 20200019980 | Arora et al. | Jan 2020 | A1 |
| 20200020032 | Bleznak et al. | Jan 2020 | A1 |
| 20200020037 | Idrobo | Jan 2020 | A1 |
| 20200020038 | Haile et al. | Jan 2020 | A1 |
| 20200020064 | Smith et al. | Jan 2020 | A1 |
| 20200020091 | Forutanpour et al. | Jan 2020 | A1 |
| 20200020174 | Hudson et al. | Jan 2020 | A1 |
| 20200020175 | Smith et al. | Jan 2020 | A1 |
| 20200020176 | Smith et al. | Jan 2020 | A1 |
| 20200020187 | Soeda | Jan 2020 | A1 |
| 20200020319 | Malhotra et al. | Jan 2020 | A1 |
| 20200020398 | Miller et al. | Jan 2020 | A1 |
| 20200020424 | Lin | Jan 2020 | A1 |
| 20200020425 | Qu et al. | Jan 2020 | A1 |
| 20200020440 | Beinhauer | Jan 2020 | A1 |
| 20200020454 | McGarvey et al. | Jan 2020 | A1 |
| 20200021429 | Harrington | Jan 2020 | A1 |
| 20200021439 | Sato | Jan 2020 | A1 |
| 20200021443 | Falk | Jan 2020 | A1 |
| 20200021444 | Young et al. | Jan 2020 | A1 |
| 20200021446 | Roennow et al. | Jan 2020 | A1 |
| 20200021546 | Cardinal et al. | Jan 2020 | A1 |
| 20200021568 | Becher et al. | Jan 2020 | A1 |
| 20200021569 | Simons | Jan 2020 | A1 |
| 20200021570 | Lin | Jan 2020 | A1 |
| 20200021588 | Wittrock et al. | Jan 2020 | A1 |
| 20200021589 | Smith et al. | Jan 2020 | A1 |
| 20200021590 | Jeuk et al. | Jan 2020 | A1 |
| 20200021598 | Lee et al. | Jan 2020 | A1 |
| 20200021600 | Simons | Jan 2020 | A1 |
| 20200021602 | Irazabal | Jan 2020 | A1 |
| 20200021643 | Purushothaman et al. | Jan 2020 | A1 |
| 20200021649 | Natanzon | Jan 2020 | A1 |
| 20200021714 | Chuang | Jan 2020 | A1 |
| 20200022201 | Ross et al. | Jan 2020 | A1 |
| 20200022416 | Alarcon | Jan 2020 | A1 |
| 20200023273 | Tsurusaki et al. | Jan 2020 | A1 |
| 20200023846 | Husain et al. | Jan 2020 | A1 |
| 20200026076 | Beckman | Jan 2020 | A1 |
| 20200026253 | Fuhr et al. | Jan 2020 | A1 |
| 20200026270 | Cella et al. | Jan 2020 | A1 |
| 20200026289 | Alvarez et al. | Jan 2020 | A1 |
| 20200026444 | Dai et al. | Jan 2020 | A1 |
| 20200026510 | Adams et al. | Jan 2020 | A1 |
| 20200026548 | Huang | Jan 2020 | A1 |
| 20200026552 | Zhang et al. | Jan 2020 | A1 |
| 20200026613 | Kaji et al. | Jan 2020 | A1 |
| 20200026619 | Kaji et al. | Jan 2020 | A1 |
| 20200026691 | Qiu | Jan 2020 | A1 |
| 20200026699 | Zhang et al. | Jan 2020 | A1 |
| 20200026700 | Qiu | Jan 2020 | A1 |
| 20200026712 | Madisetti et al. | Jan 2020 | A1 |
| 20200026741 | Gilula | Jan 2020 | A1 |
| 20200026785 | Patangia et al. | Jan 2020 | A1 |
| 20200026787 | Alam | Jan 2020 | A1 |
| 20200026800 | Siu | Jan 2020 | A1 |
| 20200026834 | Vimadalal et al. | Jan 2020 | A1 |
| 20200026862 | Zhang et al. | Jan 2020 | A1 |
| 20200026867 | Nicholls | Jan 2020 | A1 |
| 20200026973 | Osborn et al. | Jan 2020 | A1 |
| 20200027005 | Harrison et al. | Jan 2020 | A1 |
| 20200027010 | Lorenc et al. | Jan 2020 | A1 |
| 20200027050 | Ghosh et al. | Jan 2020 | A1 |
| 20200027066 | Ramasamy et al. | Jan 2020 | A1 |
| 20200027067 | Hertzog et al. | Jan 2020 | A1 |
| 20200027079 | Kurian | Jan 2020 | A1 |
| 20200027080 | Holland et al. | Jan 2020 | A1 |
| 20200027082 | Nakagawa | Jan 2020 | A1 |
| 20200027084 | Groarke et al. | Jan 2020 | A1 |
| 20200027085 | Lee et al. | Jan 2020 | A1 |
| 20200027089 | Kuchar et al. | Jan 2020 | A1 |
| 20200027091 | Hassani et al. | Jan 2020 | A1 |
| 20200027093 | Volk | Jan 2020 | A1 |
| 20200027096 | Cooner | Jan 2020 | A1 |
| 20200027106 | Kendrick | Jan 2020 | A1 |
| 20200027117 | Cotsakos et al. | Jan 2020 | A1 |
| 20200027120 | Segalov et al. | Jan 2020 | A1 |
| 20200027125 | Segalov et al. | Jan 2020 | A1 |
| 20200027132 | Segalov et al. | Jan 2020 | A1 |
| 20200027133 | Segalov et al. | Jan 2020 | A1 |
| 20200027162 | Singh et al. | Jan 2020 | A1 |
| 20200027169 | Valencia | Jan 2020 | A1 |
| 20200027179 | Liss | Jan 2020 | A1 |
| 20200027183 | Guttridge | Jan 2020 | A1 |
| 20200027303 | Thomas | Jan 2020 | A1 |
| 20200027314 | Pilnock et al. | Jan 2020 | A1 |
| 20200027315 | Cotton | Jan 2020 | A1 |
| 20200027565 | Poppe | Jan 2020 | A1 |
| 20200028360 | Heintel et al. | Jan 2020 | A1 |
| 20200028667 | Castinado et al. | Jan 2020 | A1 |
| 20200028668 | Ramasamy et al. | Jan 2020 | A1 |
| 20200028675 | Gancarz | Jan 2020 | A1 |
| 20200028681 | Chen et al. | Jan 2020 | A1 |
| 20200028688 | Takada | Jan 2020 | A1 |
| 20200028691 | Rao et al. | Jan 2020 | A1 |
| 20200028692 | Wu | Jan 2020 | A1 |
| 20200028693 | Wu et al. | Jan 2020 | A1 |
| 20200028697 | Unger et al. | Jan 2020 | A1 |
| 20200028775 | Chen | Jan 2020 | A1 |
| 20200028797 | Castinado et al. | Jan 2020 | A1 |
| 20200028800 | Strathman et al. | Jan 2020 | A1 |
| 20200028804 | Ergen | Jan 2020 | A1 |
| 20200028834 | Nakata et al. | Jan 2020 | A1 |
| 20200028844 | Aime et al. | Jan 2020 | A1 |
| 20200028885 | Gordon et al. | Jan 2020 | A1 |
| 20200028908 | Coleman et al. | Jan 2020 | A1 |
| 20200028926 | Sprague et al. | Jan 2020 | A1 |
| 20200028947 | Yang | Jan 2020 | A1 |
| 20200029128 | Erskine | Jan 2020 | A1 |
| 20200029139 | García Osma et al. | Jan 2020 | A1 |
| 20200029190 | Bruns | Jan 2020 | A1 |
| 20200029250 | Ibek et al. | Jan 2020 | A1 |
| 20200030172 | Fassihi et al. | Jan 2020 | A1 |
| 20200030971 | Oleynik | Jan 2020 | A1 |
| 20200033821 | Krishnamurthy et al. | Jan 2020 | A1 |
| 20200033834 | Samid | Jan 2020 | A1 |
| 20200033837 | Simmons et al. | Jan 2020 | A1 |
| 20200033887 | Kim | Jan 2020 | A1 |
| 20200033931 | de Rochemont | Jan 2020 | A1 |
| 20200034311 | Wang | Jan 2020 | A1 |
| 20200034334 | Lu | Jan 2020 | A1 |
| 20200034338 | Gentile et al. | Jan 2020 | A1 |
| 20200034343 | Keskar | Jan 2020 | A1 |
| 20200034352 | Li et al. | Jan 2020 | A1 |
| 20200034353 | Innocenti | Jan 2020 | A1 |
| 20200034356 | Yu | Jan 2020 | A1 |
| 20200034395 | Lu | Jan 2020 | A1 |
| 20200034411 | Soon-Shiong et al. | Jan 2020 | A1 |
| 20200034448 | Sato et al. | Jan 2020 | A1 |
| 20200034453 | Sato et al. | Jan 2020 | A1 |
| 20200034454 | Chamarajnager et al. | Jan 2020 | A1 |
| 20200034456 | Montgomery-Recht et al. | Jan 2020 | A1 |
| 20200034457 | Brody et al. | Jan 2020 | A1 |
| 20200034469 | Sato et al. | Jan 2020 | A1 |
| 20200034501 | Duff et al. | Jan 2020 | A1 |
| 20200034536 | Tagomori | Jan 2020 | A1 |
| 20200034548 | Wu et al. | Jan 2020 | A1 |
| 20200034550 | Kim et al. | Jan 2020 | A1 |
| 20200034551 | Cantrell et al. | Jan 2020 | A1 |
| 20200034552 | Korres et al. | Jan 2020 | A1 |
| 20200034553 | Kenyon et al. | Jan 2020 | A1 |
| 20200034571 | Fett | Jan 2020 | A1 |
| 20200034610 | Taylor et al. | Jan 2020 | A1 |
| 20200034712 | Katz et al. | Jan 2020 | A1 |
| 20200034766 | Borges | Jan 2020 | A1 |
| 20200034788 | Ynion, Jr. | Jan 2020 | A1 |
| 20200034792 | Rogers et al. | Jan 2020 | A1 |
| 20200034804 | Mousko et al. | Jan 2020 | A1 |
| 20200034813 | Calinog et al. | Jan 2020 | A1 |
| 20200034818 | Selfin et al. | Jan 2020 | A1 |
| 20200034828 | Elishkov | Jan 2020 | A1 |
| 20200034833 | Collen et al. | Jan 2020 | A1 |
| 20200034834 | Li et al. | Jan 2020 | A1 |
| 20200034836 | Shah | Jan 2020 | A1 |
| 20200034839 | Soundararajan et al. | Jan 2020 | A1 |
| 20200034841 | Kurian | Jan 2020 | A1 |
| 20200034868 | Momary et al. | Jan 2020 | A1 |
| 20200034869 | Harrison | Jan 2020 | A1 |
| 20200034876 | Soundararajan et al. | Jan 2020 | A1 |
| 20200034888 | Soundararajan et al. | Jan 2020 | A1 |
| 20200034919 | Qiu et al. | Jan 2020 | A1 |
| 20200034925 | Dziuk | Jan 2020 | A1 |
| 20200034928 | Lim et al. | Jan 2020 | A1 |
| 20200034944 | Johansson et al. | Jan 2020 | A1 |
| 20200034945 | Soundararajan et al. | Jan 2020 | A1 |
| 20200035059 | Campero et al. | Jan 2020 | A1 |
| 20200035337 | Sohne et al. | Jan 2020 | A1 |
| 20200035339 | Eevani et al. | Jan 2020 | A1 |
| 20200035340 | Kain et al. | Jan 2020 | A1 |
| 20200035341 | Kain et al. | Jan 2020 | A1 |
| 20200036225 | Kolling et al. | Jan 2020 | A1 |
| 20200036511 | Cheon et al. | Jan 2020 | A1 |
| 20200036514 | Christensen et al. | Jan 2020 | A1 |
| 20200036515 | Chari et al. | Jan 2020 | A1 |
| 20200036517 | Denham | Jan 2020 | A1 |
| 20200036519 | Bitauld et al. | Jan 2020 | A1 |
| 20200036520 | Kilian | Jan 2020 | A1 |
| 20200036523 | Patin | Jan 2020 | A1 |
| 20200036530 | Lampkins et al. | Jan 2020 | A1 |
| 20200036531 | Minovic et al. | Jan 2020 | A1 |
| 20200036533 | Soundararajan et al. | Jan 2020 | A1 |
| 20200036549 | Staton et al. | Jan 2020 | A1 |
| 20200036585 | Todd et al. | Jan 2020 | A1 |
| 20200036687 | May | Jan 2020 | A1 |
| 20200036695 | Sharp et al. | Jan 2020 | A1 |
| 20200036707 | Callahan et al. | Jan 2020 | A1 |
| 20200036712 | Soundararajan et al. | Jan 2020 | A1 |
| 20200036728 | Spanke et al. | Jan 2020 | A1 |
| 20200036729 | Maneval et al. | Jan 2020 | A1 |
| 20200036740 | Ford | Jan 2020 | A1 |
| 20200036743 | Almukaynizi et al. | Jan 2020 | A1 |
| 20200037034 | Greyling | Jan 2020 | A1 |
| 20200037158 | Soundararajan et al. | Jan 2020 | A1 |
| 20200037381 | Ross et al. | Jan 2020 | A1 |
| 20200042988 | Snow et al. | Feb 2020 | A1 |
| 20200042989 | Ramadoss et al. | Feb 2020 | A1 |
| 20200042994 | Zhang et al. | Feb 2020 | A1 |
| 20200042995 | Snow et al. | Feb 2020 | A1 |
| 20200042998 | Mendhi et al. | Feb 2020 | A1 |
| 20200042999 | Zhang et al. | Feb 2020 | A1 |
| 20200043007 | Simons | Feb 2020 | A1 |
| 20200044837 | Bos et al. | Feb 2020 | A1 |
| 20200044863 | Yadlin et al. | Feb 2020 | A1 |
| 20200050774 | Unagami | Feb 2020 | A1 |
| 20200051077 | Ma et al. | Feb 2020 | A1 |
| 20200051188 | Chopra et al. | Feb 2020 | A1 |
| 20200051361 | Cui et al. | Feb 2020 | A1 |
| 20200052890 | Baron et al. | Feb 2020 | A1 |
| 20200052898 | Wentz | Feb 2020 | A1 |
| 20200052903 | Lam et al. | Feb 2020 | A1 |
| 20200053054 | Ma et al. | Feb 2020 | A1 |
| 20200053124 | Manasse et al. | Feb 2020 | A1 |
| 20200057755 | Veeningen | Feb 2020 | A1 |
| 20200057876 | Chang | Feb 2020 | A1 |
| 20200057920 | Collins et al. | Feb 2020 | A1 |
| 20200058022 | Ma et al. | Feb 2020 | A1 |
| 20200059495 | Karame et al. | Feb 2020 | A1 |
| 20200065480 | Gu et al. | Feb 2020 | A1 |
| 20200067699 | Resch et al. | Feb 2020 | A1 |
| 20200067707 | Resch et al. | Feb 2020 | A1 |
| 20200068404 | Newman et al. | Feb 2020 | A1 |
| 20200073560 | Adanve | Mar 2020 | A1 |
| 20200074110 | Veeningen et al. | Mar 2020 | A1 |
| 20200074112 | Ren et al. | Mar 2020 | A1 |
| 20200074456 | Coleman et al. | Mar 2020 | A1 |
| 20200074457 | Coleman et al. | Mar 2020 | A1 |
| 20200074459 | Ma et al. | Mar 2020 | A1 |
| 20200074460 | Tapang | Mar 2020 | A1 |
| 20200074548 | Aidoo et al. | Mar 2020 | A1 |
| 20200074552 | Shier et al. | Mar 2020 | A1 |
| 20200076570 | Musuvathi et al. | Mar 2020 | A1 |
| 20200076614 | Georgieva et al. | Mar 2020 | A1 |
| 20200076829 | Wentz | Mar 2020 | A1 |
| 20200082113 | Van Liesdonk et al. | Mar 2020 | A1 |
| 20200082126 | Brown et al. | Mar 2020 | A1 |
| 20200082259 | Gu et al. | Mar 2020 | A1 |
| 20200082360 | Regev | Mar 2020 | A1 |
| 20200082433 | Brown et al. | Mar 2020 | A1 |
| 20200082738 | Poeppelmann | Mar 2020 | A1 |
| 20200084017 | Bent et al. | Mar 2020 | A1 |
| 20200084039 | Chabanne et al. | Mar 2020 | A1 |
| 20200084191 | Nicholls | Mar 2020 | A1 |
| 20200084288 | Baig et al. | Mar 2020 | A1 |
| 20200084483 | Brown et al. | Mar 2020 | A1 |
| 20200086828 | Ujkashevic et al. | Mar 2020 | A1 |
| 20200089872 | Gray | Mar 2020 | A1 |
| 20200089906 | Bent et al. | Mar 2020 | A1 |
| 20200089919 | Courousse et al. | Mar 2020 | A1 |
| 20200092094 | Resch et al. | Mar 2020 | A1 |
| 20200097256 | Marin | Mar 2020 | A1 |
| 20200097849 | Kelly | Mar 2020 | A1 |
| 20200098011 | Bonawitz et al. | Mar 2020 | A1 |
| 20200099530 | Khatib | Mar 2020 | A1 |
| 20200099666 | Soon-Shiong et al. | Mar 2020 | A1 |
| 20200104636 | Halevi et al. | Apr 2020 | A1 |
| 20200104705 | Bhowmick et al. | Apr 2020 | A1 |
| 20200106708 | Sleevi | Apr 2020 | A1 |
| 20200111022 | Silberman et al. | Apr 2020 | A1 |
| 20200111093 | Ma et al. | Apr 2020 | A1 |
| 20200112424 | Gouget | Apr 2020 | A1 |
| 20200112429 | Keselman et al. | Apr 2020 | A1 |
| 20200112442 | Wentz | Apr 2020 | A1 |
| 20200112545 | Smith et al. | Apr 2020 | A1 |
| 20200117690 | Tran et al. | Apr 2020 | A1 |
| 20200118458 | Shriberg et al. | Apr 2020 | A1 |
| 20200119921 | Rodriguez et al. | Apr 2020 | A1 |
| 20200119969 | Niederfeld et al. | Apr 2020 | A1 |
| 20200120023 | Munson et al. | Apr 2020 | A1 |
| 20200120070 | Thubert et al. | Apr 2020 | A1 |
| 20200120074 | Ma et al. | Apr 2020 | A1 |
| 20200125739 | Verma et al. | Apr 2020 | A1 |
| 20200125744 | Smith et al. | Apr 2020 | A1 |
| 20200125999 | Simpson | Apr 2020 | A1 |
| 20200126070 | Joseph | Apr 2020 | A1 |
| 20200126075 | Fisch | Apr 2020 | A1 |
| 20200126365 | Eckman et al. | Apr 2020 | A1 |
| 20200126660 | Costantino et al. | Apr 2020 | A1 |
| 20200127810 | Hiromasa et al. | Apr 2020 | A1 |
| 20200127834 | Westland | Apr 2020 | A1 |
| 20200128075 | Tormasov et al. | Apr 2020 | A1 |
| 20200134207 | Doshi et al. | Apr 2020 | A1 |
| 20200134612 | Fostiropulo et al. | Apr 2020 | A1 |
| 20200134624 | Zhang et al. | Apr 2020 | A1 |
| 20200134625 | Li et al. | Apr 2020 | A1 |
| 20200136797 | Yu et al. | Apr 2020 | A1 |
| 20200136798 | Kim et al. | Apr 2020 | A1 |
| 20200136799 | Smith et al. | Apr 2020 | A1 |
| 20200136829 | Keon et al. | Apr 2020 | A1 |
| 20200142986 | Ragnoli et al. | May 2020 | A1 |
| 20200143066 | Klontz | May 2020 | A1 |
| 20200143076 | Oberhofer et al. | May 2020 | A1 |
| 20200143368 | Zhang et al. | May 2020 | A1 |
| 20200143459 | Simpson | May 2020 | A1 |
| 20200143466 | Wu et al. | May 2020 | A1 |
| 20200145195 | Ma et al. | May 2020 | A1 |
| 20200145384 | Chauhan | May 2020 | A1 |
| 20200150885 | Rattan et al. | May 2020 | A1 |
| 20200151356 | Rohloff et al. | May 2020 | A1 |
| 20200151709 | Bryan | May 2020 | A1 |
| 20200151992 | Cui et al. | May 2020 | A1 |
| 20200153624 | Wentz et al. | May 2020 | A1 |
| 20200153627 | Wentz | May 2020 | A1 |
| 20200153628 | Sakai et al. | May 2020 | A1 |
| 20200153801 | Ma et al. | May 2020 | A1 |
| 20200153803 | Treat et al. | May 2020 | A1 |
| 20200160290 | Peikert et al. | May 2020 | A1 |
| 20200160388 | Sabeg et al. | May 2020 | A1 |
| 20200160641 | Ruskin et al. | May 2020 | A1 |
| 20200162235 | Cheon et al. | May 2020 | A1 |
| 20200162251 | Wentz | May 2020 | A1 |
| 20200162268 | Wentz | May 2020 | A1 |
| 20200162451 | Alhawaj et al. | May 2020 | A1 |
| 20200167503 | Wei et al. | May 2020 | A1 |
| 20200167512 | Chitra et al. | May 2020 | A1 |
| 20200174949 | Ramasamy et al. | Jun 2020 | A1 |
| 20200174990 | Pratkanis | Jun 2020 | A1 |
| 20200175180 | Li et al. | Jun 2020 | A1 |
| 20200175183 | Ramasamy et al. | Jun 2020 | A1 |
| 20200175502 | Ma et al. | Jun 2020 | A1 |
| 20200175509 | Qi | Jun 2020 | A1 |
| 20200175611 | Gelfand | Jun 2020 | A1 |
| 20200175623 | Howie | Jun 2020 | A1 |
| 20200177366 | Han et al. | Jun 2020 | A1 |
| 20200184036 | Wu et al. | Jun 2020 | A1 |
| 20200184093 | Liu et al. | Jun 2020 | A1 |
| 20200184278 | Zadeh et al. | Jun 2020 | A1 |
| 20200184465 | Kislev et al. | Jun 2020 | A1 |
| 20200184471 | Liu et al. | Jun 2020 | A1 |
| 20200184555 | Gleizer | Jun 2020 | A1 |
| 20200184556 | Cella | Jun 2020 | A1 |
| 20200186325 | Anderson | Jun 2020 | A1 |
| 20200186350 | Wentz et al. | Jun 2020 | A1 |
| 20200186352 | Arora et al. | Jun 2020 | A1 |
| 20200186528 | Fan et al. | Jun 2020 | A1 |
| 20200187018 | Hoffberg | Jun 2020 | A1 |
| 20200192957 | Augustine et al. | Jun 2020 | A1 |
| 20200193042 | Johns | Jun 2020 | A1 |
| 20200193066 | Johns | Jun 2020 | A1 |
| 20200193292 | Weng et al. | Jun 2020 | A1 |
| 20200193418 | Augustine et al. | Jun 2020 | A1 |
| 20200193419 | Lin | Jun 2020 | A1 |
| 20200193434 | Ma | Jun 2020 | A1 |
| 20200193516 | de Jong et al. | Jun 2020 | A9 |
| 20200193541 | Barry et al. | Jun 2020 | A1 |
| 20200195419 | Zhang et al. | Jun 2020 | A1 |
| 20200195437 | Gallagher et al. | Jun 2020 | A1 |
| 20200201679 | Wentz | Jun 2020 | A1 |
| 20200201910 | Gavaudan et al. | Jun 2020 | A1 |
| 20200202018 | Ciocarlie et al. | Jun 2020 | A1 |
| 20200202171 | Hughes et al. | Jun 2020 | A1 |
| 20200202345 | Zhang | Jun 2020 | A1 |
| 20200202376 | Benoliel et al. | Jun 2020 | A1 |
| 20200202427 | Cella | Jun 2020 | A1 |
| 20200202429 | Cella | Jun 2020 | A1 |
| 20200204340 | Curran | Jun 2020 | A1 |
| 20200204375 | Coulmeau et al. | Jun 2020 | A1 |
| 20200204524 | Simons et al. | Jun 2020 | A1 |
| 20200204563 | Simons | Jun 2020 | A1 |
| 20200210380 | Cage et al. | Jul 2020 | A1 |
| 20200210392 | Kain | Jul 2020 | A1 |
| 20200210404 | Kain et al. | Jul 2020 | A1 |
| 20200210405 | Kain | Jul 2020 | A1 |
| 20200211018 | Li et al. | Jul 2020 | A1 |
| 20200213079 | Kreeger et al. | Jul 2020 | A1 |
| 20200213110 | Cage et al. | Jul 2020 | A1 |
| 20200213130 | Zhang | Jul 2020 | A1 |
| 20200213134 | Zhang | Jul 2020 | A1 |
| 20200213291 | Cage et al. | Jul 2020 | A1 |
| 20200213292 | Cage et al. | Jul 2020 | A1 |
| 20200213329 | Simons | Jul 2020 | A1 |
| 20200213331 | Li et al. | Jul 2020 | A1 |
| 20200213839 | Truchan et al. | Jul 2020 | A1 |
| 20200218825 | Krishnamoorthy | Jul 2020 | A1 |
| 20200219017 | Simpson | Jul 2020 | A1 |
| 20200219188 | Cella | Jul 2020 | A1 |
| 20200219362 | Simons | Jul 2020 | A1 |
| 20200220851 | Storm et al. | Jul 2020 | A1 |
| 20200220870 | Wagner et al. | Jul 2020 | A1 |
| 20200226470 | Storm et al. | Jul 2020 | A1 |
| 20200226687 | Krishna | Jul 2020 | A1 |
| 20200226867 | Komo et al. | Jul 2020 | A1 |
| 20200228307 | Cheon et al. | Jul 2020 | A1 |
| 20200228309 | Hoffstein et al. | Jul 2020 | A1 |
| 20200228313 | Storm et al. | Jul 2020 | A1 |
| 20200228314 | Ikarashi et al. | Jul 2020 | A1 |
| 20200228317 | Ma et al. | Jul 2020 | A1 |
| 20200228325 | Fan et al. | Jul 2020 | A1 |
| 20200228339 | Barham et al. | Jul 2020 | A1 |
| 20200228340 | Blackhurst et al. | Jul 2020 | A1 |
| 20200228341 | Mohassel et al. | Jul 2020 | A1 |
| 20200234719 | Filler et al. | Jul 2020 | A1 |
| 20200234794 | Esteves-Verissimo et al. | Jul 2020 | A1 |
| 20200235908 | Hiromasa | Jul 2020 | A1 |
| 20200241960 | Yanovsky et al. | Jul 2020 | A1 |
| 20200242102 | Kain | Jul 2020 | A1 |
| 20200242466 | Mohassel et al. | Jul 2020 | A1 |
| 20200242557 | Carey et al. | Jul 2020 | A1 |
| 20200243176 | Soon-Shiong et al. | Jul 2020 | A1 |
| 20200244435 | Shpurov et al. | Jul 2020 | A1 |
| 20200244437 | Ruan | Jul 2020 | A1 |
| 20200250318 | Al Belooshi | Aug 2020 | A1 |
| 20200250320 | Liu et al. | Aug 2020 | A1 |
| 20200250590 | Augustine et al. | Aug 2020 | A1 |
| 20200250679 | Arora et al. | Aug 2020 | A1 |
| 20200252198 | Nandakumar et al. | Aug 2020 | A1 |
| 20200252199 | Cheon et al. | Aug 2020 | A1 |
| 20200258339 | Cui et al. | Aug 2020 | A1 |
| 20200258340 | Cui et al. | Aug 2020 | A1 |
| 20200259638 | Carmignani et al. | Aug 2020 | A1 |
| 20200259639 | Robert et al. | Aug 2020 | A1 |
| 20200259896 | Sachs et al. | Aug 2020 | A1 |
| 20200265159 | Schmatz et al. | Aug 2020 | A1 |
| 20200266974 | Cheon et al. | Aug 2020 | A1 |
| 20200267144 | Wagner et al. | Aug 2020 | A1 |
| 20200267553 | Wagner et al. | Aug 2020 | A1 |
| 20200272475 | Courousse | Aug 2020 | A1 |
| 20200272744 | Kaushik et al. | Aug 2020 | A1 |
| 20200273028 | Zhang et al. | Aug 2020 | A1 |
| 20200273099 | Cella | Aug 2020 | A1 |
| 20200273100 | Cella | Aug 2020 | A1 |
| 20200273101 | Cella | Aug 2020 | A1 |
| 20200273578 | Kutzko et al. | Aug 2020 | A1 |
| 20200274693 | von Vistauxx | Aug 2020 | A1 |
| 20200279045 | Tueno et al. | Sep 2020 | A1 |
| 20200279253 | Ma et al. | Sep 2020 | A1 |
| 20200279260 | Ma | Sep 2020 | A1 |
| 20200279324 | Snow et al. | Sep 2020 | A1 |
| 20200279325 | Snow et al. | Sep 2020 | A1 |
| 20200279326 | Snow et al. | Sep 2020 | A1 |
| 20200280430 | Tueno et al. | Sep 2020 | A1 |
| 20200280431 | Ma et al. | Sep 2020 | A1 |
| 20200280553 | Simons | Sep 2020 | A1 |
| 20200286083 | Ma et al. | Sep 2020 | A1 |
| 20200286092 | Zhang et al. | Sep 2020 | A1 |
| 20200286170 | Kramer et al. | Sep 2020 | A1 |
| 20200293643 | Wang | Sep 2020 | A1 |
| 20200294128 | Cella | Sep 2020 | A1 |
| 20200294129 | Cella | Sep 2020 | A1 |
| 20200294131 | Cella | Sep 2020 | A1 |
| 20200294132 | Cella | Sep 2020 | A1 |
| 20200294133 | Cella | Sep 2020 | A1 |
| 20200294134 | Cella | Sep 2020 | A1 |
| 20200294135 | Cella | Sep 2020 | A1 |
| 20200294136 | Cella | Sep 2020 | A1 |
| 20200294137 | Cella | Sep 2020 | A1 |
| 20200294138 | Cella | Sep 2020 | A1 |
| 20200294139 | Cella | Sep 2020 | A1 |
| 20200294158 | Karame et al. | Sep 2020 | A1 |
| 20200295926 | Androulaki et al. | Sep 2020 | A1 |
| 20200296128 | Wentz | Sep 2020 | A1 |
| 20200302523 | Cella | Sep 2020 | A1 |
| 20200302525 | Cella | Sep 2020 | A1 |
| 20200304284 | Markram et al. | Sep 2020 | A1 |
| 20200304290 | Coulmeau et al. | Sep 2020 | A1 |
| 20200304293 | Gama et al. | Sep 2020 | A1 |
| 20200310767 | Mallon et al. | Oct 2020 | A1 |
| 20200311300 | Callcut et al. | Oct 2020 | A1 |
| 20200311566 | Ackerman et al. | Oct 2020 | A1 |
| 20200311695 | Cao et al. | Oct 2020 | A1 |
| 20200311720 | Zhang et al. | Oct 2020 | A1 |
| 20200311816 | Calvin | Oct 2020 | A1 |
| 20200313886 | Poeppelmann | Oct 2020 | A1 |
| 20200319853 | Tanaka et al. | Oct 2020 | A1 |
| 20200320043 | Sen et al. | Oct 2020 | A1 |
| 20200320206 | Cammarota et al. | Oct 2020 | A1 |
| 20200320340 | Wentz | Oct 2020 | A1 |
| 20200320481 | Narayanan | Oct 2020 | A1 |
| 20200320825 | Simons | Oct 2020 | A1 |
| 20200322125 | Veugen | Oct 2020 | A1 |
| 20200322127 | Lozac'h et al. | Oct 2020 | A1 |
| 20200326937 | Levin et al. | Oct 2020 | A1 |
| 20200327250 | Wang et al. | Oct 2020 | A1 |
| 20200327252 | McFall et al. | Oct 2020 | A1 |
| 20200327254 | Abilash et al. | Oct 2020 | A1 |
| 20200327378 | Smith et al. | Oct 2020 | A1 |
| 20200327546 | Pennington et al. | Oct 2020 | A1 |
| 20200327609 | Dubrofsky | Oct 2020 | A1 |
| 20200334669 | Makowski | Oct 2020 | A1 |
| 20200334776 | Hasan | Oct 2020 | A1 |
| 20200335107 | Hahn et al. | Oct 2020 | A1 |
| 20200336292 | Soriente et al. | Oct 2020 | A1 |
| 20200336468 | Marchese-Ribeaux | Oct 2020 | A1 |
| 20200336470 | Kravitz et al. | Oct 2020 | A1 |
| 20200342118 | Yeo et al. | Oct 2020 | A1 |
| 20200342331 | Takenouchi | Oct 2020 | A1 |
| 20200342452 | Diamond | Oct 2020 | A1 |
| 20200342528 | Zhu et al. | Oct 2020 | A1 |
| 20200342529 | Zhu et al. | Oct 2020 | A1 |
| 20200342530 | Zhu et al. | Oct 2020 | A1 |
| 20200344049 | Yasuda et al. | Oct 2020 | A1 |
| 20200344060 | Munson et al. | Oct 2020 | A1 |
| 20200349054 | Dai et al. | Nov 2020 | A1 |
| 20200349274 | Miller et al. | Nov 2020 | A1 |
| 20200349435 | Gupta et al. | Nov 2020 | A1 |
| 20200349563 | Lu et al. | Nov 2020 | A1 |
| 20200351078 | Kolte et al. | Nov 2020 | A1 |
| 20200351083 | Bartolucci et al. | Nov 2020 | A1 |
| 20200351089 | Wentz | Nov 2020 | A1 |
| 20200351098 | Wentz | Nov 2020 | A1 |
| 20200351253 | Treat et al. | Nov 2020 | A1 |
| 20200351258 | Simons | Nov 2020 | A1 |
| 20200351657 | Wentz | Nov 2020 | A1 |
| 20200356085 | Wentz et al. | Nov 2020 | A1 |
| 20200356689 | McEnroe et al. | Nov 2020 | A1 |
| 20200357031 | Schroepfer et al. | Nov 2020 | A1 |
| 20200358187 | Tran et al. | Nov 2020 | A1 |
| 20200358594 | Becher et al. | Nov 2020 | A1 |
| 20200358595 | Ma et al. | Nov 2020 | A1 |
| 20200358599 | Baracaldo Angel et al. | Nov 2020 | A1 |
| 20200358601 | Gama et al. | Nov 2020 | A1 |
| 20200358610 | Yeo et al. | Nov 2020 | A1 |
| 20200358611 | Hoang | Nov 2020 | A1 |
| 20200358746 | Soon-Shiong et al. | Nov 2020 | A1 |
| 20200359207 | Lee et al. | Nov 2020 | A1 |
| 20200359222 | Lee et al. | Nov 2020 | A1 |
| 20200359550 | Tran et al. | Nov 2020 | A1 |
| 20200359582 | Tran et al. | Nov 2020 | A1 |
| 20200364456 | Tran et al. | Nov 2020 | A1 |
| 20200364700 | Lin | Nov 2020 | A1 |
| 20200364703 | Joveski et al. | Nov 2020 | A1 |
| 20200364704 | Qi | Nov 2020 | A1 |
| 20200366459 | Nandakumar et al. | Nov 2020 | A1 |
| 20200366460 | Han et al. | Nov 2020 | A1 |
| 20200366487 | Neve De Mevergnies et al. | Nov 2020 | A1 |
| 20200366503 | Zhang et al. | Nov 2020 | A1 |
| 20200372145 | Cramer | Nov 2020 | A1 |
| 20200374100 | Georgieva et al. | Nov 2020 | A1 |
| 20200374103 | Cheon | Nov 2020 | A1 |
| 20200374118 | Maim | Nov 2020 | A1 |
| 20200374135 | Lu et al. | Nov 2020 | A1 |
| 20200374270 | Mishra | Nov 2020 | A1 |
| 20200380476 | Trudeau et al. | Dec 2020 | A1 |
| 20200382274 | Williams et al. | Dec 2020 | A1 |
| 20200382288 | Solomon et al. | Dec 2020 | A1 |
| 20200382299 | Tanaka et al. | Dec 2020 | A1 |
| 20200382325 | Simplicio, Jr. et al. | Dec 2020 | A1 |
| 20200382478 | Voell et al. | Dec 2020 | A1 |
| 20200382510 | Dunjic et al. | Dec 2020 | A1 |
| 20200387777 | Vestimehr et al. | Dec 2020 | A1 |
| 20200387891 | Paschini et al. | Dec 2020 | A1 |
| 20200387893 | Maim | Dec 2020 | A1 |
| 20200387896 | Tran et al. | Dec 2020 | A1 |
| 20200387965 | Cella | Dec 2020 | A1 |
| 20200387966 | Cella | Dec 2020 | A1 |
| 20200387967 | Cella | Dec 2020 | A1 |
| 20200387968 | Cella | Dec 2020 | A1 |
| 20200389292 | Bartolucci et al. | Dec 2020 | A1 |
| 20200389298 | Saxena et al. | Dec 2020 | A1 |
| 20200389301 | Detres et al. | Dec 2020 | A1 |
| 20200389303 | Kim et al. | Dec 2020 | A1 |
| 20200394287 | Mucciolo et al. | Dec 2020 | A1 |
| 20200394518 | Sirdey et al. | Dec 2020 | A1 |
| 20200394652 | Youb et al. | Dec 2020 | A1 |
| 20200394708 | Cella | Dec 2020 | A1 |
| 20200394709 | Cella | Dec 2020 | A1 |
| 20200396065 | Gutierrez-Sheris | Dec 2020 | A1 |
| 20200402073 | Tang et al. | Dec 2020 | A1 |
| 20200402171 | Isshiki et al. | Dec 2020 | A1 |
| 20200402623 | Carl et al. | Dec 2020 | A1 |
| 20200402625 | Aravamudan et al. | Dec 2020 | A1 |
| 20200403772 | Gentry et al. | Dec 2020 | A1 |
| 20200403781 | Gentry et al. | Dec 2020 | A1 |
| 20200404023 | Zhu et al. | Dec 2020 | A1 |
| 20200410134 | Bhowmick et al. | Dec 2020 | A1 |
| 20200410399 | Lang et al. | Dec 2020 | A1 |
| 20200410585 | Austin et al. | Dec 2020 | A1 |
| 20200412550 | Zhang | Dec 2020 | A1 |
| 20200412702 | Torres et al. | Dec 2020 | A1 |
| 20200412715 | Chen et al. | Dec 2020 | A1 |
| 20210004493 | Breskvar | Jan 2021 | A1 |
| 20210004502 | Johns | Jan 2021 | A1 |
| 20210005112 | Furukawa | Jan 2021 | A1 |
| 20210012029 | Gustafsson et al. | Jan 2021 | A1 |
| 20210012282 | Smith et al. | Jan 2021 | A1 |
| 20210012335 | Zhu et al. | Jan 2021 | A1 |
| 20210012416 | Zhu et al. | Jan 2021 | A1 |
| 20210012419 | Zhu et al. | Jan 2021 | A1 |
| 20210012421 | Kramer et al. | Jan 2021 | A1 |
| 20210012433 | Zhu et al. | Jan 2021 | A1 |
| 20210014047 | Guim Bernat et al. | Jan 2021 | A1 |
| 20210014063 | Arora et al. | Jan 2021 | A1 |
| 20210014071 | Zhang | Jan 2021 | A1 |
| 20210014150 | Munson et al. | Jan 2021 | A1 |
| 20210018953 | Ford | Jan 2021 | A1 |
| 20210019143 | Landman | Jan 2021 | A1 |
| 20210019792 | Preston et al. | Jan 2021 | A9 |
| 20210019893 | Ananthanarayanan et al. | Jan 2021 | A1 |
| 20210021606 | Gvili | Jan 2021 | A1 |
| 20210082044 | Sliwka | Mar 2021 | A1 |
| 20210342836 | Cella | Nov 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 2019372344 | May 2021 | AU |
| 2019372344 | May 2021 | AU |
| 3018377 | Sep 2015 | FR |
| WO2016120826 | Aug 2016 | WO |
| WO2016120826 | Aug 2016 | WO |
| WO-2019217555 | Nov 2019 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 62968496 | Jan 2020 | US |
