Source: http://www.google.com/patents/US20020010618?dq=6526440
Timestamp: 2015-07-04 10:12:10
Document Index: 720436090

Matched Legal Cases: ['arts 116', 'arts 116', 'art 116', 'arts 116', 'arts 116', 'arts 116', 'arts 116', 'art 116', 'art 116', 'art 116', 'art 116', 'art 116', 'art 116', 'arts 116', 'art 116']

Patent US20020010618 - Data distribution - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method of distributing performance data concerning a plurality of subjects (such as stock market companies) from a distribution site to a user site is described. The method comprises storing gathered performance data concerning each of the subjects in a central database, where the storing step comprises...http://www.google.com/patents/US20020010618?utm_source=gb-gplus-sharePatent US20020010618 - Data distributionAdvanced Patent SearchPublication numberUS20020010618 A1Publication typeApplicationApplication numberUS 09/771,459Publication dateJan 24, 2002Filing dateJan 26, 2001Priority dateJan 31, 2000Also published asCA2397824A1, EP1122661A1, WO2001057742A1Publication number09771459, 771459, US 2002/0010618 A1, US 2002/010618 A1, US 20020010618 A1, US 20020010618A1, US 2002010618 A1, US 2002010618A1, US-A1-20020010618, US-A1-2002010618, US2002/0010618A1, US2002/010618A1, US20020010618 A1, US20020010618A1, US2002010618 A1, US2002010618A1InventorsRocco Pellegrinelli, Luca Spampinato, Sandro BottarelliOriginal AssigneeRocco Pellegrinelli, Luca Spampinato, Sandro BottarelliExport CitationBiBTeX, EndNote, RefManReferenced by (14), Classifications (4), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetData distribution
DETAILED DESCRIPTION OF THE INVENTION [0039] Referring now to FIG. 1, there is shown an updated performance data distribution system 10 embodying the present invention. The system 10 is configured to gather, on a daily basis, performance data relating to the current values of securities such as stocks, funds and shares from stock markets all over the world. This current data can then be collated and supplied to customers together with additional historical data derived from the current data. Given the number of subjects (stocks, funds and shares for different companies) to be covered and the volume of historical data for each subject (typically daily information going back several years), the historical data for each subject is presented graphically as an element of a ticker tape as is described in detail hereinafter. [0040] The system 10 comprises a central data processing site 12 that is connected to three data vendors 14 by different communication channels. Data vendor A 16 is connected directly to the central data processing site 12 through a direct telecommunication line 18. Data vendor B 20, who may be located in a different country, is connected to the central data processing site 12 via the Internet 22. Data vendor C 24 is connected to the central data processing site 12 directly through a public telephone network 26 such as a PSTN or ISDN. [0041] The central data processing site 12 thus receives data from a plurality of sources 14. The received data is cleaned up, collated, integrated and stored within the central data processing site 12. The exact way in which this data is processed is described in detail later. Selected data is then distributed, in this embodiment, to each of four local data distribution sites 28 that may also be in different countries of the world. [0042] The central processing site 12 is coupled to a local data distribution site W 30 and a local data distribution site X 32 via the Internet 22. More specifically, local data distribution sites W and X 30, 32 are each servers with their own securities database hosted by a respective Internet Server Provider (ISP) 34, 36. Each of these distribution sites 30, 32 has a web page (not shown) which is accessible to its subscribing customers 38 via the Internet 22. [0043] A local data distribution site Y 40 is directly connected into the Internet 22 for data communication with the central data processing site 12. This distribution site 40 has a local securities database for storing received information and provides a local host for its customers 42 via an Intranet or LAN (Local Area Network) 44. The customers 42 obtain the information distributed to the local distribution site 40 by accessing its local web site 46. [0044] A local distribution site Z 48 is directly connected into the public telephone network 26 for data communication with the central processing site 12. This distribution site 48 has a local securities database for storing received information and provides a local host for its customers 50 via an Intranet or LAN (Local Area Network) 52. The customers 50 obtain the information distributed to the local distribution site 48 by accessing its local web page 54. [0045] The central processing site 12 comprises a communications manager 56, a data processing unit 58, a market database 60 and a market database management unit 62. The communications manager 56 handles all the data communications to and from the central processing site 12, namely to and from the data vendors 14 as well as to and from the local distribution sites 28. The communications manager 56 includes hardware and software supplied by some of the data vendors 14 for handling each of their specific data transmission protocols as well as their specific formats of data. This special equipment is configured to optimize the often-large data transfers. Other data vendors, such as data vendor B 16, simply provide an Internet address and a password for accessing the data at their Internet site. [0046] Different data vendors have different ways of supplying performance data to the central processing site. Performance data is broadcast by some of the data vendors at regular intervals to subscribers, such as the central processing site 12. Other performance data has to be obtained on demand. Some data vendors provide data in real time and others provide the data as snapshots on a daily basis. As the performance data from the different data vendors is in different formats, the data vendors 14 provide specific data structure specifications, setting out how the data will be sent, which are stored at the central processing site 12 and used in extracting the desired information from the received data. [0047] The data processing unit 58 receives the raw performance data from the communications manager 56 and transforms it into a uniform format. The market database management unit 62 takes the transformed data and stores it in the market database 60 in an appropriate way for ease of access. The market database management unit 62 also handles the retrieval of selected performance data for transfer to the local data distribution sites 28 via the communications manager 56. [0048] Referring to FIG. 2, the method of accumulating performance data from the different data vendors 14 and storing it in the market database 60 is now described in detail. The method commences at 70 with the downloading of performance data from a financial data vendor 14 over a communications link. The performance data is provided on hundreds of companies, funds and stocks from one or more markets, for example from the New York and London Stock Markets, with each different stock, fund or company being considered as a different subject. The different ways in which this data is transferred has been mentioned previously. [0049] The data processing unit 58 transforms the downloaded data at 72 into a standard format suitable for storage in a common database (the market database 60). This procedure requires accessing the stored information regarding the data format used by each particular data vendor 14 and using this information to strip out the required information; for example the name of the subject and the current stock market value of its shares in a particular market. [0050] The data processing unit 58 then detects and corrects errors in the received data at 74. This is carried out in a two-stage process. The first stage involves a computer program considering the received data and compiling a ranked list of potential errors. The second stage involves selecting likely errors for correction and correcting them on the basis comparison with previously received correct performance data for the subject. The error-corrected data is then consolidated and integrated together at 76 for storage in the market database 60 on a subject by subject basis. [0051] The market database 60 stores the performance data on a subject by subject basis. Prior to the received error-corrected data being stored, a check is carried out at 78 to determine whether the current subject, for which performance data is to be stored, is one which has an existing data entry in the database 60. This can be simply achieved by checking a running list of subjects in the database 60. If the subject is not new, then the existing record pertaining to this subject is located at 80 in the market database 60 and the received performance data for this subject is stored at 82 in that record. [0052] The exact manner of updating the existing data record in this way is dependent on the data structures used in the database. In this particular embodiment, slightly different data structures are used for different types of subject, stocks are different from funds for example. However, in general, a two-part record structure for each subject is used. The first part of the record structure is a flat record of fixed size containing all the structural information (data descriptors such as market, sector, capitalization, etc.) about the subject and a pointer to the second part of the structure. The second part is an array of historical performance data regarding the subject, storing the historical data sequentially and contiguously. [0053] The historical data array stores the value of the subject on a daily basis, daily prices of a stock for example, in a contiguous and sequential manner without any stored sums or statistics. The data is partitioned according to a set of time frame periods which determine the granularity of the historical data namely, daily, weekly, monthly and yearly. The purpose of this sequential storage and partitioning is to enable rapid access to and retrieval of selected data from the often large mass of historical data for a subject. For example, historical data over a five-year period on a daily basis is commonly stored in the historical data array. Also by storing the historical data in this way, the granularity of data retrieval can be handled without difficulty as the positional relationships of the historical data is predetermined. [0054] Turning back to the result of the check carried out at 78 to determine whether the current subject, for which performance data is to be stored, is one which has an existing data entry in the market database 60. If the subject is new, then structural information (data descriptors such as market, sector, capitalization, etc.) for each subject are determined at 83. Each data descriptor is simply a grouping that helps in the data retrieval stage when a customer 38, 42, 50 may require the retrieval of only particular groupings of relevant data. Then a first part of a two-part subject record is created at 84 in the market database 60; the first part is arranged to store the newly created structural information (data descriptors) describing the subject. Subsequently, a historical array (second part of the subject record) for storing continuous received performance data is created at 86 and a pointer (not shown) to this second part is added to the first part of the subject record. [0055] Once the subject record has been created at 84 and 86, the received data for a given subject is then stored at 88 in both the first and second parts of the record. More specifically, the newly created data descriptors are stored in the first part and received data is stored at a starting position for the contiguous data in the historical array. Also a list bearing the names of all subjects may then be updated as appropriate. [0056] A check is then carried out at 90 to determine whether there is further data on any of the subjects in the received data that needs to be stored in the market database 60. If there is further data to be stored, then the above procedure at 78, 80, 82, 84, 86, 88 for storing the received information in the market database 60 is repeated for all of the different subjects about which information has been received at 70. [0057] Once all the received data has been loaded into the market database 60, the method waits at 92 until a new update is required or new information has been received. When new information is to be obtained, the above-described steps of the method are repeated. [0058] Having accumulated the data at the central processing site 12, this data is then distributed to the local data distribution sites 28 according to the specific services to be provided by each local site 28. Typically, the central processing site 12 is run by a first company and the local data distribution sites 28 are run by second companies who pay a subscription fee to the first company for the services provided. [0059] Each local site 28 has a securities database that has the same data structure format as the market database 60. Each securities database is accessible to its customers 38, 42, 50 through a web page 46, 54 of the server. Usually each securities database stores a copy of all of the data which is maintained in the market database 60 such that, if required, customers 38, 42, 50 have access to the full range of performance data. However, some securities databases may only retain a predetermined subset of the subjects or markets stored in the market database 60. In these cases, the second companies may pay a reduced subscription fee to the first company. [0060] The way in which data is transferred from the local sites 30, 32 to particular customers 38 over the Internet 22 is now described by way of example. The other local sites 40, 48 transfer data in a different way which is dependant on the specific protocols implemented on their Intranet or LAN 44, 52. However, the principles described below of how data is supplied to the Internet customers 38 applies equally to the operation of these other local sites 40, 48. [0061] Referring now to FIG. 3, flow of data from the data vendors 14 to the Internet customers 38 is shown schematically. As mentioned previously, market data are downloaded daily 100 from the different data vendors 14 using specific and usually different protocols and technological media for each data vendor 14. As there are several data vendors, each providing data on different subjects, the downloading procedure occurs almost continually. Data are consolidated, integrated and cleaned up 102 by proprietary software in the central processing site 12 and the received data is stored in the market database 60. [0062] A proprietary procedure 104 updates the local data distribution site 28, 30 on a daily basis with new performance data. The data is stored in the securities database 106 that is based on proprietary technology and is highly optimized for the storage and rapid retrieval of historical numerical series. As mentioned previously, the structure of the securities database 106 is the same as that of the market database 60. This data structure is specifically implemented to provide fast access to records and the historical data provided therein. Accordingly, the access primitives used to retrieve data operate at relatively high speeds. [0063] The local data distribution site 28, 30 comprises a securities database server 108, communications server 110 and an SQL (Structure Query Language) relational database 112 which stores customer information and customer defined data configurations. The communications server 110 handles the real-time communications between the customer 38 and the local data distribution site 28, 30. Furthermore, the communications server 110 provides data access to the securities database 106 via the securities database server 108 and to the SQL relational database 112. [0064] Each customer accesses the local data distribution site 28, 30 via an Internet browser running on their own computer (not shown). The data to be supplied from the local data distribution site 28, 30 to the customer 38 takes the form of a ticker tape 114 of charts 116 as will be described in detail later. [0065] When a page or frame containing a reference to the ticker tape 114 is requested by a customer browser over the Internet 22, the contents of a specific cookie file 118 on the customer computer is sent with the identity of the customer (for known customers) to the local data distribution site 28, 30. The specific configuration associated with the customer identity is retrieved from the SQL (Structure Query Language) database 112 by an ASP (Active Server Page) 120 that makes use of an ADO (ActiveX Data Objects) COMs (Component Object Models) in the communications server 110. Customer configuration may include an explicit set of security identities or a set of selection criteria. For unknown customers, a default configuration is generated. [0066] A proprietary Java applet 122 is then downloaded from the communications server 110 to the customer 38, together with the configuration information retrieved from the SQL relational database 112. The applet 122 interprets the configuration information, configures the customer's display 124 and generates a stream of URLs (Universal Resource Locators) which are forwarded to the local data distribution site 28, 30 for each of the charts 116 of the ticker tape 114 to be displayed. The URLs are generated sequentially as each URL that makes up the ticker tape 114 is to be displayed on the user's screen. Accordingly, the rate at which the ticker tape is being moved corresponds to the rate of generation of the stream of URLs. [0067] For each URL received, the communications server 110, through a proprietary COM (server component) within another ASP 126 of the communications server 110, interacts with the proprietary securities database server 108 and asks for the generation of a chart 116. The requested charts 116 are generated in GIF (Graphics Interchange Format) and are downloaded as a sequential stream of data to the applet 122 at the customer 38. The applet 122 displays the requested charts 116 on the screen 124 in the form of the moving ticker tape 114. In this way, several charts are displayed and moved at any instant in time. [0068] When the finite number of requested charts 116 have been displayed (one loop of the ticker tape 114), the sequence of displaying the charts 116 is repeated. However, rather than downloading this information for a second time, the originally received data which has been cached is used to generate the sequence to be repeated. [0069] Each ticker tape chart 116 is of a fixed time period, one year in this embodiment. However in alternative embodiments of the present invention, not only can this time period be fixed to a different value but also it can become a user-definable factor which is set by the user when the desired subject groupings are selected. [0070] The applet 122 also permits a detailed expanded static display of each chart 116 together with the data descriptors of the subject, by the customer simply selecting the chart 116 by a mouse click. In order to provide the desired static display, with potentially a maximum level of detail, the mouse click generates a new URL which is sent to the local data distribution site 28, 30 to access the desired historical data and generate an appropriate GIF chart 116. [0071] How the graphical representation is to be displayed is also selectable, for example in the form of a line graph, an area graph or a bar graph. Also the customer 38 can select the time period each chart 116 is to cover (one to five years for example) and the granularity of the data to be displayed (daily, weekly, monthly for example). The selected options which relate to the way in which the historical data is to be presented, simply determine how historical data is to be extracted from the second part of the subject records in the securities database 106. [0072] When the communications server 110 searches the securities database 106 for a particular subject in order to generate its corresponding historical data chart 116, the access primitives (not shown) used to obtain the data from the securities database 106 are optimized to allow fast access to the relevant data granularity (daily, weekly, monthly, etc.) and a very fast retrieval of the historical data. This speed is due to the contiguous storage of consecutive historical performance data in the securities database 106. [0073] The format and operation of the ticker tape 114 is now described with reference to FIG. 4. The ticker tape 114 provides a GUI (Graphical User Interface) for the Internet customer 38. The main portion of the ticker tape 114 displays moving charts 116, one for each of the securities of interest to the customer 38. A smaller portion of the ticker tape 114 provides control buttons 130 which generate, on selection, commands for controlling the operation of the ticker tape 114 on the customer's screen 124. [0074] The applet 122 interprets the customer's selection of a control button 130 as a command and, in response, controls the movement of the ticker tape 114. For example, the customer can by clicking on the speed buttons 132 accelerate and slow down the ticker tape speed. Also the direction of scrolling can be changed using the directional arrow buttons and even a stop button 136 is provided. [0075] The customer 38 can also select the type of securities that are to be displayed in the ticker tape 114. The control buttons 130 include a configuration button 138 for this purpose. When the customer 38 clicks on the configuration button 138 of the ticker tape 114, the URL of a specific configuration page is generated. [0076] The configuration page presents customer selectable options for the types of securities that are to be displayed. For example, the type of securities to be displayed can be selected by country, region, past performance criteria, stock type, etc. The options presented to the customer correspond to the data descriptors (groupings) of the first part of each subject record provided in the securities database 106. The selected options which relate to the way in which the historical data is to be presented, simply determine how historical data is to be extracted from the second part of the subject records in the securities database 106. It is the provision of these data descriptors that in each subject record which enable rapid grouping of relevant data according to a customer's specific configuration. [0077] The customer 38 makes a selection and a list of the selection criteria of the securities to be included in the ticker tape 114 is created. This list is then stored in the SQL relational database 112 as the specific configuration information for this customer and is used subsequently for the generation of each new chart 116 for this customer 38. [0078] After a customer has configured the ticker tape 114, the applet 122 restarts the information request procedure from the retrieval of the specific configuration information. [0079] The proprietary components on the server side of the above-described embodiment are implemented in the C++ programming language using COM interfaces. [0080] Having described a particular preferred embodiment of the present invention, it is to be appreciated that the embodiment in question is exemplary only and that variations and modifications, such as will occur to those possessed of the appropriate knowledge and skills, may be made without departure from the spirit and scope of the invention as set forth in the appended claims. For example, it is to be appreciated that the above is the presently preferred implementation of the present invention. The use of Microsoft™ ASP, ADO, MS IIS, COM as well as Java can readily be substituted with equivalent technology. It would also be possible for the performance data to be distributed to mobile user's telephones using WAP (Wireless Application Protocol). This provides a powerful way in which customer's can be kept updated with stock market information even when not at their desks. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7080101 *Dec 1, 2000Jul 18, 2006Ncr Corp.Method and apparatus for partitioning data for storage in a databaseUS7246090 *Oct 25, 2000Jul 17, 2007Measuredmarkets Inc.Method for detecting aberrant behavior of a financial instrumentUS7409403 *Oct 30, 2001Aug 5, 2008Red Hat, Inc.Alert management data infrastructure and configuration generatorUS7681141 *Jun 22, 2004Mar 16, 2010Sony Computer Entertainment America Inc.Fast scrolling in a graphical user interfaceUS7793205 *Jul 8, 2005Sep 7, 2010Sharp Laboratories Of America, Inc.Synchronization of video and dataUS7979569Dec 1, 2006Jul 12, 2011Firestar Software, Inc.System and method for exchanging information among exchange applicationsUS8041783 *Apr 20, 2006Oct 18, 2011Siemens AktiengesellschaftMethod for distribution of configuration settings for medical devicesUS8150752 *May 17, 2010Apr 3, 2012James Kemp SmithComputerized financial information retrieval by dynamic URL constructionUS8620989Dec 1, 2006Dec 31, 2013Firestar Software, Inc.System and method for exchanging information among exchange applicationsUS8838668Dec 1, 2006Sep 16, 2014Firestar Software, Inc.System and method for exchanging information among exchange applicationsUS8838737Aug 18, 2011Sep 16, 2014Firestar Software, Inc.System and method for exchanging information among exchange applicationsUS20100223203 *May 17, 2010Sep 2, 2010James Kemp SmithComputerized financial information retrieval by dynamic url constructionUS20130041888 *Mar 12, 2012Feb 14, 2013Firestar Software, Inc.System and method for exchanging information among exchange applicationsWO2003085980A1 *Mar 7, 2003Oct 16, 2003Digeo IncInteractive television ticker having pvr-like capabilities* Cited by examinerClassifications U.S. Classification345/440International ClassificationG06Q40/00Cooperative ClassificationG06Q40/04European ClassificationG06Q40/04Legal EventsDateCodeEventDescriptionJun 7, 2001ASAssignmentOwner name: BRAINPOWER S.A., SWITZERLANDFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PELLEGRINELLI, ROCCO;SPAMPINATO, LUCA;BOTTARELLI, SANDRO;REEL/FRAME:011645/0409Effective date: 20010427RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services