_Please clarify the specific new high-risk technical innovation you are proposing to develop, and explain how you will be able to create a defensible competitive advantage. Many systems of this general type have been studied in the past._ Below is an example of a virtual keypad with 4 keys and 4 emojis per key. Suppose my icons are 😍🀒🀐πŸ₯Έ. At the keypad terminal, I'd enter: 1,4,4,2 ``` _key1_ _key2_ | πŸ˜ƒπŸ˜ | | πŸ₯ΈπŸ€© | | πŸ˜‡πŸ˜Ž | | πŸ€“πŸ₯³ | ----- ----- _key3_ _key4_ | πŸ₯ΊπŸ€― | | πŸ«₯πŸ€₯ | | 😑πŸ₯Ά | | 🀒🀐 | ----- ----- ``` After I successfully authenticate, my keypad gets shuffled. When I make another purchase, I'd enter 1,2,1,1 ``` _key1_ _key2_ | πŸ«₯😍 | | πŸ₯ΈπŸ€₯ | | πŸ˜‡πŸ€ | | 🀒πŸ₯³ | ----- ----- _key3_ _key4_ | πŸ˜ƒπŸ€― | | πŸ₯ΊπŸ€© | | 😑😎 | | πŸ€“πŸ₯Ά | ----- ----- ``` This design thwarts credit card (cc) skimmers because they steal the cc number and log the zip code or debit card PIN. With nKode, skimmers would have to incorporate a camera to monitor the screen as well. What's more, they'd have to watch a user enter their nKode 5 times (based on our work with McCrary) to determine the nKode. Most skimmers are left on a cc terminal for at most a day. Thieves try to collect a few hours' worth of transactions, retrieve their skimmer, and move on to the next store to avoid getting caught and losing their skimmer (and the stolen data). The combination of requiring a camera and requiring multiple observations of the same cc/debit card on the same terminal over the course of a day is impractical. It's rare for one person to use a cc on the same terminal 5 times over the course of a week, let alone a day. There aren't any authentication systems that work like nKode. It is the first change to something-you-know authentication since MIT first invented username/password. At Arcanum, we advertise nKode, a pictographic passcode in the shape of a keypad, but our patent covers a broad range of designs and attributes. The keypad design is well-suited for PoS/ATMs, with a virtual keypad on the screen that mirrors the physical keypad on the terminal; however, nKode is not limited to icons or keypad shapes. For the visually impaired, our patent covers audio attributes grouped into keys. For numeric data such as SSNs, keypad attributes can be entirely numeric. In desktop/mobile applications, icons can remain static while key numbers move to them. For example, the nKode displayed below can be entered on a keyboard. With icons 😍🀒🀐πŸ₯Έ, a user would type 1,2,1,1, the same as the second keypad above. ``` πŸ˜ƒ:3, πŸ₯Έ:2, πŸ₯Ί:4, πŸ«₯:1 😍:1, 🀩:4, 🀯:3, πŸ€₯:2 πŸ˜‡:1, πŸ€“:4, 😑:3, 🀒:2 😎:3, πŸ₯³:2, πŸ₯Ά:4, 🀐:1 ``` With the keypad arranged like it is above, the keys don't need to be numeric either. ``` πŸ˜ƒ:c, πŸ₯Έ:b, πŸ₯Ί:d, πŸ«₯:a 😍:a, 🀩:d, 🀯:c, πŸ€₯:b πŸ˜‡:a, πŸ€“:d, 😑:c, 🀒:b 😎:c, πŸ₯³:b, πŸ₯Ά:d, 🀐:a ``` In summary, nKode's moat is that we have a patent that covers a broad range of attributes: images, emojis, alphanumeric symbols, sounds, textures (like braille), and shuffles them in spatial(keys), auditory, tactile, or alphanumeric groups. CISOs and users want nKode. Users like nKode because it's easy to remember. CISOs want it because it eliminates key-logging, shoulder surfing, and password reuse.