Thank you for taking the time to reply. We have so far kept things proprietary and we do have patents. We've done several proof of concepts with very large comp

Thank you for taking the time to reply. We have so far kept things proprietary and we do have patents. We've done several proof of concepts with very large companies and they've been successful and moving forward. We have a "partnership" with a very recognizable IT company that reviewed our technology. However, the sales cycle is really long and a lot of "that's too good to be true" - so thinking about the ubiquitous path. I started programming in 1982 - so I've seen a lot and understand the skepticism. However, the choices made in the 70's about indexing (BTrees) aren't the best choice for a highly parallel, distributed world. Plus BTrees order the data, so they'll likely never work for "secret" indexing. For instance, it is quite amusing - all of the interest in fully homomorphic encryption and it being the holy grail if they can just make it fast enough. FHE is a secure computation technology, not a scalable search technology. Let's say you have 1 billion records - with FHE, you'd have to evaluate all 1 billion records for every query (which would take days at best current rate of 1 million evals per hour). As soon as you index those 1 billion records to avoid that with a BTree, you are subject to substantial inference risk because the records would be ordered. So, without an index that has limited inference risk, FHE is DOA for indexing/search (it is too slow regardless). If you have that index with limited inference risk, you don't need FHE for indexing/search. I would argue that our data structures for indexing data are ready for an update - in a world with exploding volume and velocity of data and huge security and privacy risk. Think about it, one hacker breaches a database server today and they get everything. If we keep concentrating valuable info like this, it'll keep getting stolen. Again, appreciate your reply.