Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
  • G06F16/33—Querying
  • G06F16/3331—Query processing
  • G06F16/3332—Query translation
  • G06F16/3338—Query expansion

Definitions

• This invention relates generally to computers and, more specifically, to information management and/or research systems.
• FlG. 1 is an Ontology Objects Table Data and Index Model according to an embodiment of the invention
• FIG. 2 is an Ontology Semantic Links Table Data and Index Model according to an embodiment of the invention
• FIGS. 3-6 are screenshots illustrating principles of at least one embodiment of the invention.
• FIG. 7 is a Table Showing Semantic Search Qualifiers and Corresponding Predicates according to an embodiment of the invention.
• FIG. 8 is a screenshot illustrating principles of at least one embodiment of the invention.
• FIGS. 9-12 are screenshots illustrating principles of at least one embodiment of the invention.
• Entities can include digital representations of abstract, personalized context. There may be competing entities within a community of knowledge. In one embodiment, users create and share entities INDEPENDENT of knowledge sources. In one scenario, an Entity Market could develop where domain experts could get bragging rights for creating and sharing the best entities in a given context. Human librarians could focus on creating and sharing the best entities for their organizations, based on their knowledge of ongoing projects and researchers' intent. Entities could even be shared across organizational boundaries by independent domain experts.
• Tn one embodiment, users can be able to save and email entities to each other. The best entities will win. Again, this is natural.
• a user can be able to open an entity (sent, say, via email) in the Librarian and then drag and drop that entity to a Knowledge Community like Medline. Again, the entity is INDEPENDENT of the knowledge source. The entity could be applied to ANY knowledge source in ANY profile. With entities, context (and NOT content) is important. [0015] In one embodiment, example of entities that would map to recent "debates on context" are:
• CRISP HIV Infection
• CRISP Immunologic Assay and Test
• KIS Knowledge Integration Service
• this allows the user to easily specify a qualified keyword that the KlS can interpret semantically. This can significantly aid usability, especially for those users that might not care to browse the ontologies, and for access from the simple Web UI.
• the query, "Find all chemicals or chemical leads relevant to bone diseases and available for licensing" can now be specified simply as:
• the following rules may be used in various embodiments of the invention to achieve semantic stemming.
• Each of the rules may be practiced independently of the others or in combination with one or more rules.
• the rules themselves may be altered, reduced, or augmented with various steps as may be necessary.
• the KIS preferably maps *: to ALL supported ontologies and intelligently generates a semantic query (alternatively, the user can specify an ontology name to restrict the semantic interpretation to a specific ontology fl e.g., "MeSH:bone diseases").
• This implementation turned out to be non-trivial because the KIS smartly prunes the query in order to guarantee fast performance. In one embodiment, the following pruning rules may be employed.
• OLM Ontology Lookup Manager
• the OLM caches the ontologies that the KIS may be subscribed to (via KDSes).
• the ontologies may be zipped by the KDS and/or exposed via [HTTP] URLs.
• the KIS then auto-downloads the ontologies as KDSes may be added to KCs on the KIS.
• the KIS also periodically checks if the ontologies have been updated. If they have, the KIS re-caches the ontologies. When an ontology has been downloaded, it may be then indexed into a local Ontology Object Model (OOM).
• OOM Ontology Lookup Manager
• the data model may be described in detail in the section titled "Semantic Stemming Processor Data and Index Model" below.
• the indexing may be transacted. Before an ontology may be indexed, the KIS sets a flag and serializes it to disk. This flag indicates that the ontology may be being indexed. Once the indexing is complete, the flag may be reset (to 0/F ALSE). Tf the KTS is stopped or goes down while the indexing is in progress, the KIS (on restart) can detect that the flag is set (TRUE). The KIS can then re-index the ontology. This ensures that an incompletely indexed ontology isn't left in the system. In one embodiment, indexed ontologies may be left in the KIS and aren't deleted even when KCs are deleted — for performance reasons (since ontology indexing could take a while).
• the KIS uses the KDS for ontology lookup.
• the fuzzy mapping steps below may be employed.
• the KIS employs the OLM, which invokes a semantic query on the Ontology Table(s) referred to by the semantic query. This first semantic query may get the categories from the semantic keywords (semantic wildcards). If there are multiple ontologies, a batched query can be used to increase performance (across multiple ontology tables in the OOM).
• the modified time of ontologies at the KDS may be the modified time of the ontology file itself and not of the ontology metadata file; this way, if only the ontology XML file may be updated, that would be enough to trigger a KIS ontology- cache update.
• the cache may be pruned after 10,000 entries using FIFO logic.
• the stemmer intelligently picks candidates on a per ontology basis —when fuzzy mapping with the KDS may be employed. This way, selecting one good candidate from one ontology does not preclude the selection of other good candidates from other ontologies - even with a direct (non-fuzzy) match with one ontology.
• fuzzy mapping in one embodiment, more fuzzy logic can be added to map terms in the semantic stemmer to close equivalents — e.g., *: Calcium Channel - Calcium Channel Inhibitor Activity.
• this errs on the conservative side (supersets may be favored more than subsets; subsets may require the same number of terms to qualify as candidates).
• the model still handles this and "bails itself out” (the fuzzy logic, not unlike the ontology imperfections, may be a form of uncertainty). The eventual filters soften the impact of this uncertainty.
• the KIS can add a default concept filter check for ontology or cross-ontology qualified keywords (e.g., "*:bone diseases"). This addition may be only done for rank bucket 0 and/or for All Bets or Random Bets -for non-semantic sub- queries. This offers high precision even with ontology-qualified keywords and/or for semantic knowledge types like Best Bets or Breaking News.
• ontology or cross-ontology qualified keywords e.g., "*:bone diseases”
• this preferably returns results on polyneuritis and on the Guillain-Barre Syndrome, which IS also known as infectious polyneuritis.
• the semantic stemmer preferablyrecognizes ontology name aliases.
• the KIS semantic stemmer can dynamically add a non-semantic concept filter for an ontology qualified concept IF the rank bucket is 0 or if the concept could not be semantically interpreted. This is beautiful because it works for all cases: if the concept could not be interpreted, the non-semantic approximation may be used; if the concept was interpreted and/or the context is semantic (e.g., Best Bets or Breaking News), the non-semantic concept may be not added so as not to pollute the results (since the concept has already been interpreted); if, on the other hand, the rank bucket is 0, the semantics don't matter so adding the concept is a good thing anyway (it increases recall without imposing a cost on precision), even if the concept has already been semantically interpreted.
• a method to the KIS Web Service Interface for the Web Ul integration may be passed a text string (including Booleans) which it can then map to a semantic query.
• the KIS can automatically specify the "since" parameter to the KIS Data Connector (if it detects this) to optimize the incremental indexing path to minimize the number of redundant queries during incremental indexing (since there are much more read-write contention — since it may be a real-time service).
• the KIS may use the system thread-pool and/or EACH KC runtime object can have its own semaphore. This ensures that the KCs don't overwork the KDSes yet increases concurrency by allowing multiple KCs to index as fast as possible simultaneously.
• the central KIS runtime manager holds/increments a work reference count on each document sourced from each connector that may be currently indexing (it releases/decrements it once it is done indexing the document). This fixes a problem where a KC connector would quickly "find" an RSS file and think it was done, even while the items within the RSS file were still being processed and/or indexed.
• the KIS supports broad time-sensitivity settings
• the KIS can map extended characters to English- variants.
• the Guillain-Barre Syndrome can be mapped to Guillain- Barre Syndrome.
• Semantic Wildcards may be also integrated with Deep Info.
• the user may be able to specify a request including (but not limited to) semantic wildcards and/or then navigate the virtual knowledge space using the request as context.
• the KIS returns category paths to the semantic client which can then be visualized in Deep Info (not unlike Category Discovery).
• the user may be then able to navigate the hierarchies and/or continue to navigate Deep Info from there.
• the following are examples of various embodiments of the invention. They may be practiced independently or in combination and/or may be limited or augmented with steps as may be necessary.
• the categories may be visualized in the Deep Info console. And then the tree can be directly invoked by the user to launch a semantic query off a related category once the user discovers a category from his/her launch point (returned categories can be visualized differently from parent categories - perhaps in a different font/color). This could be a profile, keywords, document, entity, etc. In this case, it may be the request itself.
• Another launch point may be the Clipboard — the Deep Info console can have a Clipboard Launch Point (if there is something on the clipboard) for whatever may be on the clipboard. This is very powerful as it would the user to copy anything to the clipboard (text, chemical images, document, etc.), go to the Deep Info and/or then browse/explore without actually launching a request.
• Deep Info metadata can be returned as part of the SRML header (they may be request-specific but result-independent).
• the KIS can preferably handle virtually any kind of semantic query that users might want to throw at it (Drag and Drop and/or entities can provide even more power).
• Wc can prcfcrablyhandlc this query as follows:
• semO.BestBetHint 1 AND semO.PredicateTypelD IN (13,
• Ontology qualified or multi-ontology qualified search terms and the Librarian can semantically highlight relevant terms. So for example, type in Dossier on "*:bone disease" and the semantic client can do the smart thing. This was non-trivial and has some pieces that need to be noted in the docs:
• ontology-qualified terms may be dynamically interpreted based on the current profile, the semantic client maps the terms (e.g., "*:bone disease") to the ontologies for the request profile. It gets tricky shortly thereafter.
• the semantic client figures out the ontologies for the request profile and/or add semantic highlight terms for each of these ontologies.
• going through mutliple ontologies has an impact on performance.
• the user could (in the limit) have a profile with tens of KCs each of which have several different ontologies. As such, a more pragmatic, fuzzy algorithm was called for.
• the following are various embodiments of the invention that may be practiced independently or in combination and/or may be reduced or augmented or altered with steps as may be necessary.
• the Librarian first starts a timer to time the mapping process. This may be configurable and/or can be switched off to have no timer.
• the semantic runtime client preferably waits for the hit generation for 10 seconds (if configured to have a timer). This may be enough time for most queries but also prevents the system from locking up in case the user has a query with, say, 20, cross-ontology qualifiers (this could hang the system).
• This algorithm may be stable and/or provides the user with a very high probability of always getting most or all the right terms (with "*:”) or all the right terms with specific categories or keywords, WITHOUT making the system vulnerable to hangs with, say, arbitrary queries with a profile with many arbitrary KCs.
• the entire system (end-to-end) supports parenthesized category filters.
• the semantic client attempts to explode complex queries.
• the KIS handles all complex Boolean logic so the Librarian doesn't have to do this.
• the XPath query uses double-quotes (consistent with the XPath spec).
• the semantic client excludes ontology and/or highlighting hit cache state from import/export.
• the Librarian can regenerate the hit cache after an import.
• the KIS uses the system thread-pool and EACH KC runtime object preferably has its own semaphore. This ensures that the KCs don't overwork the KDSes yet increases concurrency by allowing multiple KCs to index as fast as possible simultaneously.
• the central KlS runtime manager holds/increments a work reference count on each document sourced from each connector that may be currently indexing (it releases/decrements it once it is done indexing the document).
• Ads in news feeds can be problematic because they can affect the ability of the KIS to semantically filter and/or rank properly. For instance, some web pages contain several times (at times more than 5 times) as much ad content as the actual content for the article.
• some web pages contain several times (at times more than 5 times) as much ad content as the actual content for the article.
• the Safe List may be manually maintained initially. This can contain a list of publisher names that don't include ads. A good example is the Business-Wire which includes press releases. We can manually maintain the Safe List as part of our ASP value proposition. The News Connector can check the Safe List and/or if the publisher is deemed safe, can indicate to the KIS that it can safely index the entire document.
• Content-cleansing uses heuristics, machine learning, and/or layout analysis to automatically detect whether a page has ads. If ads are detected, the service can then attempt to extract the subset of the document that may be the meat of the document (as text) and/or then indicate to the KIS (via RSS signaling) that the PCIS is to index that document.
• Alternate embodiments also detect the "print” icon with the "print” tool tip (or any tool tip with text mapping to any of the above), and/or apply the same rule.
• [001531 Cache the stats on host names for which rule #1 works. Add the host names to a "safe list candidates" file. We then need to validate those candidates and/or add them to the safe list. You also add items to the safe list based on submissions from trusted people (e.g., within Nervana and/or Beta customers).
• ad removal and/or cleansing rules can also be employed at the semantic client during Dynamic Linking (e.g., Drag and Drop or Smart Copy and Paste). For example, if the user drags and drops a Web page, the cleansing rules can first be invoked to generate text that does not contain ads. This may be done BEFORE the context extraction step. This ensures that ads are not semantically interpreted (unless so desired by the user - this can be a configurable setting).
• Dynamic Linking e.g., Drag and Drop or Smart Copy and Paste.
• Figures 1 and 2 illustrate sample tables that may be present in various embodiments of the invention.
• Figures 3-6 illustrate examples of various embodiments of the invention, that are operable, for example, to:
• the Life Sciences News KC can periodically ask the General News KC (during its real-time indexing process) for Breaking News on *:Health OR "*:Health Care” OR “* Medical Personnel” OR *:Drugs OR "* :Pharmaceutical Industry” OR *:Pharmacology OR “*:Medical Practice”
• a KC was populated based on editorial rules, based on tags provided by our news provider, to determine which sources and/or articles may be Life-Sciences-related.
• the Life Sciences (LS) News KC can ALSO point to the General News KIS via the preferred KIS RSS interface.
• the RSS can include a reference to *:Health OR "*:Health Care” OR "* Medical Personnel” OR *:Drugs OR '" ⁇ Pharmaceutical Industry” OR *:Pharmacology OR “*:Medical Practice”
• the LS News KC can index the Health subset of the General Reference KC. This way, we use our own technology for domain-specific filtering.
• the approach described below may be set for the IT News KC and/or ALL Vertical KCs.
• the approach can also be used to funnel (or tunnel, depending on your perspective) traffic from the General Patents KC to the Life Sciences Patents KC (and/or other vertical Patents KCs in the future).
• Step 1 Quick search in COMPENDEX to identify relevant terminology
• Step 2 Develop search strategy using COMPENDEX and INSPEC thesaurus terminology.
• Step 3 Modify search terms for use in WPESfDEX
• Step 4 Identify appropriate IPCs and Manual Codes
• Step 5 Explore Thesauri for Code definitions
• Step 6 Refine strategy
• Step 7 Identify LEXICON terms for a CAplus search
• Step 8 Combine, de-duplicate, sort and display results
• the painful keyword search below may be replaced by a simple Nervana semantic search on an Engineering Patents KC indexed with the Engineering ontology for
• the Information Nervous System adds multi-dimensional semantic ranking which may be currently a manual (and almost impossible) task.
• * may be a preferred and very powerful way for expressing semantic queries in Nervana and provides as close to natural-language queries as may be computationally possible.
• * provides semantic stemming and semantic reasoning to INFER what terms MEAN IN A GIVEN CONTEXT IN A GIVEN PROFILE, NOT synonyms or other word forms of the terms.
• the Information Nervous System (read: The Nervana System) also semantically ranks results with *: queries IN THE CONTEXT of the desired terms/concepts. In the preferred embodiment, this may be NOT the same as mapping the query to a long Boolean query nor may it be the same as ranking the synonyms of the terms.
• a Dossier on "*:bone diseases" AND *:chemicals may be NOT mathematically equivalent to a Boolean search for every type of bone disease (ORed) AND every type of chemical (ORed) BECAUSE OF CONTEXT- SENSITIVE RANKING.
• the KTS on indexing incoming content from news feeds and other sources adds the following logic:
• the KIS can *anonymously* log semantic searches and use those logs to improve our ontologies.
• actual searches are a great window to actual REAL- WORLD vocabularies being used — including typos and/or other word-forms that our ontologies might currently lack.
• this idea relates to an end-to-end ontology improvement service/system (with a Web application and/or Web services) that can allow ontologists to view logs and/or statistics and/or loop that back into the ontology improvement process.
• This may be tied to an ontology management tool via Web services.
• An ontology research and/or development team that can own the statistical analysis of search logs, ontology semi-automation, and/or * distributed* ontology development tools.
• the ontology tools has collaboration functions and/or to be tied into online communities and/or Wikis. Customers may be able to recommend ontology improvements from the Librarian and/or Web UI and/or have that propagated to the ontology analysis and/or development team in real-time.
• the KlS can not go beyond 1000 numbers in the range tag to guard against a DOS attack. This number may be adjusted as may be necessary.
• Deep Info Hyperlinks may be a visual tool in the Information Nervous System, used to complement the Deep Info pane. Deep Info Hyperlinks allow the user of the semantic client to navigate Deep Info not unlike navigating hyperlinks. This allows the user to be able to continuously navigate the semantic knowledge space, via Dynamic Linking, without any limitations based on the size of the knowledge space (which could exceed the amount of available UI real estate in say, a tree view). There may be a Deep Info stack to track "Back,” “Forward” and/or "Home”. For non-root category nodes in Deep Info, there may be an enabled "Up” button to allow the user to navigate to the parent category in a given ontology.
• Deep Info results can be restricted to the first major level in the tree (i.e., a result docs not have a tree expansion which then shows more results — in the same in-place tree UI).
• Context templates special agents or knowledge requests
• the user can navigate to the template itself (e.g., Breaking News) to get more information — e.g., discovered categories with the template/special-agent as a pivot.
• Category hierarchies can be reflected in the tree as deep as may be needed. The user can navigate to a result, category, etc. and/or then continue the navigation from there — without overloading the UI.
• Deep Info Hyperlinks may be indicated with the underlined text. Also, notice the Back, Forward, Stop, Refresh, Home, Mail, and/or Print buttons (no different from a hypertext web browser). The user may be able to navigate the Deep Info knowledge space (via Dynamic Linking) by recursively clicking on the Deep Info Hyperlinks and/or by going "Back" and/or "Forward," as desired. Clicking Home would take the user back to the starting "Deep Info position" (either for application-wide or profile-wide Deep Info or to the context point from where the Deep Info semantic chain was launched). Clicking Refresh would refresh the Deep Info pane, not unlike refreshing a loaded web page in a Web browser. Clicking Stop would stop the pane from loading. Clicking Mail would email the Deep Info XML contents to a person or group of persons. Clicking Print would print the Deep Info pane.
• the Deep Info Hyperlinks also have a drop-down menu to allow the user launch a new request (or entity) corresponding to the clicked Deep Info node.
• each entry in the Deep Info Hypertext space may be a legitimate launch point for a new request, bookmark, or entity.
• the user may be able to create a new request, bookmark, or entity (opened in place or "explored” — opened in a new window).
• the system intelligently maps the current node to a request, bookmark, or entity, based on the semantics of the node. For instance, a category may be mapped to a Dossier on that category (by default and/or exposed in the Ul as a verb/command) or a "topic" entity referring to the category (as another option, also exposed in the UI as a verb/command).
• a context template (special agent or knowledge request) can be mapped to a request with the same semantics and/or with the filter based on the source node (upstream) in the Deep Info pane.
• Some nodes might not be "mappable" (e.g., a category folder) and/or the UI indicates this by disabling or graying out the request launch commands in such cases.
• the clipboard launch point for Deep Info can be automatically updated when the clipboard changes (via a timer or a notification mechanism for tracking clipboard changes) or can be left as is (until the user refreshes the Deep Info Pane).
• the semantic client keeps track of the most recent N clipboard items (via the equivalent of a clipbook) and/or have those exposed in the Deep Info pane.
• the most recent clipboard item may be displayed first (at the top).
• the "current" item then may be auto-refreshed in real-time, as the clipboard contents change.
• the current item on the clipboard (or any entry in the clipbook) may be a f ⁇ le- folder, the Deep Info pane allows the user to navigate to the contents of that folder (shallowly or deeply, depending on the user's preference).
• the Deep Info Minibar may be displayed when the user selects an item (perhaps via a small button the user must click first) and/or has only the result item as an initial launch point (so as not to overload the UI). Also, the Deep Info Minibar includes a Deep Info path with "Annotations" off the result item itself (in addition to all the context templates and/or other Deep Tnfo paths). The Minibar also allows the user to explore — off the result item as a launch point — both the current (contextual) profile and/or other profiles in the system. The user be able to semantically explore Deep Info across profile boundaries.
• the Deep Info pane flags each category in the hierarchy as belonging to Best Bets, Recommendations, or All Bets. This allows the user to visually get a sense of the strength of the Deep Tnfo path (in this case a category) TN THE CONTEXT of the strength of the categories IN THE CONTEXT of the query or document (or the Deep Info source). This may become a hint to the user per how much time and/or effort to spend navigating different paths. So in the example below, the user can have a clear sense that Cardiac Failure may be a Best Bet category, Dementia may be a Recommended category, and/or that Immunologic Assays may be an All Bets category.
• a visual indicator showing if a category is [also] in the news (e.g. Dementia below) - the sample picture shown reads "NEW! but in practice reads "NEWS.”
• the hints represent the relevance of the inferred categories in the corpus itself. Else, in the case of a document, the clipboard, text, etc., the hints represent the INTERSECTION of relevance of the inferred categories in the source AND the corpus (the index).
• the Best Bet hint for a Deep Info category may only be set IF the category (or categories) may be Best Bets in BOTH the source document AND the corpus. Ditto for Recommended categories (the category has to be at least a Recommendation in both source and/or destination). Else, the hint may be indicated as All Bets.
• the model (as described above per flagging categories in context via visual hints) also applies to People.
• Experts may be to be treated as Best Bets on the People axis
• Interest Group may be treated as Recommendations on the People axis
• Newsmakers may be treated as Headlines on the People axis.
• the visual hints preferably would indicate relevance based on Expertise, Interest, and/or News (per newsmakers). These visual hints for discovered categories may be displayed IN ADDITION to the context templates (special agents or knowledge requests) also displayed for the Person/People in question. Tn the preferred embodiment, the symmetric (People) visual hints also supplements the Information hints (Best Bets, etc.).
• the visual hints may be based on direct equivalents in the semantic networks in the KISes in the contextual profile — indeed the Category information returned in the Deep Info query has identical attributes to the BestBetHint, RecommendationHint, BreakingNewsHint, and/or HeadlinesHint in the semantic network. These attributes indicate whether the category is a Best Bet category, a Recommended category, a Breaking News category, or a Headlines category.
• the KIS goes further and/or also return a hint to the semantic client indicating whether the Deep Info source (e.g., John Smith) below is a "Best Bet” (expert per semantic symmetry), "Recommendation” (interest group per semantic symmetry), Breaking News (breaking newsmaker per semantic symmetry) and/or Headlines (newsmaker per semantic symmetry).
• the KIS accomplishes this by querying for these hints from categories in the Objects table (or Categories table in an alternate embodiment) and/or joining this against the People table with the filter indicating whether the person ("John Smith” in this case) has a semantic link to the category.
• Deep Info In Deep Info, as illustrated in the figure above, the user often starts from a category and/or then navigates from there. However, this can be problematic because the category' might not be "understood" (i.e., the category's ontology might not be supported) in other Knowledge Communities in the contextual profile. Semantic wildcards get around this because the interpretation of the context may be performed on the fly - the categories may be inferred in real-time and/or not explicitly specified.
• Deep Info it may be preferable to preserve the seamlessness of the user experience by supporting intelligent and/or dynamic navigation. With documents and/or text (and in some cases, entities), this happens automatically — Dynamic Linking already involves real-time inference and/or mapping of categories. However, with categories as the source context, things get a bit trickier for the reason described above. To address this, the Information Nervous System supports Intelligent Dynamic Linking. If the source category is not understood (as explicitly specified), the KIS can indicate this in the Deep Info result set. However, the KIS can go a step further: it can then attempt to map the explicit category to semantic wildcards simply by adding the '*:' prefix to the category name (off the category path).
• the new result set may be tagged as having been dynamically mapped to semantic wildcards.
• the semantic client can then display a very subtle hint to the user that the Deep Info results were inferred on the fly by the system.
• Dynamic Deep Info Seeking allows the user to seek to Deep Info from any piece of text.
• the user may be able to hover over any highlighted text (with semantic highlighting) and/or then dynamically use the highlighted text as context for Deep Info — the semantic client can detect that the text underneath the cursor is highlighted and/or then use the text as context.
• the result may be selected (if not already) and/or the Deep Info mini-bar invoked with the highlighted text as context (with semantic wildcards added as a prefix - for intelligent processing). This creates a user experience that feels as though the user seeks (without navigating) from a highlighted term to Deep Info on that term.
• this feature may be also extended to hovering over any piece of selected text.
• the user can select the text, hover over it, and/or then seek to Deep Info using the text as context.
• Presence information may be integrated as an additional hint. This indicates whether a displayed user is online, offline, busy, etc.
• the Presence information may be integrated using an operating system (or otherwise integrated) API.
• Verbs may be also be integrated in the Deep Info UI to allow the user to see a displayed user and/or then open an IM message, send email, or perform some other Presence-related action either directly within the Deep Info UI or via an externally launched Presence-based or IM application.
• the Geography ontology allows semantic regional scoping/searching. This allows queries like Dossier on American Politics from General News. This may be invoked as Dossier on *:American *:Politics. Other examples may be:
• this button can allow a Martian who just landed on Earth to create the first pass for an ontology describing previously unknown knowledge domains on Mars. Coming back to Earth, it would allow Nervana to generate a new ontology for domains or sub-domains, perhaps new industries like nanotech, etc.
• the scientific and/or product development part of this involves creating the Red Button to CONSTANTLY scan through documents on the Web and/or other sources and/or generate the ontology based on high-level taxonomic and/or conceptual inferences that can be made.
• the generated ontology may only be a first pass; humans may have to then follow up to refine the ontology.
• this button can allow a user to quickly determine the quality of an ontology. For all our current ontologies, what is the grade? Which gets an A? And which gets an F? Which ontology is so bad that it shouldn't be used in production, period? And why? What is the basis for determining A, B, C, D, E, or F? What is the scale and/or how are grades determined? These grades can then be used for our ontology certification and/or logo program. This can be employed for ontology comparison analysis (A.) are two ontologies semantically similar and if so, how much? B.) is ontology A better than ontology B for knowledge domain K and if so, by how much, and why?).
• A. ontology comparison analysis
• This button may be tied into a real-time ontology monitor
• This monitor can constantly track search logs and/or web logs to determine if an existing ontology may be getting stale or may be otherwise not representative of the domain of knowledge it represents. Search lingo changes and/or the vocabulary around a knowledge domain changes; the real-time ontology monitor can make the "Does this ontology suck?" red button also a "Does this ontology still not suck anymore?” button.
• this button can allow a user to take an existing ontology, integrate it with the real-time ontology monitor, and/or have recommendations made on how to fix or improve the ontology.
• the KIS understands the following qualifiers: [00466] o author: (this restricts the search to the author field)
• filetype this restricts the search to the file extension (e.g.,. filetype:pdf)
• o range a number range (format D range: ⁇ start>- ⁇ end>).
• the model may be also completely extensible - more filters can be added in a backwards compatible way without affecting the system.
• each qualifier has a corresponding predicate which indicates the basis for the semantic link, linking a document (or other information item) to the concept in question.
• Figure 7 illustrates the mapping of the qualifiers to predicates (the actual predicate values may be arbitrary but must be unique).
• events awareness refers to a feature of the Information Nervous System where the system understands the semantics of events (end- to-end) and/or applies special treatment to provide event-oriented scenarios.
• Life Sciences Events can allow knowledge-workers semantically keep track of research conferences, marketing conferences, meetings, workshops, seminars, webinars, etc. For instance, questions like: Find me all research conferences on Gastrointestinal Diseases holding in the US or Europe in the next 6 months.
• this Knowledge Community can be seeded manually and/or then filled out with additional business-development (as needed).
• the seeding would RSS integration (where available) and/or editorial tools (screen-scraping) to generate Event metadata (as RSS) which can then be indexed on a constant basis.
• a special RSS tag indicates to the KIS that an event "expires" at a certain date/time and/or after a certain time-span. When the event "expires" in the KC, the KIS automatically removes it.
• the semantic client may be "aware" of results that may be events and/or can allow users to add events to their Outlook Calendar (or an equivalent). This can be done via a Verb/Task on a selected "event result.”
• the WebUI client allows users set reminders for events.
• the WebUI then emails them just before the event occurs (with a configurable window, not unlike Outlook). So for example, a user may be able to register for reminders (semantic reminders, if you will) for the sample query I indicated below.
• the KIS supports self-aware, expiring events, as described above.
• the KIS and/or the semantic clients also support a new field qualifier, location:, that allows the user to specify the desired location of an Events semantic search. This maps to a new predicate, PredicateTypeID_LocationContainsConcept. Also, there may be a startdate:, enddate:, and/or duration: (event duration) qualifiers with corresponding predicates.
• Drag and Drop dynamic query generation applies to entities, semantic wildcards, smart copy and paste and/or other Dynamic Linking invocation models.
• the query generation rules can result in sequential queries.
• the resultant-query generation rules may be a bit more complicated. If there are multiple Best Bet categories generated from the source (the "dragged" object), the categories may be added to a resultant list. Else, if there is one Best Bet category, the category may be added along with Recommendations categories (if available). Else the Recommendations categories may be added to the resultant list (if available). Else, the All Bets categories may be added (if available). If there are non-semantic entries (as previously described) — for instance key concepts in the title or body — these may be also added to the resultant list. This may be repeated for all SQML filter entries. The resultant categories may be then added to one master semantic query, which may be then invoked with an AND operator.
• the Information Nervous System there aremultiple semantic clients that access services exposed by the Information Nervous System. In one embodiment, this may be done via an XML Web services interface. There may be two additional semantic clients: the Nervana WebUI and/or the Nervana RSS interfaces. [00501] These have several strategic benefits:
• Migration path (can start with WebUI; and/or then migrate to Librarian for power-user scenarios)
• the RSS interface may be also exposed via [HTTP] and/or can be consumed by standard RSS readers.
• the RSS interface emits RSS 2.0 data.
• any WebUI query can be saved as an RSS query which emits RSS 2.0. This can then be consumed in a standard RSS reader.
• the RSS interface automatically creates a channel name as follows: Nervana ⁇ Knowledge Request> on ⁇ Filter>, where ⁇ Knowledge Request> is the knowledge request type (Breaking News, Best Bets, etc.), and/or filter is the search filter.
• Figure 8 illustrates a WebUI interface, in accordance with an embodiment of the invention.
• the Infotype semantic search qualifier may be a powerful and/or special qualifier that may be used to specify information types in the Information Nervous System. The user can ask for Breaking News but only those that may be Presentations. This may be specified as Breaking News on InfoType Presentations .
• the BCIS adds special info predicates corresponding to each information type. This can be a abstraction on top of filetypes — both predicate classes may be added to the semantic network. Furthermore, some infotypes yield other infotypes - e.g., a presentation may be also a document; in such cases, multiple predicate assignments may be issued.
• semantic type semantic search qualifiers may be like infotype qualifiers except that the qualifier tags themselves indicate the semantic type. This makes it clear to the KIS that only a specific predicate based on entity-detection is employed. For instance, "person:john smith" indicates to the KIS that only a concept that has been detected to refer to a person may be included in the semantic search. Or place rhouston indicates only a place called Houston and/or not a name called Houston. And so on. This information may be added to the semantic network by the KTS via semantic type predicates. Examples may be:
• time search qualifiers are pre-defined and/or semantically interpreted qualifiers that refer to absolute or relative time. These don't have to be (nor are they- in the case of relative times) hard-coded into an ontology - they can be interpreted in real-time by the KIS. The KIS then maps these qualifiers to an absolute time (or time range) IN REAL-TIME (resulting in a live computation of the actual time value) and/or then uses the resultant value in the semantic query.
• Examples of queries that may be enabled by time search qualifiers are:
• time ontologies allow the semantic interpretation and/or inference of time-related concepts.
• Examples of time-related concepts may be: “twentieth century,” “the nineties,” “summer,” “winter,” “first quarter,” “weekend” (terms for Saturday and/or Sunday), “weekdays” (have terms for Monday through Friday), etc.
• the triangulation of Time ontologies with Geography ontologies covers the space-time continuum, which is part of reality.
• a similar model may be also applied for numbers — Number Ontologies. This enables queries with concepts like “six-figures,” “in the millions,” etc. This may be also be implemented with number search qualifiers.
• historical ontologies may be like Time ontologies but rather focus on time in the context of specific historical concepts. Examples:
• institutional ontologies may be used as a generic ontologies (like Geography). These have businesses, universities, government institutions, financial institutions, etc. AND their relationships.
• this ontology may be also useful to semantically search for companies and/or other institutions referred to by acronyms (e.g., GE). Also, this ontology handles common typos. Example: “Bristol-Myers Squibb” (correct spelling) vs. "Bristol Myers-Squibb” (very common typo).
• this ontology may be critical for IP searching, for which the ownership of IP is very important.
• Commentary and/or Conversations may be treated differently in terms of their semantic ranking and/or filtering algorithms. This may be because they may be based on publications, annotations, etc. from people in the Knowledge Communities (KCs). The involvement of people may be a critical axis that determines the basis for relevance. For example, take an email message with the body "Sounds good.” or even something as short as "OK.” In a typical knowledge community using only ontology-based semantic indexing, ranking, and/or filtering, these messages might be interpreted as being irrelevant or weakly relevant.
• KCs Knowledge Communities
• the Dynamic Linking model of the Information Nervous System partially addresses this because the user can navigate using different semantic paths to reach the eventual item — the paths then become a legitimate basis for relevance, in addition to — or regardless of— the semantic contents of the item itself.
• the ranking may be biased in favor of time and/or not semantic relevance (not unlike email)
• a model for comparing and/or mapping ontologies may be present.
• the model described here will generate a map that shows how several (2 or more) ontologies may be similar (or not).
• all the scores may be tallied. For every category, a ranked list of every category in every other ontology may be generated (from highest to lowest scores, greater than 0). This then represents the ontology assignment/comparison map. The larger and/or more relevant the corpus to the entire ontology set, the better. This map may be then be used to map categories across ontology boundaries - during indexing.
• federated and/or merged semantic notifications refers to a feature of the Information Nervous System that allows users to have rich semantic notifications from a federation of knowledge communities, organized by profile, and/or across a distributed set of servers.
• every KTS can be configured with a master notification server that it then communicates notifications too (based on a polling frequency and/or on registered user semantic-requests). Federated identity and/or authentication may be used to integrate user identities.
• the master notification servers then merge all the notification results, elide duplicates, and/or then notify the registered user.
• the user can register for notifications from specific KISes (and KCs) which can then notify the users (via email, SMS, etc.).
• notifications can be sent to a Notification Merge Agent which lives centrally on a special KIS.
• This merge agent can then mark all the source profiles (by GUID), merge and/or organize the notification results by profile, and/or then forward the merged and/or organized results to the registered user.
• this refers to a feature to allow the user to get semantic wildcard equivalents from the semantic client categories dialog.
• the categories dialog can have a "Copy to Clipboard" button - enabled only, perhaps, when there may be selected categories. When this button is clicked, the selected categories may be copied to the clipboard as text.
• the user can then go back to the edit control in the standard request or the command line on the Home Page and/or click Paste.
• the user can then change the text to AND, add parentheses, change the wildcard to a specific ontology alias qualifier (e.g., Cancer or MeSH) 5 etc.
• a specific ontology alias qualifier e.g., Cancer or MeSH
• this may be the semantic client namespace item serialization model and/or file formats — for Request, Results, and/or Profiles (and/or other non-container namespace items) Saving and/or Sharing (e.g., email):
• a request may be saved (or emailed) as a Zipped folder (read: an easily sharable file).
• read an easily sharable file.
• the Zipped folder can contain the following files and/or folders:
• results (this folder can contain the results as they were when they were saved):
• the request is a Dossier, there may be one XML file for each request type
• the HTML file may be a report generated from the results XML. It can have lists and/or a table showing each result and/or it metadata. Also (from a usability standpoint), it can have hyperlinks to the result pages, which a TXT file would not have.
• request (Original Profile) (this folder can contain the XML (SQML) that represents the semantic query/request AS IT WAS WHEN IT WAS SAVED)
• Request Info.HTM (this file can describe the request, its filters and/or the original profile, including the names of its KCs and/or category folders)
• This file can also contain the metadata for the request - e.g., the creation date/time, the last modified date/time, the request type, the profile name, etc.
• request (Any Profile) (this folder can contain the XML (SQML) that represents the semantic query/request WITHOUT ANY PROFILE INFORMATION)
• the request XML can contain all the state in the original request, but only, perhaps, with the request filters, excluding the KCs for the request profile. This allows other users to view the request in their own profiles, if the filters are what they find interesting]
• Request Info.HTM (this file can describe the request and/or its filters)
• This file can also contain the metadata for the request — e.g., the creation date/time, the last modified date/time, the request type, etc.
• This file can describe the contents of the folder
• This file can also contain the metadata for the request - e.g., the creation date/time, the last modified date/time, the request type, etc.
• the Zipped folder name can be prefixed with "Nervana.”
• a similar model may be employed for serializing profiles - profiles contain folders with each request, in addition to the profile settings. [00605] Why the ZIP Format?
• Zip is an open format with broad industry support. Zip management may be preferably built into Windows XP allowing for easy management of the saved request and/or results. Furthermore, there may be many third-party Zip SDKs for customers that might want to generate reports from saves Nervana requests/results. For example, a customer might want to write an application that scans through file or Web folders containing saved Nervana requests/results, extracts the contents from the Zip folders, and/or then manipulates, analyzes, aggregates, or otherwise manages the saved RSS results within each zipped folder. So a customer (say, Zymogenetics) can have an application that monitors a shared folder, opens the zipped Nervana folders, and/or then aggregates the RSS results (from different requests) to, say, database tables or spreadsheets for analysis.
• Zip can provide backward and/or forward compatibility for the "format.” Old versions of the Librarian may be able to "open” requests from future versions and/or vice-versa. Zip would also allow us (in large measure) to add and/or remove components from the "format” without affecting the core of the "format.”
• Newsmakers refers to authors of inferred news (within one or more agencies or knowledge communities) in a given context.
• Newsmakers may be "known" (provable identities) within a user's knowledge communities.
• Newsmakers may be members of agencies (knowledge communities) so a user can continue to navigate with a newsmaker as the virtual pivot object - a user can find a Newsmaker, navigate to Headlines by that Newsmaker, drag and drop one of those Headlines to find semantically relevant Best Bets, navigate to the Interest Group for one of those Best Bets, etc.
• Newsmakers can also be people featured in the news - the system maps extracted concepts, performs entity detection to detect names, and/or attempts to authenticate those names against names in the agency. The system can then assign a similar (but not identical) Newsmaker predicate that indicates that the semantic link has uncertainty ( e -g- 5
• the "Newsmaker" context template query can then include this predicate as part of the Newsmaker query — but in some cases, the predicate can also be excluded (this model preserves flexibility). In the preferred embodiment, the authors may be authenticated by their email address so this problem wouldn't occur.
• Newsmakers may be authenticated authors (and/or members of the agency (knowledge community)).
• a separate "In the News” query can be generated for entities (including unauthenticated people) that may be featured in the news.
• RSS Commands/Verbs may be special signals embedded in RSS that direct the KTS to take actions on specific information items. These may be specified with namespace-qualified elements that correspond to specific verbs that the KIS invokes. Examples:
• metaansert or meta:add constructs the KIS to index the RSS item
• metardelete or meta:remove instructs the KIS to delete the RSS item
• n the total number of keywords that are semantically relevant to all the filters in the query.
• k the number of semantic or keyword filters in the query.
• the order of magnitude of total number of combinations may be by which the n items can be arranged in sets of k may be represented by the formula:
• Bone Diseases currently has a total of 308 keywords representing the many types of bone diseases and/or their synonyms and/or word variants.
• Chemical has a total of 5740 keywords representing the very many number of chemical compounds and/or their synonyms and/or word variants.
• a staging server hosts a daemon which downloads news items and/or then indexes them in an intermediate staging index.
• This index may be then divided up into multiple channels - allowing for indexing scale-out (with each KIS indexing one channel). More channels can then be added to provide more parallelism and/or less simulatenous read-write (while indexing) — in order to improve both query and/or indexing performance.
• Examples of channels may be: LifeSciences, GeneralReference, and InformationTechnolo gy .
• Examples of corresponding URLs may be:
• the connector's ASP.NET page takes an additional parameter Since, also case-insensitive.
• the format of time may be yyyy-mm- ddTHH:mm:ss. For example: 2005-06-29T16:35:43. This can be easily obtained in C# by calling date.ToString("s"), where date may be an instance of System.DateTime structure.
• the paging parameters may be as earlier: Start and PageSize.
• the connector emits RSS 2.0 data which may be mapped from the staging index (with the news items).
• the RSS 2.0 data indicates that the data may be from a Nervana Data Connector.
• the KIS downloads the RSS, it parses it. It then checks to see if the RSS is from a Nervana Data Connector. Tf it is, it then checks the paramsSupported field. Tf this is populated, it then checks if the "since" parameter is one of the comma-delimited items in the field. If the "since" parameter is found, the KIS then makes note of the current time.
• Figure 7 News connector RSS item snippet
• the nofollow meta tag may be added accordingly, based on whether the link is accessible or not.
• the Nervana Knowledge Center may be a Federated universe of Nervana-powered content, providing the transformation of Information to Knowledge.
• the Knowledge Center has semantically indexed content, People (in a future version), and/or annotations (also in a future version). Tn various embodiments of the invention, any of the following may be included:
• Smart Marketplace This may be the e-commerce scenario and/or includes sponsored listings that may be semantically indexed.
• the KCs therein may be first-class KCs (with people, annotations, etc.). I contend that if there is enough value in the content and/or the medium, people can independently subscribe (the one person's ad is another person's content scenario I described recently). Examples include:
• Ncrvana-Run Research KCs e.g., Semantic/Smart Medline.
• Nervana-Run Domain and Scenario-Specific KCs Examples include Compliance, Sarbanes-Oxley, etc.
• Smart Libraries preferably can have ALL the tools in the toolbox. They may be first-class Knowledge Communities, they can have people, they can have annotations, etc. See more below.
• Smart Groups may be like a semantic (knowledge- oriented) equivalent of blogs. The scenarios here are numerous. There may be many thousands of knowledge communities around the world — on everything from gene research to fly-fishing. Users can first sign up (maybe for $5 a month) as members of the Nervana Network. As a member, you may be then able to create and/or moderate Smart Groups. Smart Groups may be different from regular groups (like Yahoo Groups) or blogs in that:
• Examples of Smart Groups Research communities, virtual communities across companies (including partners, suppliers, etc.), classes in schools (e.g. working on specific projects), informal communities of interest around specific area, etc. Imagine a group of researchers that may be able to annotate results from Nervana Semantic Medline (after a Drag and Drop) in their own Smart Groups, and/or create semantic threads based on results from Medline, and/or then annotate Smart News results around those semantic threads.
• Nervana Semantic Medline after a Drag and Drop
• Smart Books in partnership with a large aggregator like Barnes & Noble. Subscribe to a Nervana Smart Books KC and/or semantically finds books with semantic wildcards and/or the like. Dynamically link that to Smart Groups within (Smart Books a moderated by Nervana) OR your own Smart Groups (moderated by you or a friend/colleague).
• Smart Images in partnership with a large aggregator like Getty or Corbis. Semantically find professional or amateur photographs by dragging and/or dropping a picture from your desktop. And then creating semantic threads around the pictures you find - with other hobbyists that like photography as much as you do (in your Pictures-based Smart Groups). The provider may be responsible for providing rich annotations to the books.
• Smart Media in partnership with large music and/or video (including live broadcast) aggregators.
• the key value proposition here may be that reviews become semantic and/or context-aware.
• communities of interest may be formed around music genres, movies, etc. This needs to be more tightly moderated because it may be more consumer-oriented.
• ALL the tools in the toolbox can apply.
• live mode may be a Watch List of one and/or may be aimed at providing awareness-oriented presentation for a specific request (including special requests and/or Dossiers) or request collection. It allows users to track timely results in the context of a request or request collection.
• the Presenter periodically issues queries to the KTSes in the contextual profile for a request in Live Mode.
• a request can be in normal mode or live mode.
• the Presenter also sorts the results based on timeliness and/or provides additional functionality for handling News Dossiers (previously described) and/or for guarding against KC starvation in the case of federated profiles.
• the Presenter can have a configurable refresh rate and/or other awareness parameters.
• the skin polls the Presenter for results.
• the Presenter polls the KISes and/or then places the results in a priority queue (as previously mentioned).
• the skin picks up the results and/or shows special UI to indicate recently added results, freshness spikes, an erosion of freshness (fade), etc.
• the Presenter guards against KC starvation in federated profiles by making sure results from a high-traffic KC don't completely drown out results from lower-traffic KCs.
• the Presenter employs a round-robin algorithm to ensure this.
• Spike Alert A Spike Alert may be generated/fired when a new result is the first fresh result over a given period of time. The Presenter sets a timer; if the timer expires with no results then a flag may be set. The very next "fresh" result would trigger a Spike Alert in the UI. The arrival of a new result resets the timer.
• the Spike Alert may be designed to draw the user's attention to a given result. The methods of drawing attention may include a small sound, a pop up alert window, a color change, or a movement of page elements.
• the semantic client and/or WebUT support the saving, exporting, and/or emailing of results. All results can be saved or exported or selected results can be.
• All Results Lists may be RSS (XML, cross-platform). Reports may be HTML (portability, cross-platform, no need for special clients, etc.). However, Dossiers may be saved in zipped folders.
• Zipped folders provide a single thicket model (ease of sharing, ease of file management, etc.), they may be portable, cross-platform and/or pass though firewalls (most firewall extension filters allow zips to pass through) — for email sharing.
• HTML reports may be also branded with our logo and/or tagline and/or the logo may include a hyperlink to our web site - for viral marketing.
• this infrastructure can then be used for semantic email alerts — in one embodiment, the user registers his/her email address(es) and/or semantic wildcard (or other) queries.
• the semantic client or WebUI can then email (or via some other notification channel) periodic breaking news or headlines results to the user. These may be in HTML and/or RSS, as described above.
• the Email Companion Agent may be an agent that employs the email notification infrastructure described above and/or may be a companion to an existing distribution list. So the admin can create a distribution list to track semantic topics and/or the companion agent can email breaking news and/or headlines to the list on a periodic basis, consistent with the semantics of the distribution list.
• sclf-awarc documents may be documents — using the Information Nervous System - that generate their own live, semantic references.
• This employs the Dynamic Linking functionality of the Information Nervous System but embeds the logic in documents themselves (the document "drags and drops itself in real-time).
• a document can be configured to dynamically link to one or more knowledge communities (federated).
• a self- aware research paper that generates its own references. The references are as good — in the general case, with arbitrary papers — as references the author generates him or herself.
• self-aware documents can "call" into the semantic client runtime to invoke Dynamic Linking in real-time — as they are displayed.
• a research paper emailed around with live, semantic references. This is extremely powerful because the value of the paper changes over time - as the surrounding "semantic environment" changes.
• the documents can be configured with authentication information that may be passed into the semantic client runtime.
• the argument to the Dynamic Linking APIs may be the "self URI (the document itself).
• semantic profiles may be wrappers around entities, as described in a previous invention submission.
• a semantic profile can be built for a company (based on relevant documents, filed patents, etc.)
• semantic screening refers to tracking incoming and/or outgoing information (including documents) and/or correlating the information to one or more semantic profiles.
• a company might build semantic profiles for companies involved in ongoing patent litigation and/or then set up screening rules to ensure that no document leaves the company relevant to the litigation. Similar rules can be setup for incoming traffic.
• Deploy Combinatorial Filters Manage combinatorial complexity; Provide manageable, meaningful, probabilistic, ranked inputs into Disease Model; Inputs into a stochastic model; Deploy Early Warning Systems; Decision-Support; Diseases to target? Projects to keep? Licensing, M&A opportunities? Safety, IP issues? Signaling systems (biomarkers, toxicogenomics, etc.); Build Drug Discovery Libraries; Research, patents, safety studies, factoids, etc.; Enable Knowledge Feedback Loop.
• Ontologies Describe knowledge domains; Basis for semantic interpretation; Necessary but NOT sufficient; Needed: Ontologies + Combinatorial Filter; Filter: Handles combinatorial mathematics; Use ontologies as inputs; Avoid extremes of ontological simplicity & complexity; Simple enough but not too simple; "Semantic loss”; Complex enough but not too complex: “Semantic overkill”; Yet more mathematical complexity.
• Phase I Start with External Data; Deploy Combinatorial Filters; Deploy Early-Warning Systems; Use well-known ontologies; Start building Discovery Libraries; Corresponding to hypotheses; Across silos.
• Phase II Refine your business processes; Processes, Metrics and Accountability; Design Knowledge Audits.
• Phase III Unlock your internal data.
• Phase IV Define your knowledge domains; Develop or license ontologies for your domains; Open Biological Ontologies; [http:]//obo.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computational Linguistics (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=38049408

Family Applications (1)

Country Status (2)

Family Cites Families (4)

• 2006
  • 2006-11-17 EP EP06839942A patent/EP1952286A2/de not_active Withdrawn
  • 2006-11-17 WO PCT/US2006/061054 patent/WO2007059536A2/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events