In secure multiparty computation, the enemy of practicality is not usually raw computation — it is rounds. Every back-and-forth of messages between the parties adds a network round-trip, and over a wide-area network those round-trips dominate latency. An MPC protocol that is theoretically elegant but needs many rounds can be useless for anything interactive, like a payment.

US11784803B2, “Round-efficient fully secure solitary multi-party computation with honest majority,” granted to Visa International Service Association on October 10, 2023, is explicitly about that bottleneck. Classified under H04L 9/085 (secret sharing) with signature codes, its title front-loads the three properties that matter: round-efficient, fully secure, honest-majority.

“Several round-efficient solitary multi-party computation protocols with guaranteed output delivery are disclosed. A plurality of input devices and an output device can collectively perform a computation using methods such as fully homomorphic encryption.”— U.S. Patent No. 11,784,803 source

Each of those terms is load-bearing. “Solitary” means a single designated party receives the output — a common real-world pattern where one entity needs the answer and the others are contributing private inputs. “Honest majority” is the trust assumption that more than half the parties follow the protocol, which buys stronger guarantees and simpler constructions than the dishonest-majority case. “Round-efficient” is the optimization the patent claims over that setting. And “guaranteed output delivery” is the strongest robustness notion in MPC: even if some parties are corrupt and try to abort, the honest output party still either gets the correct result or learns the computation was compromised.

The independent claim shows how those properties are mechanized. Claim 1 sits at one input device and threads several cryptographic steps together: it encrypts an input share with a public key, signs the encrypted input “with a signing key to form a signature,” and transmits that encrypted-input-plus-signature tuple to the other input devices. It then receives the others' tuples, “verifies that the input device received another tuple from each,” and “verifies the one or more other signatures using the one or more other encrypted inputs and one or more verification keys.” Only validated inputs survive: the device “determining a plurality of valid encrypted inputs,” “computing a first encrypted output using the plurality of valid encrypted inputs,” then “partially decrypting the first encrypted output with a first secret key share” before sending the partial decryption to the receiving device. The output party combines all the partial decryptions to recover the result — classic threshold decryption, where no single party holds the full key.

The robustness and accountability machinery lives in the dependent claims, and it leans on zero-knowledge. Claim 5 adds an “input proof… proving that the encrypted input was generated correctly,” signs that proof along with the ciphertext, and adds a “decryption proof… proving that the first partially decrypted output was partially decrypted correctly,” all verified against a “common reference string.” That CRS-plus-proof structure is how the protocol catches a corrupt party who supplies a malformed input or a bad partial decryption. Claim 6 supplies the guaranteed-output-delivery fallback: if a device fails to receive a tuple from every peer, or fails to verify a signature or input proof, then “instead of transmitting the second tuple to the receiving device,” it transmits the raw input share so the receiver can finish the computation directly — the protocol degrades gracefully rather than aborting. Claim 17 discloses an alternative construction built on garbled circuits and per-excluded-party “intermediate protocols,” underscoring that the patent claims a family of round-efficient solitary-MPC protocols, not a single one.

The receiving party's view is claimed separately, and reading it clarifies how the threshold decryption actually closes. Claim 10 sits at the receiving device: it collects a first set of tuples (each an encrypted input plus a signature), then a set of additional tuples each carrying “a first encrypted output and a partially decrypted output… partially decrypted by a corresponding input device… using a secret key share.” It verifies it received a tuple from every input device, verifies each signature, recomputes the encrypted output itself, partially decrypts that with its own “receiving secret key share,” and finally combines its partial decryption with all the others “thereby generating a decrypted output.” No party ever holds the full decryption key; the output emerges only when enough partial decryptions are combined. Claim 15 adds the accountability layer at the receiver — it builds and signs “a list of validated and invalidated tuples,” distributes it, and the input devices generate their partial decryptions only over the validated set. That published, signed validity list is how the protocol pins down exactly which inputs counted, so a corrupt party cannot later dispute the result or smuggle in a malformed contribution.

Why a payments network cares is straightforward: latency budgets at the point of sale are brutal, and any cryptographic protocol that wants to run inside a transaction has to be round-frugal. The combination here — threshold FHE-style encryption for the inputs, signatures and zero-knowledge input/decryption proofs for integrity, and an input-share fallback for liveness — is engineered precisely so an honest output party gets a correct answer in few rounds even when a minority misbehaves. The inventor team — Badrinarayanan, Mukherjee, Ravi, Miao — overlaps with serious academic MPC work, and the same Visa research group shows up across the biometric and MPC filings, marking a coherent program.

Per the desk's discipline: issued grant (B2), not an application; a protocol-method claim, not a deployed product. A round-efficiency patent is a claim to a construction, not proof that a particular transaction flow uses it.

For the reader tracking the field, this is the maturation signature: the early MPC patents asked “can we do this securely?”; the 2023-era ones ask “can we do it in two rounds instead of five, and still guarantee an output when someone cheats?” When the IP shifts to round counts, threshold decryption, and concrete robustness fallbacks, the technology is being engineered for production, not demonstrated for a paper.