Patent Application
20070276871
In the drawings appended hereto like reference numerals denote like elements between the various drawings. While illustrative, the drawings are not drawn to scale. In the drawings:
The following detailed description is divided into two main sections. The first of these sections discloses the definition of the Market Research Model. The second section describes exemplary Patterns and Interfaces which may be implemented as part of a system supporting the formation of data mosaics and investment ideas. Exemplary embodiments of the invention are also described.
In order to provide context for the discussion which follows,
The Market Research Model (MRM) is a paradigm supporting the collection, association, filtering, and viewing of content to support analyses of market-driven instruments, for example securities valuation and trend prediction. The MRM consists of Entities and Patterns (i.e. complex Entities). Different classes of Entities and Patterns correspond to critical, core concepts in the domain (i.e., key content related to the domain in which the market-driven industry operates). According to one embodiment of the present invention, the following are considered Entities:
1) Elements of the Value Chain Model;
2) Content Sources;
3) Content; and
4) Links.
The Value Chain Model (VCM) represents how goods and services flow between parties, such as from producers to consumers in an industry (i.e., the Value Chain). Typically, a VCM is an ordered Aggregation consisting of Producer/Reseller Primitive Entities and an optional set of other primitive entities. The entities within a VCM may also be ordered according to a variety of optional Link entities which have particular semantic meaning (e.g. Supplier/Customer, Produced By, Strategic Partner, etc.) in the MRM. Having a minimal instantiation of a VCM is essential for providing context to individual data points (as well as more complex concepts) in a larger mosaic and for organizing research on an investment idea. It will be appreciated that use of the term Producer/Reseller is intended to be a compact way to represent a broad class of business relationships. It is not to be considered limiting, as customer, consumer, vendor, partner, supplier, distributor, consultant, and many other relationships between business parties are considered within the scope of that term. The VCM is discussed in greater detail below.
Content Sources (an Entity type) include, but are not limited to: private individuals, companies/corporations, industry and professional organizations, third-party data providers and aggregators, data feed services, publications, etc. As the name suggests, Content Sources are points from which content used to populate a data mosaic may be obtained. As will be discussed, the nature of the content source (e.g., experience, reputation, closeness to the industry in question, possible biases, etc.) may itself be a content element of a data mosaic (in addition to the content provided by that content source).
Content (also an Entity type) includes, but is not limited to the ideas, facts, opinions, etc. contained in: text documents, emails, presentations, spreadsheets, databases, recordings, transcripts, and summaries from the above Content Sources. Indeed, virtually any element of information, whether opinion or fact may be considered a Content Entity. Of particular note are industry expert statements, also known as Impact Statements, which are short textual statements elicited from industry experts during their conversations with the research provider.
Links are Connections between elements in the MRM. Any Entity or Pattern may be linked to any other Entity or Pattern. As will be explained further below, the establishment of links permits exploring the various content comprising the MRM by traversing from Entity to Entity within the MRM. However, links must be judiciously placed to guide the exploration process—the goal of the MRM is to facilitate an organization of large quantities of content. Providing too many links will result in unguided traversing of the MRM which may overwhelm the user with information.
Aggregations are a highly useful class of Pattern defined within the MRM. Specifically, Aggregations are sets, which may be ordered or unordered, of other Entities, Patterns, and other annotations. Aggregations may be ordered by some subset of the included Entities, Patterns, and other annotations, also known as the Ordering Subset. For example, elements of the Ordering Subset may be Link Entities or other annotations.
If the ordering subset is empty, then the Aggregation is considered a collection or non-ordered grouping of Entities and Patterns. An example of this latter case is the Producer/Reseller Watch List, an unordered collection of Producer/Resellers of interest to the end user.
Abstractions are ordered Aggregations which represent synthesized concepts about a group of Entities or Patterns. For example, a Thesis, which is an investment idea regarding a producer/reseller or group of producers/resellers based on a complex set of Entities in the MRM, is an Abstraction.
We to turn to an example of an MRM.
One critical requirement of providing context-sensitive support (that is, information relevant to a user's area of interest) is developing a representation of the domain (e.g., the industry) relating to the target of the mosaic which is adequate (within the limits of the system and its purposes) to support the formation and population (with content) of the mosaic. That is, it is important to have an adequate representation as a part of the MRM of at least relevant portions of the industry to which a security in question relates. A Value Chain Model (VCM) forms a minimum set of Entities for this purpose.
The content of the VCM includes required and optional content, summarized in table 1 as follows:
The model represents a Value Chain because each producer/reseller derives value from its predecessor producers/resellers in the form of goods and/or services.
With reference now to
We note that there can be more than a single Value Chain Model instantiated within an MRM. Indeed, different Value Chain Models may be employed from the research provider and/or third-party sources, and linked as necessary between their constituent elements using the Link types described above. In another possible embodiment of the invention, the end user may be allowed to extend the existing VCMs within the MRM or to add his or her own VCM(s) as part of their MRM.
The MRM may be described more formally as follows, using traditional set theory notation. We begin by defining the following:
In order to assist a user of the system in creating, navigating, and interpreting a data mosaic, the system permits the definition of Patterns (e.g., complex Entities). Pre-formulated Patterns (e.g., commonly used) may be provided to a user as well as tools allowing a user to create their own custom Patterns. Furthermore, there are a number of Interfaces (e.g., displays in a graphical user interface) which are particularly useful with certain Patterns. We next describe several specific embodiments of a system using the MRM, Patterns, and Interfaces according to the present invention.
Consultation Pattern and Consultation Interface
A first type of Pattern useful in describing an exemplary system is a Consultation Pattern (or simply a Consultation). A Consultation is the fundamental unit of work done by a user, the data service provider or a third party (or a combination thereof) when directly consulting (e.g., speaking with) a content source. It is the action associated with the collection of content. That is, the interaction between a user and a content source results in a set of Content regarding one or more producers or resellers, the market, etc. Formally, we define the Consultation Pattern as a class of Aggregate Entities consisting of:
A set of producers/resellers (PR);
One (or more) content sources (CS); and
A set of content about the producers/resellers (C)
A data service provider may initiate Consultations in the process of providing its service to end users. These consultations will populate the database(s) to which a user may subscribe. In addition, a user may request the data service provide to schedule a consultation. In such a case, the service provider may conduct a consultation on the user's behalf, or may put the user in touch with the Content Source for the consultation. The data service provider may create the instance of the Consultation for the consultation for the end user, or the end user may be provided an interface for creating a personal Consultation therefor. Consultations may be edited by the person creating the Consultation. Controls may also be provided to permit others to edit parts or all of a Consultation (this being true for other Entities in the MRM as well)
Over time, a user of the system builds up a set of Consultations which form some of the building blocks of a data mosaic. Interactions between the data provider service and the user can occur by passing/altering consultation elements back and forth.
An exemplary computer user interface 50 for a Consultation is shown in
In addition to the details window 52 for the specific consultation, there may be provided a window 62 providing access to information related to the topic of the Consultation, such as for viewing previous Consultations, notes, etc. created by the user or others. Such a window may, for example, provide drop down lists 64 for filtering content to obtain desired information, and tabs 66, 68, 70, 72 for navigating between views. Should a user select a tab or an individual Entity displayed in window 62, a hyperlink may call up an appropriate associated Interface for that Entity.
Consultation List Pattern and Interface
The Consultation List Pattern defines a type of Aggregation Pattern listing Consultations available for the security in question. More formally, the Consultation list is defined as:
CList={consultation1, consultation2, . . . , consultationk}
The Consultation List Pattern allows a user to view upcoming scheduled Consultations and prior Consultation history. That is, one aspect of the Consultation List Pattern is to function as a scheduler. When a user requests a Consultation from within a system, it shows up in their instantiation of the Consultation List Pattern and keeps them up to date with the status of the Consultation.
Thesis Pattern and Display
A Thesis Pattern is an Abstraction Pattern which can describe a complex investment idea (here called a Thesis). With reference to
One critical aspect of the Thesis is that it allows the user to conceptually, visually, and functionally drill down or drill up through the Abstraction layers (i.e. reasoning) about the Thesis. That is, an end user can start with the top-level Plank 102 and descend through the subordinate Planks 104-110 until he or she can view the desired information, such as the specific Content Sources (e.g. Experts) and Content (e.g. Impact Statements) which are in support or refutation of each Plank. Alternatively, a user may start from a specific Entity, such as a Producer/Reseller, and traverse upwards towards the top-level Plank of the Thesis. In general, a user may start at any point in the Abstraction hierarchy of Planks within the Thesis definition.
This navigation may be facilitated by a graphical user interface 230 as shown in
The Thesis Pattern is important for a number of reasons. For example, it allows Research Providers the ability to communicate complex investment ideas about an industry to an end user while providing all of the associated reasoning and data in a form which allows for efficient understanding of the investment idea. In addition, since the end user can annotate the Thesis object at any level of abstraction, the end user can adapt instantiations of a Thesis Pattern based on their own observations.
More formally, a Thesis Pattern is defined as:
A Category/Watch List is an unordered Aggregation (e.g. collection) which allows for a high-degree of interaction between the research provider and the end-user. From the research provider's perspective, a Category/Watch List Pattern contains items of interest to the end user, and thus may be used to flag and promote new Content Sources, Content, Theses, etc. which are relevant to the elements in the Category/Watch List. These elements may be made to automatically appear on the end-user's interface without additional tagging by the research provider. From the end-user's perspective, Category/Watch List Patterns are a powerful tool to manage the content from the research provider. Both the research provider and the end-user may be provided the ability to add and remove elements from a Category/Watch List Pattern.
The difference between a Category and a Watch List is that a Category can contain a heterogenous set of Entities or Patterns within the MRM. The Watch List is a specific subclass of Category which includes only a single class of Entities and/or Patterns (i.e. all elements in the Watch List are of the same type).
The power of the Category/Watch List Pattern lies in its capability of presenting, in a single focused area of an interface, a high-level summary of all recent relevant material from a research provider. The Company Watch 90 of
The Product/Reseller Watch List is another example of a Watch List Pattern. The Product/Reseller Watch List communicates the set of products/resellers entities of interest to the end-user as well as the existence of new Content and Content Sources linked to the Product/Resellers in the Watch List.
More formally, the Product/Reseller Watch List is defined as:
As illustrated in the embodiment of Product/Reseller Watch List 90 shown in
Categories and Watch Lists provide a means of automatically notifying end users when new Content or Content Sources that are relevant to their interests are available. For example, relevance may be defined as sets of Content and Content Sources which are directly linked to entities within the Watch List. For example, for the Producer/Reseller Watch List we consider only Content/Content Source pairs which are directly associated with the set of Producer/Resellers included within the Watch List. After computing the relevant Content/Content Source sets, there are a number of techniques of displaying them to the end user. As an example, an interface may highlight (e.g. text effects, icon, etc.) Producer/Resellers in the Watch List which are associated with recent Content/Content Sources according to the following formula, expressed in pseudocode:
The above is one high level example of implementing Watch List functionality. Other additional functionalities and formulae or algorithms may be developed to provide various aspects of Watch List functionality. Accordingly, this example is not intended to and does not limit the scope of the present invention. Each of the Product/Resellers listed in the Watch List area 90 may be hyperlinks such that clicking on any one of them takes the user to the Product/Reseller Interface for that Product/Reseller.
Favorites Pattern and Interface
The Favorites Pattern defines a class of ordered Aggregations which are used to group together selected Entities of a given class or classes by an end user. By creating instantiations of this Pattern, the end user or research provider can group, or define as “favorite,” a set of Content Sources, of Theses, etc.
More formally, a Favorites Pattern is defined as:
The Favorites Pattern allows end users to organize, easily display, and quickly access the set of Entities and Patterns which they find most helpful in their research processes. Much like the Producer/Reseller Watch List Pattern, the Favorites Pattern is also a way for an end user to communicate with a research provider, for example as a way for a research provider to discern the interests of the end user.
An exemplary embodiment 116 of a Favorites Pattern for Experts is shown in
Producer/Reseller Interface
The Producer/Reseller interface allows the end user to view all research he or she has performed on a particular Product/Reseller. An exemplary Producer/Reseller Aggregation interface 130 is shown in
A first window 134 presents a list of all Consultations (collectively referred to as Network Insights in this example) for the Product/Reseller to which the user is permitted access. The Network Insights displayed in window 134 may be sorted by date, identity of the expert, age, etc. through an appropriate selection mechanism such as a pull-down menu 136.
A second window 138 presents a list of Consultations associated with the Product/Reseller to which the user is permitted access. These Consultations may have been entered by the user or by some other research provider. The Consultations displayed in window 138 may be sorted by date, Expert, age, etc. through an appropriate selection mechanism such as a pull-down menu 140.
A third window 142 presents a list of personal files the user has accumulated related to the Product/Reseller. These personal files include word processing documents, spreadsheets, images, multimedia files etc. which the user chooses to associate with the Product/Reseller. Typically, only the user would have access to such personal files, although access may be controlled (e.g., allowing access within a network, etc.) by permissions as well understood in the art.
The Product/Reseller interface 130 also provides the user with the ability to conveniently add the selected Product/Reseller to a Favorites/Categories list of a type described above. When viewing a Product/Reseller the user may selected the Add to Favorites button 144, which causes the Product/Reseller to be added to the user's Favorites/Categories List for Products/Resellers.
In addition, the interface allows the user to traverse the Value Chain Model to reach other related Entities of interest. Specifically, the Producer/Reseller Interface allows the end user to reach the following related Entities and/or Patterns efficiently:
Expert Entity and Interface
The Expert Entity is a subclass of Content Source, usually an individual, hence
expertεCS
The Expert interface allows the end user to view all Content previously developed by the Expert.
Ecosystem Interface
The Ecosystem Interface allows the end user to traverse the Value Chain Model, from Producer/Reseller to related Producer/Reseller. For a given Producer/Reseller, related Producers/Resellers are put into one or more of three categories: Supplier, Customer, and Competitor. Furthermore each of these categories may be broken down into subsets relevant to a class of Goods/Services associated with the Producer/Reseller. Such organization may be structured by the data service provider, by the user, or by third parties, as controlled by permissions, depending on the application of the present invention.
User-Driven Traversal of the Value Chain Model
In this section we provide an example of a user-driven formation of a Data Mosaic. We select for this example a product category of audio/video players, and more specifically such products manufactured by Apple, Inc. (AAPL). The products, company, and details of the example are selected to provide an overview of certain of the features and capabilities of a system according to the present invention, and are not in any way limiting as to the fuller scope of the present invention.
Once settled on a product and/or company a user wishes to investigate, the first step may be to refer to the Producer/Reseller Watch List Interface 190 shown in
To investigate AAPL, the user clicks on the AAPL link 192, which brings the user to the Producer/Reseller interface 194, as shown in
Suppose the user first wishes to browse AAPL's Value Chain Model interface, for example, to discover the various suppliers for AAPL's products. From Window 194, the user simply clicks on the Ecosystem button 202, which then links to and displays the Value Chain Model interface 210 shown in
Value Chain Model interface 210 allows the user to browse through the customer, supplier, and competitor relationships for AAPL. For example, from interface 210 the user can see at 212 that there are four primary suppliers of hard drives for AAPL (i.e., Toshiba, WDC, MXO, STX). This suggests to the user that sales of AAPL products may result in changes in sales figures (and hence quarterly projections) for Toshiba, WDC, MXO, and STX, depending on the percentage of sales AAPL represents for the various vendors (information which could be located elsewhere in the VCM). Furthermore, since each entry in the VCM is itself a hyperlink, if the user clicks on, as an example, STX, the user then traverses to a Producer/Reseller interface 214 for STX shown in
Thus, the system uses the user's traversal through the Value Chain Model to provide targeted, relevant Content which helps to build out the user's actual or conceptual Data Mosaic. However, the user is completely in control of the traversals, allowing investigations of a wide variety of relationships and addressing of a variety of inquiries (theses). Furthermore, the user is able to create additional Entities and Patterns (e.g., Consultations, Producer/Reseller Watch List, Favorite Experts, etc.) during the exploration of the VCM. For example, in the case of Consultations, the user can annotate the Data Mosaic with his or her own interpretations of the Content offered by Content Sources.
At this point, the user could follow the STX Value Chain Model by clicking on the Ecosystem button 216 in
Using the above methodology, a user can very quickly investigate the Value Chain Model surrounding AAPL. As another example, a user may observe that there are few or only one supplier of potentially key components (“bottleneck suppliers”). For example, SSTI is the sole listed supplier of Flash memory to APPL. Through the traversal process described above it may be possible to determine how many other suppliers of Flash memory are in the market, and hence APPL's sensitivity to surpluses or shortfalls in the SSTI's production. As yet another example, returning to
Thesis Traversal
The invention described in this patent also provides a language and means for structured interaction between a research provider and an end user for complex investment research concepts. The Thesis Pattern discussed above is a hierarchy of abstraction entities linked to both Content (both atomic and abstracted) and the Value Chain Model. This hierarchy and associated links are presented to the user and the user is allowed to traverse the model freely, while the system provides Content relevant to the user's focus of attention.
As an example, we select a Thesis relevant to AAPL such as the following:
Thesis: AAPL will dominate the mobile audio/video market for at least the next year.
Furthermore, we construct the following top-level Planks for the above:
Each of the Planks are Abstractions which are linked directly with Content (e.g. Statements) from Content Sources (e.g. Experts). In each of the supporting Planks (2a-2b, 3a-3c) the interface displays the number of Statements both supporting the Plank (For, or positive), opposing the Plank (Against, or negative), or Neither (neutral). (In certain embodiments it may be desirable to force rating statements as either For and Against a Plank.) Each Statement is also linked with a set of Producer/Resellers. The resulting Plank is therefore associated with the union of the sets of Producer/Resellers linked with the Statement (e.g., Plank 3c would be linked to SSTI, Plank 3b would be linked to LPL and Hannstar, and so on). Thus, the user can also traverse into the Value Chain Model surrounding AAPL from the Thesis.
The above Planks are examples of Abstractions—namely, the Planks 2a-2b, 3a-3c are abstractions generated from actual Statements (Content) originally obtained from Experts (Content Sources). Planks 2 and 3 are further abstractions of Planks 2a-2b and Planks 3a-3c, respectively. Finally, Planks 1-3 are finally abstracted into the top-level Plank displayed at the top of
The hierarchical structure 220 illustrated in
The user can also traverse between Theses, if they share Planks and/or Statements. Thus the Thesis pattern provides the means of a structured exploration of investment ideas between the research provider and end user.
Central to the formation of a data mosaic for end users is the ability to schedule Consultations between the end users (e.g., Clients) and Content Sources (e.g., Experts) efficiently. Hence support for scheduling Consultations between end-users and Content Sources is an important capability for computer-based systems which support the primary research process described in this invention.
We define the Scheduling Problem as the problem of finding a common date, time, and location for an end user and Content Source to hold a conversation of given length. Inputs to the Problem include:
1) Scheduling Constraints
These are constraints (positive or negative) for dates/times (and possibly locations) for the Consultation from the end-user and/or the Content Source. Positive constraints are dates/times (and possibly locations) where the end-user or Content Source is available for the Consultation; negative constraints are dates/times (and possibly locations) where the end-user or Content Source is unavailable for the Consultation. The constraints may also include preferential information as well. Also, the desired length of the conversation and type of conversation (e.g. phone call, in-person meeting, social event, etc.) is included as a constraint.
2) Time Bound Constraints
These are constraints on the scheduling process itself and may be either Consultation-specific or Global in nature. Some examples of this type of constraint are:
Other types of Time Bound Constraints are also possible. There are a number of actions a system may take when a time bound constraint is violated. For example, the system may issue an automated warning to the Research Provider regarding the violated constraint. The Research Provider would then be able intervene in the scheduling process for this Consultation in a variety of ways (e.g., calling the non-responsive party or parties, canceling the Consultation if no longer needed, etc.)
However, these constraints are often incomplete and/or unknown prior to the start of the scheduling process for a particular Consultation. Thus the process of scheduling is an iterative one. Such a process 250 is illustrated in
Violation of the time bound constraints result in an automatic notification of the violation to the Research Provider. The Research Provider may examine the scheduling history for the consultation and intercede by inserting themselves into the scheduling process.
While a plurality of preferred exemplary embodiments have been presented in the foregoing detailed description, it should be understood that a vast number of variations exist, and these preferred exemplary embodiments are merely representative examples, and are not intended to limit the scope, applicability or configuration of the invention in any way. For example, the present invention may take the form of an application program running on a user's computer or network while making calls to a server and caching certain data to populate the application, or may take the form of a purely web-based, remote application. Furthermore, certain features described above may not be included in every embodiment of the present invention, and alternatively, other features supporting a decision making process not described above may be included without departing from the spirit and scope of the present invention. Therefore, the foregoing detailed description provides those of ordinary skill in the art with a convenient guide for implementation of the invention, by way of examples, and contemplates that various changes in the functions and arrangements of the described embodiments may be made without departing from the spirit and scope of the invention defined by the claims thereto.
The present invention is related to and claims priority from copending U.S. Provisional Patent Application titled “User Interface System for Providing Content on Market-Driven Industries”, Ser. No. 60/802,642, filed May 23, 2006, which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60802642 | May 2006 | US |
