TextWise and Innography® have announced a strategic partnership to incorporate TextWise semantic search into Innography’s intellectual property business intelligence solution. The new functionality available with Innography® Fall ’10™ enables Innography customers to perform contextual semantic search using specific patent numbers or long blocks of text as the query.

“TextWise facilitates near effortless querying for patent searchers and we’re pleased to be working with Innography as the leader in IP business intelligence,” says Connie Kenneally, President of TextWise. “The incorporation of our technology into Innography’s latest release mitigates the need to perform repetitive searches that rely solely on identifying keywords to generate relevant search results. In contrast, our semantic search performs well with very long queries and one does not have to find the perfect keyword combinations to get the most relevant results.”

A TextWise search is performed by incorporating the full context of either a paragraph, claim, abstract or any longer piece of text to generate more relevant matches to similar information contained in the US patent database. “TextWise takes an innovative approach to facilitating rapid identification of patents for monetizing IP assets when coupled with Innography’s intellectual property business intelligence solution,” said Doug Miller, Chief Marketing Officer at Innography. “Our customers have expressed great interest in patent semantic search, so we are very pleased to be offering this new functionality as an option with their Innography subscriptions.”

The target areas where this joint offering would be most advantageous are:
• Expediting products for clearance from infringing on other offerings
• Rapid idea screening for patenting
• Lead identification for patent licensing, sales and patent acquisitions
• NPE defense / invalidity protection

A demonstration of Innography Fall ’10™, including the TextWise patent semantic search feature, can be found at: http://innography.com/assets/files/fall10demo/fall10-demo.html.

About Innography
Innography® delivers a comprehensive, online Intellectual Property Business Intelligence (IPBI) application that enables companies of all types and sizes to achieve the optimal return on their IP investments. By correlating patent and trademark data with financial, litigation and other key business information, Innography instantly generates a variety of unique visualizations to help organizations reduce the time it takes to perform IP research and reduce associated legal expenditures. This enables corporations to get products to market faster, uncover new and more lucrative revenue sources, keep better track of competitors, manage litigation claims, and stay on top of additional IP-associated functions. Visit www.innography.com to view a brief online product demo or call 1.512.306.8688 for more information.

Consider how we humans learn language. Even with formal education, it takes a child about 15 years starting from infancy to be able to read and understand general news articles in the New York Times. Over this period, one would probably hear or read at least on the order of 10 billion words. Even so, most high schoolers will need many additional years of schooling to become able to comprehend technical material.

So, how can anyone expect a computer to understand something like medical text after training on only about 100 million words of data? A computer of course runs on nanosecond cycles while the human brain operates on millisecond cycles; but we have had about 50,000 generations to evolve our language software, while the electronic computer has had only about 10 generations.

The bottom line here is that language learning is difficult; and it requires sifting through immense amounts of data. There probably is no magic technological shortcut here, but we have reached now the stage where our systems can routinely handle the volumes of data that would support semantic capabilities equivalent to an 8th-grade education. Decent commercial language processing tools are also now available.

Consequently, we are making major progress on semantic dictionaries, but have to be realistic about the work still ahead of us. Expect no overnight miracles from us or anyone else, especially when these are based on measly samples of data. There is still no royal road to semantics.

In Chapter 8 of Lewis Carroll’s “Alice Through the Looking Glass,” our intrepid logical adventurer is talking to the White Knight, who wants to sing to her. He says, “The name of the song is called ‘HADDOCK’S EYES.’”

It turns out of course that the name of the song is really “THE AGED AGED MAN,” though the song is actually called “WAYS AND MEANS.” The confusion here about naming is quite understandable to anyone who has ever ordered TenderSweet™ clams at HoJo’s and discovered that they are neither tender nor sweet.

All of this would be hilarious except that we have to build semantic dictionaries that must deal extensively with the meaning of names in text. This problem will take a while to talk about adequately; and so please tune in tomorrow.

This posting will probably make the eyes of most people glaze over, but current and prospective users of our SemanticHacker API should really be informed consumers. So think of this as being like one of those federally mandated labels on your bottle of Red Bull.

The ingredients of a semantic dictionary are a set of hundreds of thousands of terms, a set of thousands of dimensions, and various numbers expressing the strength of association between a given term and a given dimension. Most of these associations will have zero strength, indicating that we have no information about them; but there will still be millions of non-zero numbers to provide a rigorous undergirding for statistical semantics.

We build a semantic dictionary by obtaining large training samples of documents relevant to each of its dimensions. The strength of association is then estimated as being proportional to the relative frequency of occurrence in training documents for a term in a dimension versus in those for all other other dimensions. The process is actually more complicated than this, but the differences are just refinements of the overall scheme as described.

Now we all understand what terms are (e.g. britney_spears, midfielder, rugelach, purple), but where do dimensions come from? The answer is that they are somewhat arbitrary. A dimension can be defined around any kind of category for which someone has provided requisite training documents. In many cases, we can find prior sets of categories to work from (ODP, USPTO), but we also can ourselves try to infer categories from some available pool of potential training data.

However we proceed here, it is necessary that the resulting dimensions be pertinent to an application of interest, be independent of each other, be supported by adequate training data, and be associated with enough terms to support semantic analysis of target text. This all can be tricky to achieve, but if it were easy, everyone would be doing it.