U.S. patent application number 13/932714 was filed with the patent office on 2013-11-07 for processing securities-related information.
The applicant listed for this patent is Broadridge Conten Solutions, Inc.. Invention is credited to Mark Asdoorian, David Brown, Ying Chen, Leonard Driscoll, Jeffrey B. Levering, Alex Magary, Russel E. Planitzer.
Application Number | 20130297533 13/932714 |
Document ID | / |
Family ID | 42267490 |
Filed Date | 2013-11-07 |
United States Patent
Application |
20130297533 |
Kind Code |
A1 |
Planitzer; Russel E. ; et
al. |
November 7, 2013 |
PROCESSING SECURITIES-RELATED INFORMATION
Abstract
Embodiments of the invention provide techniques for improving
clarity of disclosure materials provided to investors, by enabling
securities issuers, intermediaries and/or other entities to create
and disseminate clear and concise summary-level information on
individual securities to investors to enable informed investment
decisions. The information may include a summary version of the
full statutory prospectus (a "summary prospectus"). A summary
prospectus may include a concise, "plain English" synopsis and/or
representation of certain information contained in the hill
statutory prospectus, such as a security's investment objectives
and strategies, costs, risks and/or other information.
Inventors: |
Planitzer; Russel E.; (New
York, NY) ; Asdoorian; Mark; (Lynn, MA) ;
Brown; David; (Sudbury, MA) ; Chen; Ying;
(Fitchburg, MA) ; Driscoll; Leonard; (Andover,
MA) ; Levering; Jeffrey B.; (Harvard, MA) ;
Magary; Alex; (Andover, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Broadridge Conten Solutions, Inc. |
Jersey City |
NJ |
US |
|
|
Family ID: |
42267490 |
Appl. No.: |
13/932714 |
Filed: |
July 1, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12508987 |
Jul 24, 2009 |
8521632 |
|
|
13932714 |
|
|
|
|
10135834 |
Apr 30, 2002 |
|
|
|
12508987 |
|
|
|
|
Current U.S.
Class: |
705/36R |
Current CPC
Class: |
G06Q 30/018 20130101;
G06Q 40/06 20130101; G06Q 30/02 20130101 |
Class at
Publication: |
705/36.R |
International
Class: |
G06Q 40/06 20060101
G06Q040/06 |
Claims
1. A computer-implemented method of processing a body of data
representing a prospectus issued for at least one mutual fund, the
method comprising: (A) locating, within the body of data, one or
more data elements each having at least one attribute within a
predefined set of attributes; (B) inserting one or more markers
into the body of data to indicate the presence of the data
element(s) located in (A); (C) using the marker(s) inserted in (B),
generating a representation of the prospectus; and (D) making the
representation of the prospectus available for a recipient 3
access.
2. The method of claim 1, wherein the representation of the
prospectus is a summary prospectus.
3. The method of claim 2, wherein the act (D) comprises making the
summary prospectus available in hard copy and/or online form.
4. The method of claim 3, wherein the act (D) comprises making the
summary prospectus available in hard copy and online form, with the
hard copy summary prospectus including a uniform resource locator
(URL) at which the online summary prospectus may be accessed.
5. The method of claim 3, wherein the act (D) comprises making the
summary prospectus available in online form, the online summary
prospectus comprising a plurality of sections each including at
least one data element located in (A) and a link to detailed
information regarding the at least one data element.
6. The method of claim 5, wherein the link is to a location within
the body of data representing the prospectus.
7. The method of claim 6, wherein the body of data representing the
prospectus comprises a table of contents, and wherein the location
is proximate to the table of contents.
8. The method of claim 6, wherein the body of data representing the
prospectus comprises a portion which provides information regarding
the at least one data element, and wherein the location is
proximate to the portion.
9. The method of claim 5, wherein, subsequent to issuance of the
prospectus for the at least one mutual fund, a more recent
prospectus was issued for the at least one mutual fund, and wherein
the link is to a location within a body of data representing the
more recent prospectus.
10. The method of claim 5, wherein, subsequent to issuance of the
prospectus for the at least one mutual fund, a more recent
prospectus was issued for the at least one mutual fund, wherein the
body of data representing the more recent prospectus comprises a
table of contents, and wherein the link is to a location proximate
to the table of contents.
11. The method of claim 1, wherein each of the one or more data
elements is selected from a group of data elements for the at least
one mutual fond consisting of an investment objective, a fee or
expense, a principal investment strategy, a principal risk, an
annual total return, an investment advisor, a portfolio manager, a
rule relating to a purchase or sale, and information on payments to
an intermediary.
12. The method of claim 1, wherein the act (C) comprises generating
the representation of the prospectus to include the one or more
data elements arranged in a predefined sequence.
13. The method of claim 12, wherein the predefined sequence is
established by the United States Securities and Exchange Commission
(SEC).
14. The method or claim 1, wherein the acts (A)-(D) are performed
automatically upon the body of data representing the prospectus
being filed with the SEC's Electronic to Data Gathering. Analysis
and Retrieval (EDGAR) database by the issuer of the at least one
mutual fund.
15. The method of claim 1, wherein the act (C) comprises generating
a representation of the prospectus which includes one or more
branding elements associated with an entity.
16. The method of claim 15, wherein the entity is an issuer of the
at least one mutual fund.
17. The method of claim 15, wherein the entity is a
broker-dealer.
18. The method of claim 1, further comprising: (E) storing the
representation of the prospectus in a repository.
19. The method of claim 18, wherein the prospectus for the at least
one mutual fund is one of a plurality of prospectuses issued for
the at least one mutual fund over a period of time, and wherein the
repository further stores a representation of each of the plurality
of prospectuses.
20. The method of claim 19, further comprising: (F) making the
representation of each of the plurality of prospectuses
electronically accessible to a user.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 12/508,987, filed Jul. 24, 2009, which is a
continuation-in-part of U.S. patent application Ser. No.
10/135,834, filed Apr. 30, 2002, the entirety of which are
incorporated herein by reference.
FIELD
[0002] This invention relates to processing information relating to
securities, such as compliance information relating to a mutual
fund or other non-corporate security.
BACKGROUND INFORMATION
[0003] Government agencies and securities exchanges require that
certain information on a security be made available to an investor
before the security may be sold to the investor, and that certain
information be delivered to the investor with the confirmation of
any transaction. The delivery of this information has historically
taken place either in person, or via document delivery services,
such as the U.S. Mail, Federal Express, or United Parcel Service.
Recently, government agencies and securities exchanges have begun
allowing securities issuers and intermediaries to comply with
information delivery requirements by approving the delivery of the
information in an electronic format, for example, by transmitting
the information from one computer to another over a computer
network.
[0004] Securities information is available in various electronic
databases, including the United States Securities and Exchange
Commission's ("SEC's") EDGAR database. EDGAR, the Electronic Data
Gathering, Analysis, and Retrieval system, performs automated
collection, validation, indexing, acceptance, and forwarding of
submissions by companies and others that are required by law to
file information with the SEC. The primary purpose of EDGAR is to
increase the efficiency and fairness of the securities market for
the benefit of investors, corporations, and the economy by
accelerating the receipt, acceptance, dissemination, and analysis
of time-sensitive corporate information filed with the agency.
EDGAR information is available on the Internet at www.sec.gov.
[0005] Although securities information is available from databases
like EDGAR, the information is not provided in a useful electronic
format that enables compliance with government and securities
exchange regulations, especially with regard to mutual funds and
other non-corporate securities. EDGAR, as a result of its design,
makes information regarding non-corporate securities difficult to
find. In EDGAR, mutual fund information, for example, is listed as
a submission of the corporate issuer, not the fund name that is
marketed to the consumer, and one submission may include
information for more than one mutual fund. EDGAR submissions also
may include updates and amendments to earlier submitted
information. It is quite possible for a single mutual fund to have
more than fifty amendments to its compliance information. An
investor attempting to locate the complete set of compliance
information for a mutual fund directly from EDGAR would need to
retrieve all applicable amendments. This is time consuming, and it
is difficult for the investor, when attempting to gather compliance
information from EDGAR, to now if all the amendments have actually
been located, if the retrieved information about the fund is
complete, or if the retrieved information is up to-date.
SUMMARY OF THE INVENTION
[0006] Some embodiments of the invention provide a
computer-implemented method of processing a body of data
representing a prospectus issued for at least one mutual fund. The
method comprises: (A) locating, within the body of data, one or
more data elements each having at least one attribute within a
predefined set of attributes; (B) inserting one or more markers
into the body of data to indicate the presence of the data
element(s) located in (A); (C) using the marker(s) inserted in (B),
generating a representation of the prospectus; and (D) making the
representation of the prospectus available for a recipient to
access.
[0007] Other embodiments of the invention provide a
computer-implemented method of providing information relating to at
least one mutual fund to a user. The method comprises: (A)
processing data representing a statutory prospectus issued for the
at least one mutual fund to retrieve one or more data elements,
each satisfying predefined attributes, from the data, the data
representing the statutory prospectus including detailed
information corresponding to each of the one or more data elements;
(B) generating a summary prospectus comprising the one or more data
elements; and (C) making the summary prospectus available to the
user in a form that enables access to the detailed information
corresponding to each of the one or more data elements.
[0008] Still other embodiments of the invention provide a
computer-implemented method of providing information relating to at
least one mutual fund. The method comprises: (A) making available
to a user a representation of a statutory prospectus for the at
least one mutual fund, the statutory prospectus comprising detailed
information for the at least one mutual fund, the representation of
the statutory prospectus comprising one or more data elements found
within the statutory prospectus, each of the one or more data
elements corresponding to a portion of the detailed information,
the representation of the statutory prospectus being made available
to the user in a form which enables the user access to the detailed
information corresponding to each of the one or more data
elements.
[0009] Still other embodiments of the present invention provide a
computer implemented method of processing data representing a
statutory prospectus for at least one mutual fund and a summary
prospectus corresponding to the statutory prospectus. The method
comprises: (A) identifying, within the data representing the
summary prospectus, one or more data elements, each having at least
one attribute within a predefined set of attributes; (B) locating,
within the data representing the statutory prospectus, one or more
portions comprising detailed information, each portion comprising
detailed information which corresponds to one of the one or more
data elements; (C) inserting, within the data representing the
summary prospectus, at least one reference for each data element
located in (A), wherein each reference for a data element is to a
portion corresponding to the data element located in (B); and (D)
enabling a user to employ a reference inserted in (C) to access a
portion of the data located in (B) corresponding to a data
element.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] In the drawings, like reference characters generally refer
to the same parts throughout the different views. Also, the
drawings are not necessarily to scale, emphasis instead generally
being placed upon illustrating the principles of the invention.
[0011] FIG. 1 is a representation of an example hard copy summary
prospectus, in accordance with sonic embodiments of the present
invention;
[0012] FIG. 2 is a representation of an example online version of a
summary prospectus, in accordance with some embodiments of the
invention;
[0013] FIG. 3 is a flowchart of an example method for processing
compliance information, in accordance with some embodiments of the
present invention;
[0014] FIG. 4 is a block diagram of an example system for
processing information, in accordance with sonic embodiments of the
invention;
[0015] FIG. 5 is a block diagram of an example system for storing
and retrieving information, in accordance with some embodiments of
the invention;
[0016] FIG. 6 is a block diagram of an example information
obtainment and storage system, in accordance with some embodiments
of the invention;
[0017] FIG. 7 is a flowchart of an example method for responding to
requests for information, in accordance with sonic embodiments of
the invention;
[0018] FIG. 8 is a representation of an example interface
displaying retrieved information, in accordance with some
embodiments of the invention;
[0019] FIG. 9 is a flowchart of an example method for retrieving
information, in accordance with some embodiments of the
invention;
[0020] FIG. 10 is a representation of an example interface
displaying retrieved information, in accordance with some
embodiments of the invention;
[0021] FIG. 11 is a flowchart depicting an example method for
identifying an item of information for cataloging, in accordance
with some embodiments of the invention;
[0022] FIG. 12 is a flowchart depicting an example method for
identifying and/or assigning an effective date for an item of
information, in accordance with some embodiments of the
invention;
[0023] FIG. 13 is a flowchart depicting an example method for
assessing the quality of an item of processed information, in
accordance with some embodiments of the invention;
[0024] FIG. 14 is a block diagram of an example system for storing
and retrieving items of compliance information, in accordance with
some embodiments of the invention;
[0025] FIG. 15 is a block diagram of an example compliance
information server, in accordance with some embodiments of the
invention;
[0026] FIG. 16 is a flowchart of an example method for responding
to requests for compliance information, in accordance with some
embodiments of the invention;
[0027] FIG. 17 is a flowchart of an example method for identifying
and locating a data element, in accordance with some embodiments of
the invention;
[0028] FIG. 18 is a block diagram depicting an example system for
identifying and locating a data element within source information,
according to some embodiments of the invention;
[0029] FIG. 19 is a representation of example tagged data, in
accordance with some embodiments of the invention;
[0030] FIG. 20 is a representation of example tagged data, in
accordance with some embodiments of the invention;
[0031] FIG. 21 is a representation of example tagged data, in
accordance with some embodiments of the invention;
[0032] FIG. 22 is a flowchart of an example method for retrieving
and employing an anchor to retrieve source information, in
accordance with some embodiments of the invention;
[0033] FIGS. 23A-23D are block diagrams collectively depicting a
system for managing information related to publicly traded
securities;
[0034] FIG. 24 is a flowchart of an example print run process, in
accordance with embodiments of the invention;
[0035] FIG. 25 is a block diagram depicting an example technique
for identifying client accounts, holdings and documents for
inclusion in a print run, in accordance with some embodiments of
the invention;
[0036] FIG. 26 is a representation of an example data record for
inclusion in one or amore printed compliance documents in a print
run, in accordance with some embodiments of the invention;
[0037] FIG. 27 is a block diagram depicting an example computer
which may be employed to implement aspects of embodiments of the
invention; and
[0038] FIG. 28 is a block diagram depicting an example storage
medium on which may be stored instructions and data which may be
employed to implement aspects of embodiments of the invention.
DESCRIPTION
I. Overview
[0039] Various embodiments of the invention provide capabilities
designed to improve the clarity of disclosure materials provided by
securities issuers to investors, by enabling securities issuers
and/or intermediaries (e.g., broker/dealers, other distributors,
etc.) to create and disseminate clear, concise summary-level
information on individual securities to investors and potential
investors (hereinafter collectively referred to as "investors" for
simplicity and convenience), so as to enable investors to make
informed investment decisions.
[0040] This information may include, for example, a summary version
of the full statutory prospectus which all securities issuers are
required to provide to investors This summary version is referred
to herein as a "summary prospectus." In some embodiments, a summary
prospectus may include a concise, "plain English" synopsis and/or
representation of certain information contained in the full
statutory prospectus (to which the summary prospectus may, in some
embodiments, be a counterpart), such as a security's investment
objectives and strategies, costs, and risks, etc. Information in
the summary prospectus may be presented in a standardized sequence
(e.g., defined by the Securities and Exchange Commission), with
certain key information being presented in individual sections. In
addition to a concise synopsis and/or representation of key
information, the summary prospectus may indicate to the investor
where more detailed information on each topic addressed in the
summary prospectus may be found, such as via references to
locations in the full statutory prospectus and/or other documents,
so that it facilitates a "layered disclosure" of information about
the security, with information in the summary prospectus forming a
first layer and information in underlying detailed documents
forming further layers.
[0041] in some embodiments, a summary prospectus may be
disseminated at least in part via the Internet (e.g., via email,
presented on a web page, etc) to facilitate the layered disclosure
of information on one or more securities to investors. For example,
a hard copy summary prospectus delivered to an investor may include
a reference (e.g., a Uniform Resource Locator, or URL) to a web
page presenting an online version of the summary prospectus which
largely replicates the standardized order in which information is
presented by the hard copy summary prospectus. Each section of the
online version of the summary prospectus may include one or more
links to more detailed information on the summary-level information
on a given topic presented in the section. For example, each link
may reference a location within an electronic version of the full
statutory prospectus or another document. As such, the investor may
readily navigate between sections of the summary prospectus and
more detailed information provided within one or more other
documents as desired. As a result, materials disclosing important
information about the security may be made more accessible and
user-friendly to the investor, as well as to intermediaries,
financial analysts and other users, enabling these parties to more
easily compare different securities across one or more dimensions,
and thereby make more informed investment decisions.
[0042] An example format for a summary prospectus and corresponding
online version are depicted in FIGS. 1 and 2, respectively. Example
summary prospectus 100 (FIG. 1) includes an indication 101 of a
security to which it relates, a title 102, and various sections
each providing information about the considered security in
summary-level, synopsis form. For example, section 103 provides
information on the security's investment objective, section 104
provides information on its associated fees and expenses, section
105 provides information on its principal investment strategies,
section 106 provides information on principal risks associated with
its investments, section 107 provides information on annual returns
earned in prior periods, section 108 provides information on its
investment advisor, section 109 provides information on its fund
manager, section 110 provides information on the purchase and sale
of security shares, dividends, capital gains and taxes, and section
111 provides information on payments to broker/dealers and/or other
intermediaries. Of course, a summary prospectus is not limited to
presenting the information shown in example summary prospectus 100,
as any suitable information (including additional or different
information) regarding any one or more securities may be presented.
In addition, a summary prospectus may present information relating
to a mutual fund, although the invention is not limited to such an
implementation. Embodiments of the invention may provide
information relating to any one or more types of securities,
including mutual funds, variable annuities, exchange traded funds,
and/or any other type(s) of security. Embodiments of the invention
are not limited to any particular implementation.
[0043] Summary prospectus 100 also includes URL 112, which in the
embodiment depicted references an online version of the summary
prospectus which provides an investor with access to more detailed
information on the security. If summary prospectus 100 is provided
to the investor in hard copy, printed form, then the investor may
enter the URL into the address bar provided by a browser program
(not shown) to access the online version. If summary prospectus 100
is provided to the investor in electronic form (e.g., in an
electronic document e-mailed to the investor), then the URL may be
"clickable" by the investor to bring the investor to the online
version.
[0044] An example online version 200 of summary prospectus 100 is
shown in FIG. 2. In many respects', online version 200 is similar
to summary prospectus 100, as it includes much of the same
summary-level information included in summary prospectus 100,
presented in much the same order. Specifically, in the example
shown, online version 200 includes indication 201 of the security
to which the web page relates, title 202, and sections 203-211
which correspond to sections 103-111 shown in FIG. 1. Of course,
the invention is not limited to such an implementation, as an
online version of a summary prospectus may include any suitable
information, which may or may not correlate directly to information
presented in a summary prospectus. The invention is not limited to
any particular implementation.
[0045] In example online version 200, each of sections 203-211
includes the same information as is presented in the corresponding
section of summary prospectus 100, as well as a link (e.g., a
hypertext link) to more detailed information regarding the
considered topic. For example, section 204 includes information on
the security's fees and expenses, and includes link 214 which
references more detailed information on the security's fees and
expenses, which (in this example) is included within an electronic
version of a full statutory prospectus 250 for the security, which
includes information on discounts and/or exemptions for inventors
who satisfy certain criteria. By clicking link 214, the investor is
taken to location 251 within the statutory prospectus which
includes this detailed information so that the investor may review
the detailed information before deciding whether to invest in the
security.
[0046] Of course, a link within an online version of a summary
prospectus need not reference a statutory prospectus, as any
suitable document(s) or information may be referenced. For example,
section 209 includes information on the security's fund manager,
and includes link 219 which references more detailed information on
the fund's manager. If the investor notices that there has been a
change to the security's fund manager since he/she last reviewed
disclosure information (e.g., the last statutory prospectus sent to
the investor), he/she may click link 219, which in this example
references a location within an electronic version of a supplement
260 (i.e., a "sticker") to the prospectus. The supplement may have
been issued after the last full statutory prospectus, and may
provide more up-to-date detailed information regarding the new fund
manager, such as his/her prior management experience and/or tenure
at the securities issuer, than the last statutory prospectus.
[0047] It should be appreciated that a link within an online
version of a summary prospectus need not reference a specific
location within an underlying detailed document at which detailed
information is contained. For example, a link may reference a table
of contents in an underlying document (or other information) which
indicates to the investor where information on a considered topic
may be found, may reference a start of the document (allowing the
investor to find the detailed information herself), or reference
any other suitable location(s).
[0048] In example online version 200, each section includes a link
to more detailed information. Thus, in this example, a user may
click on link 213 to access detailed information on the security's
investment objective, link 214 to access detailed information on
its associated fees and expenses, link 215 to access detailed
information on its principal investment strategies, link 216 to
access detailed information on principal risks associated with its
investments, link 217 to access detailed information on annual
returns earned in prior periods, link 218 to access detailed
information on its investment advisor, link 219 to access detailed
information on its fund manager, link 220 to access detailed
information on the purchase and sale of shares, dividends, capital
gains and taxes, and link 221 to access detailed information on
payments to broker/dealers and/or other intermediaries. It should
be appreciated that an online version need not include a link in
each section, no link, or more than one link, may be provided in a
section of an online version. Embodiments of the invention are not
limited to any particular implementation.
[0049] Using the links provided in online version 200 to access
underlying detailed information, the investor may readily navigate
between "layers" of disclosure on the security, In this respect,
the disclosure in summary prospectus 100 may be considered as
providing a first layer of information, including a concise
synopsis of certain key information considered important to many
investors. Using URL 112, the investor may access the second layer
provided within online version 200, which may include much the same
information as summary prospectus 100 but also enable access to
underlying detailed information. Using the links provided in online
version 200, the investor may so access this detailed information,
and move back and forth between detailed and summary-level
information, thereby quickly and easily gaining access to
information on the topic(s) that he/she considers most important
when selecting a security for investment.
[0050] Some embodiments of the invention provide a system for
making a summary prospectus and/or online version thereof available
to investors. For example, when a securities issuer publishes a new
summary prospectus for a security (e.g., by submitting it to
EDGAR), embodiments may automatically acquire the summary
prospectus document, process it to identify certain information
contained therein, and prepare it for dissemination via any of
various media. For example, processing the document to identify
information contained therein may enable creation of an online
version of the document, as well as logical associations between
the information in the summary prospectus and corresponding
detailed information provided in other documents (which may be
similarly processed via embodiments of the invention to identify
this detailed information and/or its location within the other
documents). These logical associations may be used to create
references (e.g.; hypertext links) which are included within the
online version, thereby enabling the user to accomplish the
navigation between summary level and detailed information described
above.
[0051] Some embodiments of the invention provide an online facility
with which not only an online version of a summary prospectus, but
also other documents and materials relating to a considered
security, may be made available to investors. For example, the
online facility may provide access to a repository of documents
disseminated over time by the issuer and/or distributors of the
security. The facility may, for example, allow investors reviewing
an online version of a summary prospectus (e.g., after entering a
URL provided in a hard copy summary prospectus into a browser
application) to readily determine whether more current information
on the security (e.g., a newer summary prospectus, perhaps
referenced by a URL in a newer hard copy summary prospectus than
that which was reviewed by the investor) is available, in addition,
the facility may allow the investor access to historical detail on
the security.
[0052] Some embodiments of the invention may provide a capability
to prepare a summary prospectus for dissemination in hard copy
form. For example, some embodiments of the invention may provide a
service provider with the capability to alter the aesthetic,
characteristics and/or content of a document submitted by a
securities issuer to EDGAR, such as by adding branding elements or
other visual enhancements supplied by the securities issuer and/or
distributor, such as a broker/dealer through which the investor
purchased the security. Some embodiments of the invention may also
provide a capability to suppress the creation and/or delivery of
certain versions of the summary prospectus (e.g., to suppress
delivery to investors that previously received those versions).
Aspects of these embodiments are discussed in greater detail
below.
[0053] The sections which follow describe various systems and
processes that enable the creation and/or dissemination of a
summary prospectus, and underlying detailed documents, in online
and hard copy form. For example, Section II describes systems and
methods for identifying a summary prospectus published by a
securities issuer and/or intermediary (e.g., to EDGAR) and storing
the summary prospectus in a document repository. Section III
describes systems and methods for processing the summary prospectus
to identify certain information contained therein, and to create
logical associations between this information and more detailed
information provided in underlying documents. Section IV describes
systems and methods for using these logical associations to create
references between sections of an online version of a summary
prospectus and corresponding information in other documents, which
may allow an investor to navigate between the online version and
the underlying documents as desired. Section V describes how these
systems and methods described in Sections II-IV may be used to
disseminate a summary prospectus and/or online version thereof to
investors and/or other parties.
II. Acquiring Compliance Information
[0054] Commonly assigned U.S. Pat. No. 6,122,635, entitled "Mapping
Compliance Information Into Useable Format," filed Feb. 13, 1998,
the entirety of which is incorporated herein by reference,
discloses systems and methods which may be employed to acquire
information from one or more databases (e.g., EDGAR) identify the
information as comprising a statutory and/or summary prospectus
document for a particular security, and create and store a
computer-readable file containing the information for further
processing. Relevant portions of the '635 patent are reproduced
below for the reader's convenience.
[0055] A process 11 for acquiring, identifying and creating a
computer-readable the representing compliance information (one
example of which is a summary prospectus) is depicted in FIG. 3.
Process 311 includes acquiring securities information from one or
more database sources (Step 310). One or more portions of the
acquired securities information is identified as being compliance
information related to a particular security and extracted from the
securities information (Step 312). A computer-readable file is then
created which includes the compliance information (Step 314). This
computer readable file, identified as being the compliance
information for a particular security, may then be stored and/or
transmitted electronically to investors.
[0056] In one aspect of the invention, the method 311 shown in FIG.
4 is accomplished by one or more persons operating a programmed
computer system. A block diagram of such a computer system is shown
in FIG. 4. The computer may be implemented in any suitable manner,
as the particular type and capabilities of the computer is not
central to the invention. The invention may be implemented in a
variety of ways, including an all-hardware embodiment in which
dedicated electronic circuits are designed to perform all of the
functionality that the programmed computer can perform. An example
of the present invention is an implementation in software for
execution on a general purpose computer such as a PC running a
version of the Microsoft Windows.RTM. operating system.
[0057] Referring to FIG. 4, the general purpose computer 444
typically includes a central processor 446, a main memory unit 448
for storing programs and/or data, an input/output (I/O) controller
450, a display device 451, and a data his 454 coupling these
components to allow communication therebetween. The memory 448
generally includes random access memory (RAM) and read only memory
(ROM). The computer 444 typically also has one or more input
devices 456 such as a keyboard 458, and a mouse 460. The computer
typically also has a hard drive 462 with hard disks therein and a
floppy disk drive 464 for receiving floppy disks such as 3.5 inch
disks. A data communications interface 452 such as a modem, an
Ethernet card, or other network interface allows communication with
other computers on a LAN, intranet or Internet. Other devices also
can be part of the computer 444 including output devices 466 (e.g.,
printer or plotter) and/or optical disk drives for receiving and
reading digital data on a CD-ROM. In the present invention, one or
more computer software programs define the operational capabilities
of the computer 444. These software programs may be loaded onto the
hard drive 462 and/or into the memory 448 of the computer via the
floppy disk drive 464 or the data communications interface 452.
[0058] Referring to FIG. 5, one aspect of the present invention
includes a computer 592 connected to a network 594 via a data
communications interface 552. Computer programs that implement an
embodiment of the invention are stored on a program server 590,
which is another computer, that can be implemented by a general
purpose computer 444. Generally, the program server 590 has high
performance components, such as a high speed processor 446 and hard
drive 462, and a large amount of memory 448. The programs may be
stored on the server 590 in, for example, HTML and Java languages.
The computer 592 runs commercially available worldwide web browser
software, such as Netscape Navigator.RTM. or Microsoft Explorer.
The browser software, downloads the HTML and Java programs from the
program server 590, and executes the programs. The use of a network
594 and browser software makes the programs available to a large
number of computers on the network simultaneously. This facilitates
operation of the system by multiple users at the same time.
[0059] Referring to FIG. 6, one aspect of the present invention
includes an obtainment system 600. Obtainment system 600 contains
an acquisition subsystem 610, a cataloging subsystem 612, a
splitting subsystem 614, an effective date subsystem 616, and a
quality assurance subsystem 618. Obtainment system 600 receives
input from an identification list 603, securities submissions
sources 605, and other data sources 607. Obtainment subsystem 600
produces compliance information (e.g., a summary prospectus) that
may be delivered to a customer, or stored in a compliance
information database 625 for subsequent delivery to a customer.
[0060] The acquisition subsystem 610 receives input from the
securities submission sources 605 and other data sources 607. The
securities information acquired by acquisition subsystem 610 is
placed on a cataloging queue 630.
[0061] Cataloging subsystem 612 retrieves the securities
information from the cataloging queue 630 and catalogs it. The
cataloging subsystem 612 also receives as input, the securities
information from the cataloging queue 630, as well as
identification list 603, and other data 607. After cataloging, the
securities information is placed on the splitting queue 632.
[0062] The splitting subsystem 614 retrieves the securities
information from the splitting queue 632. After the splitting
subsystem 614 determines start and end points of each item of
compliance information in an item of securities information, the
securities information is placed on the effective date queue
634.
[0063] The effective date subsystem 616 retrieves the securities
information from the effective date queue 634, and determines an
effective date for each item of compliance information (e.g., a
summary prospectus) in the securities information. The compliance
information is then placed on the quality assurance queue 636.
[0064] The quality assurance subsystem retrieves the securities
information from the quality assurance queue 636. The compliance
information is reviewed in the quality assurance subsystem 618, and
then output from the obtainment system 600.
[0065] Referring to FIGS. 5 and 6, a system operator uses the
computer 592 executing a browser program to connect to program
server 590. Upon connecting to the program server 590, the system
operator chooses, or is assigned, a particular subsystem. The
system operator chooses or is assigned items on the respective
input queue for that subsystem and operates the subsystem to
process the retrieved data.
[0066] By dividing the system 600 into multiple subsystems and
queued input for each subsystem, the processing of the documents is
divided up into sub-tasks. Multiple system operators can be
assigned to one of the sub-tasks, and can therefore process
securities information simultaneously. For example, if there are
four system operators, the first system operator may process a
first securities information document in the cataloging subsystem,
a second system operator may process a second securities
information document in the cataloging subsystem, a third system
operator may process a third securities information document in the
splitting subsystem, and a fourth system operator may process a
fourth securities information document in the QA subsystem. Using
multiple system operators allows for rapid processing of securities
submissions through the system.
[0067] Acquisition subsystem 610 extracts files from the securities
information source that contain securities information relevant to
the subset of securities for which the user desires compliance
information according to a process as shown in FIG. 7. In one
aspect of the present invention, the securities submission source
is queried to extract all the files associated with a particular
company, step 702. The particular company may be determined by its
central index key or by the company name. Because this may not be
the first access for that particular company, the sources are
compared to the information that is already in the database that is
part of the system, so that the same document is not acquired
twice, step 704. The subsystem thereby acquires submissions
regarding securities that the user is interested in and that have
not been previously processed, step 706. The acquisition subsystem,
step 708, associates the retrieved securities filing documents with
the particular company and then the acquisition subsystem passes
the submissions to the cataloging subsystem 612.
[0068] As part of its service, EDGAR provides an index to the
securities information added each day. In one aspect of the present
invention, the acquisition subsystem 610 automatically acquires
those documents that were added that day. The EDGAR index lists a
central index key associated with each item of securities
information. Acquisition subsystem 610 uses the EDGAR index to
acquire the most recent information for a specific list of central
index keys, step 710. The list of central index keys is determined
from a list of securities, each of which has a unique identifier.
For example, a list of securities identified by CUSIP number or
stock ticker symbol may be mapped into a list of central index
keys. Specific entries in the EDGAR index are identified, step 712,
and then retrieved, step 714. The process then proceeds to step 708
as described above.
[0069] The cataloging subsystem 612 presents the system operator
with the securities submissions that are relevant. The system
operator inspects each submission and catalogs it according to the
information contained within. Each submission may contain several
items of compliance information. The system operator identifies the
particular securities about which the submission contains
compliance information.
[0070] Another aspect of the present invention scans the submission
taken from the cataloging queue and searches for and identifies
possible references to securities within the submission. The
operator would then be directed to the locations of these
identified securities within the submission in order to verify.
[0071] Any one or more of an internal identification number, CUSIP
identifiers and stock ticker symbol may be used to identify a
particular security. The internal identification number is unique
for each security. A CUSIP number is a number assigned by Standard
&. Poor's CUSIP Service Bureau, the manager of the American
Banking Association's CUSIP number system, to identify a security.
A stock ticker symbol is a symbol assigned by a stock exchange to
identify a security. An investor is most likely to reference a
security, such as a mutual fund, by any one of: the fund name
marketed to the consumer, the CUSIP number, or the stock ticker
symbol, and not by the investment company name or the central index
key.
[0072] For example, a section 800 of securities information
acquired from the SEC EDGAR database is shown in FIG. 8. The
section 800 may include a company data portion 802 including a
company name 804, a central index key 806, an IRS number 808, an
address 810 and, if applicable, former company name(s) 812. The
company data indicates the source of the submission (not shown),
but does not necessarily specify the securities described in the
submission. A particular investment management fund may have one to
hundreds of funds, and information about all or some subset of
those funds may be in one or more particular EDGAR submission.
[0073] Operation of one example of a cataloging subsystem 612 is
presented in FIG. 9. A securities submission from the cataloging
queue 630 is presented to a system operator and retrieved at step
900. In one example of operation, as shown in FIG. 10, the
securities submission portion 900 may be visible in one section of
a display screen 1000 and cataloging information 1002 may be
visible on another section. A unique line number 1004 is assigned
to each line of the securities submission 900 at step 902. The
securities submission is not permanently modified to include the
line numbers, rather, the line numbers are shown only for the
purpose of aiding in the cataloging and extracting of the
compliance information.
[0074] The cataloging section 1002 of the screen 1000 presents a
list of cataloging choices as retrieved m step 904. Cataloging
choices include possible CUSIP numbers or stock ticker symbols, the
type of compliance information contained in the document for
example prospectus, statement of additional information (SAI),
etc.), and the start line of each item of compliance information.
As the system operator reviews the securities submission, the
system operator selects the appropriate cataloging choices.
[0075] The operator, aided by the cataloging subsystem, compares
the list of cataloging choices to the contents of the retrieved
file, step 906. If a cataloging choice is located in the retrieved
file, step 908, control passes to step 910. At step 910, the line
number associated with the start of the identified cataloging
choice is recorded. If the processing of the file is not complete,
as determined in step 912, the process returns to step 906. If the
file has completed processing, at step 914, a next file is
retrieved from the cataloging queue and the process returns to step
902.
[0076] The splitting subsystem 614 determines the starting line and
ending line of the compliance information that the system will use
to extract compliance information from the securities submissions
documents. For example, if the submission contains two SAIs, each
for a different security, the starting and ending lines of the two
items of compliance information will be associated with their
respective security. The spitting subsystem presents the system
operator with the securities submission and the catalog data for
that submission. The system operator verifies the starting line and
specifies the ending line of each item of compliance information.
When the starting and ending line numbers of compliance information
in the securities submission have been identified, the securities
submission is then placed on the effective date queue.
[0077] In one embodiment, the splitting subsystem 614 is accessed
at least two times for each securities submission by two different
system operators. The starting and ending line numbers identified
by the two system operators are compared in the quality assurance
subsystem to confirm accuracy.
[0078] In one example of the system, the splitting subsystem 614
also determines whether the compliance information relates to, or
is associated with, more than one security. For example, for a
bundled product such as a variable annuity fund, an EDGAR filing
may be related to more than one investment product. One item of
compliance information may be applicable to many different
investment products. This association, as determined in the
splitting subsystem, is used later to associate the compliance
information with the relevant securities. Alternatively, in other
versions of the system, this association may occur in the
cataloging subsystem 612, or the effective date subsystem 616.
[0079] Operation of one example of the splitting subsystem 614 is
presented in FIG. 11. An entry from the splitting queue is
retrieved at step 1102. An associated cataloging choice and a
starting line number for the cataloging choice are retrieved from
the entry in the splitting queue, step 1104. That portion of the
associated securities filing document including the retrieved line
number is accessed, step 1106. Am ending line number for the
retrieved cataloging choice is determined at step 1108. The
determined ending line number is associated with the associated
cataloging choice in the effective date queue at step 1110. At step
1112, it is determined whether or not there are more entries in the
splitting queue to be processed. If there are more entries to be
processed, control returns to step 1102 to process the next entry,
otherwise the process is stopped.
[0080] As shown in FIG. 12, the effective date subsystem 616
supports a determination of an effective date of the documents
produced by the cataloging process. The system operator retrieves a
file from the effective date queue, steps 1202, 1204, and
determines the respective effective date of the information
therein. If the system operator cannot determine the effective
date, but the compliance information has been determined to be a
prospectus, and the system operator can determine the filing type,
filing date and the prospectus date, then the system operator can
determine the effective date, step 1206, through knowledge of
applicable filing requirements and features built into the system,
such as an automatic obsolescence feature that relates to the age
of the document. After the effective date has been determined, the
securities submission and its associated effective date are
associated and placed on the quality assurance queue, step
1208.
[0081] The effective date is determined based on the type of
securities submission. For example, if the securities submission
contains a 497 or 485BPOS filing, then the prospectus date is
generally the effective date. If the document is a 485APOS filing,
then the filing date is the "Filed As Of Date." The effective date
is generally either the prospectus date or the filing date plus
sixty days, whichever is later. If the prospectus registers a new
series of stock, however, then the effective date is either the
prospectus date or the filing date plus seventy-five days,
whichever is later. If the prospectus date is incomplete, for
example "January ______, 2008," the operator can use his or her
knowledge of applicable filing requirements to determine the
effective date. For 497 and 485BPOS filings, for example, the
filing date is the effective date, and for 485APOS, the effective
date is sixty days after the filing date, unless it is registering
new shares, in which case the effective date is seventy-five days
after the filing date.
[0082] In one version of the system, the effective date subsystem
616 also determines if the compliance information is amending
another item of compliance information. If it is an amendment, the
compliance information is effective when the compliance information
it is amending is effective. The effective date system sets the
effective lifespan, i.e., a date the compliance information is
effective and a date that it is no longer effective, to that of the
amended compliance information. There are other relationships
between submission types and effective dates that may be used to
determine the effective date of a document being used as the basis
for compliance information.
[0083] The quality assurance subsystem 618 is the final subsystem
in the chain before the compliance information is output from the
obtainment system. The quality assurance subsystem 618 aids an
operator in the inspection of the compliance information. The
system operator chooses, or is assigned, an item from the quality
assurance queue, step 1302, as shown in FIG. 13. The system
operator verities, step 1304, that the securities submission
referenced in the retrieved item has been processed by all
subsystems. If not, at step 1306 the item is placed in the queue
for the first subprocess that was missed. The system operator
verifies that the catalog information is correct, and verifies the
effective date, the document type, the issuer, the fund, the class,
whether the document is complete, whether there is extra data,
whether the document is properly formatted, as well as any other
relevant information.
[0084] In the example in which the splitting subsystem 614 is
accessed twice independently, the quality assurance system nay
compare the starting and ending lines specified by the previous two
splitting subsystem 614 system operators for each item of
compliance information. If any of the information for the retrieved
item is not complete, step 1308, the system operator may place the
securities submission on any of the queues for processing by a
subsystem, step 1310. Of course, if the analysis determines that
the processing should be repeated in more than one subsystem, the
quality assurance system operator may choose to place the
securities submission in the most "upstream" subsystem's queue.
Once the system operator has verified that the compliance
information will be extracted correctly, the extraction takes place
and the compliance information is output from the obtainment system
600.
[0085] Extraction involves copying information from the securities
submission document as a function of the starting and ending lines
determined within the obtainment system 600 as described above. Of
course, the same portion of the securities submission document may
be retrieved as relevant to different securities. Each security
would then have its own respective compliance information
document.
[0086] If, as determined at step 1312, an error occurred during
processing by any of the subsystems, for example if a securities
submission does not contain necessary information, then the
securities submission is placed on the error queue, step 1314. A
system operator may look at the securities submissions that have
been placed on the error queue at a later time to solve the
problems encountered.
[0087] Once output from the obtainment system, the compliance
information may be stored in a file system on either computer 592
or program server 590, step 1316. The compliance information may
also be stored in a compliance information server 625. At step
1318, if it is determined that there are more entries in the
quality assurance queue, control passes to step 1320 where the next
entry from the queue is retrieved. The process then starts again at
step 1304.
[0088] In one example, the compliance information server 625 may
include a document processor for converting the compliance
information from its native format, for example ASCII text or HTML
format, into another format, for example into Microsoft Word.RTM.
or Adobe Acrobat.RTM. format. Of course, the compliance
information, once extracted, may be kept in the source format as
the original financial submission. The compliance information is
then stored.
[0089] In one example of the present invention, the compliance
information server 625 is incorporated into the same machine as the
obtainment system 600. In this case a system for providing access
to compliance information would include obtainment system 600 and
an accessing system that incorporated compliance information server
625. In another embodiment the compliance information server 625 is
a separate server from the obtainment system 600.
[0090] Referring to FIG. 14, a compliance information server 625 is
shown connected to network 655. Client computer 650 running browser
software may access the compliance information server via the
network to retrieve the compliance information. The compliance
information server makes the compliance information available over
a network, such as a LAN, intranet or the Internet. In another
example, the compliance information server 625 distributes the
compliance information directly to a user or specified group of
users via the network. In yet another example, the compliance
information server notifies users when new compliance information
has become available at the server by sending a message over the
network.
[0091] The compliance information server 625 has access to the
compliance information as well as the catalog information about the
particular security associated with the compliance information. For
example, all of the compliance information for a particular
security may be listed. Because the compliance information server
has the information that was entered by the system operator when
the document was processed by the cataloging subsystem, all the
compliance information for a particular security may be accessed
either by the name of the security as it is marketed to the
customer, the CUSIP number of the security, or the stock ticker
symbol of the security.
[0092] Referring to FIG. 15, one example of a compliance
information server includes compliance information, an indexer, and
an output. The compliance information is stored on a hard disk
1500, but it also may be stored on other media, in memory, or on
another system that the compliance information server has access to
over the network. The compliance information includes the
compliance information produced by obtainment system 600.
Compliance information server 625 also includes catalog information
produced by system operators using obtainment system 600. An
indexer 1502 accesses the compliance information and the catalog
information and identifies all compliance information associated
with a particular security. Alternatively, indexer 1502 does not
use the catalog information 1501, but instead searches each item of
compliance information 1500 to determine the particular security
with which it is associated. Indexer 1502 may keep a list of the
compliance information stored on hard disk 400 to increase the
speed of production of a list of all compliance information
associated with a particular security.
[0093] A request to compliance information server 625 may come in
the form of a unique identifier for the security, such as an
internal identifier, a CUSIP number or a stock ticker symbol. The
indexer identifies the compliance information associated with that
unique identifier. The compliance information server may output a
list of the compliance information documents that are available.
Alternatively, it may output the compliance information. In one
example, the compliance information server receives a request for a
list of all the information for a particular security. The request
is in the form of a request for a web page. In response, the
compliance information server 625 outputs a list of the compliance
information. The list is in the form of a worldwide web page that
contains finks to each of the items of compliance information. The
worldwide web page may also contain links to other information
about that security.
[0094] Referring to FIG. 16, a method for responding to requests
for compliance information includes receiving a unique identifier
(step 1650). The unique identifier may be a unique internal
identifier, a CUSIP number, or a stock ticker symbol. The method
may also include transmitting compliance information in response to
receipt of the unique identifier (step 1652). The compliance
information server is capable of accomplishing the steps of the
method because the compliance information server has the compliance
information and it can associate the compliance information with
the particular security specified by the unique identifier.
[0095] It should be appreciated that the foregoing description with
reference to FIGS. 3-16 discloses a capability to either identify a
summary prospectus made available by a securities issuer as being
related to one or more particular securities and extract the
summary prospectus (e.g., from a larger body of data representing a
full statutory prospectus for the one or more securities), or to
identify a full statutory prospectus as being related to the one or
more securities from which a summary prospectus may be created. In
either case, one or more computer-readable files containing
extracted information may be created and stored (e.g., in a
repository containing other computer-readable documents relating to
the one or more securities), which may then be processed as
described in the following sections to either identify individual
data elements within a summary prospectus made available by a
securities issuer, or to create a summary prospectus from a full
statutory prospectus by identifying certain key data elements
within the statutory prospectus and copying or extracting them to a
summary prospectus.
III. Identifying Data Elements Provided within Compliance
Information
[0096] Commonly assigned U.S. patent application Ser. No.
10/135,834 discloses systems and methods which may be employed to
identify one or more particular data elements within a
computer-readable file containing summary prospectus information
(which may be identified using the system described above in
Section I) and to insert markers into the computer-readable file
indicating the presence of this data. Using this system (as an
example), individual sections of a summary prospectus document, and
various data elements included in each section, may be identified,
enabling the creation of an online version of the summary
prospectus.
[0097] Commonly assigned U.S. patent application Ser. No.
10/821,121, filed Apr. 8, 2004, entitled "System For Locating Data
Elements Within Originating Data Sources," the entirety of which is
incorporated herein by reference and relevant portions of which are
reproduced below, discloses techniques for employing these markers
to create logical associations between information included in
various documents. Using these techniques, for example, a summary
and statutory prospectus made available by a securities issuer may
be processed to insert references (e.g., links) into sections of an
online version of the summary prospectus to enable an investor to
navigate from the sections of the online version to underlying
detailed information provided in the statutory prospectus. In
another example, these techniques may be used to process a
statutory prospectus, identify certain key data elements contained
within, and generate a summary prospectus to include these key data
elements and references from sections of the summary prospectus
containing one or more of the data elements to portions of the
statutory prospectus providing more detailed information regarding
the data element(s).
[0098] Some embodiments of the invention provide a capability to
analyze one or more underlying documents (e.g., a statutory
prospectus) to identify the location(s) within the document(s) at
which detailed information corresponding to high-level information
provided in a summary prospectus is found. Once the location(s) are
identified, references may be created to corresponding detailed
information. Portions of the information at the identified
location(s) may be used to generate a summary prospectus, and the
references may be inserted into the appropriate sections of the
online version of the summary prospectus, so as to enable investors
to readily navigate between high-level information in the summary
prospectus and supporting detailed information contained in other
documents. Alternatively, if a summary prospectus is made available
by a securities issuer along with a corresponding statutory
prospectus, references to portions of the statutory prospectus may
be inserted into sections of the summary prospectus to enable
investors to navigate between the high-level information in the
summary prospectus and the supporting detail in the statutory
prospectus.
[0099] An example process for inspecting a document to identify the
location(s) at which information is found is depicted in FIG. 16.
In some embodiments, output from obtainment system 600 (e.g.,
summary prospectus information obtained from EDGAR, as well as
other documents providing underlying detailed information) is
provided as source documents in 1602. In 1604, the document(s) are
tagged, resulting in a tagged document in 1606. The tagged document
may enable tagged information therein to be retrievable, as
described below.
[0100] The identification of individual data items so that they may
be tagged is described in greater detail with reference to FIGS. 17
and 18. Specifically, FIG. 17 depicts a process for identifying
individual data items, and FIG. 18 depicts a system for performing
the method of FIG. 17.
[0101] At the start of the process of FIG. 17, in act 1710, a
receipt facility 1810 performs a preliminary identification of
source information 1800. For example, in an embodiment wherein
source information 1800 comprises a security filing, receipt
facility 1810 may identify the type of filing, the issuer, the
relevant security(ies), and/or other information. This may be
performed in any suitable fashion. For example, receipt facility
1810 may scan the source information 1800 and compare data found
therein with one or more data structures containing listings of the
known types of filing, securities, issuers, and/or other data. Upon
the preliminary identification of source information 1800 by
receipt facility 1810, act 1710 completes.
[0102] The process then proceeds to act 1720, wherein one or more
specific data elements are located within the source information
1800. In some embodiments, identification is performed by
processing facility 1820, which performs the identification and
location using output received from receipt facility 1810, as well
as input provided by a human user. Specifically, in some
embodiments, processing module 1820 receives output from receipt
facility 1810 which defines, based on the preliminarily
identification performed by receipt facility 1810, the type of
source information 1800. Processing facility 1820 uses this
information to access one or more of a collection of data
structures (e.g., flat files) which each contain one or more
encoded parameters that are descriptive of data elements commonly
found within the source information. Processing facility 1820
utilizes the encoded parameters to locate the data elements within
the source information. Once a data element has been located in the
source information, processing facility 1820 issues a prompt to a
human user via a graphical user interface (GUI) to confirm that the
data element has been correctly identified.
[0103] In some embodiments, encoded parameters are provided as text
within a data structure. One or more data structures may
collectively represent a "taxonomy" for a specific type of source
information interpreted by processing facility 1820. Specifically,
a taxonomy may define the characteristics of each of the data
elements commonly found within the considered type of source
information. A taxonomy may define data element characteristics for
any type of source information. For example, a taxonomy may define
characteristics of data elements within a type of securities filing
from all issuers (e.g., all mutual fund prospectuses), all filings
from a specific issuer, all filings from all issuers, or any other
suitable grouping of source information. Further, more than one
taxonomy may be applicable to a specific type of source
information. The invention is not limited in this respect.
[0104] A taxonomy may include one or more descriptive
characteristics for each data element to be identified within the
source information. For example, a taxonomy for a mutual fund
prospectus might provide parameters defining descriptive
characteristics for a "portfolio manager" data element as it
appears within a fund prospectus. For example, a parameter for the
portfolio manager data element may indicate that this data element
is normally accompanied by the text "portfolio manager" within the
source information. Any of numerous descriptive characteristics may
be provided as a parameter for a data element within a taxonomy.
For example, a parameter may indicate that a specific data element
is normally accompanied by specific text (as with the example
provided above), is normally found at a specific location within
the source information (e.g., at the end of the document, or at the
top of a page), normally receives a specific graphical treatment is
provided in a specific font, as an icon, and/or in a specific
color), or otherwise conforms to a rule regarding its appearance or
presence within source information.
[0105] A taxonomy may include more than one parameter for a
specific data element. For example, a taxonomy for a fund
prospectus may contain a first parameter for the portfolio manager
data element which indicates that it is normally accompanied by the
text "portfolio manager," a second parameter which indicates that
it is normally found at the top of the second page of the
prospectus, and a third parameter which indicates that it is
provided in a specific font. Further, a taxonomy may specify which
of these parameters must be satisfied in order for the data element
to be identified. For example, a taxonomy may specify that only the
first and second of the above-listed parameters must be satisfied
to identify the portfolio manager data element, that all three
parameters must be satisfied, that only one must be satisfied, or
any other suitable combination of these parameters. The invention
is not limited to a particular implementation in this respect.
[0106] In one embodiment, processing facility 1820 loads one or
more taxonomies to memory and implements the encoded parameters
therein as it processes the source information. In one embodiment,
as the processing facility 1820 reads the source information it
compares the characteristics of the source information with
characteristics represented in the parameters. As in the example
provided above, the taxonomy for a specific type of source
information may contain a parameter which indicates that the
presence of the text "portfolio manager" within that source
information indicates the presence of the portfolio manager data
element. As the processing facility 1820 reads the source
information and compares its characteristics with those reflected
by the parameters; upon encountering the text "portfolio manager"
in the source information the processing facility may determine
that the condition set forth by a parameter is satisfied, and
identify the portfolio manager data element within the source
information.
[0107] In some embodiments, a taxonomy may specify that a data
element is accompanied by specific text or the equivalent of that
text in any of several languages. For example, a taxonomy may
specify that a portfolio manager data element is accompanied by the
text "portfolio manager," or the equivalent to "portfolio manager"
in French, Spanish, Russian, Chinese, Japanese or any other
language. Each of these equivalents to "portfolio manager" may
simply be encoded as individual parameters within the taxonomy
itself, or processing facility 1820 may be configured to translate
text into one or more other languages as needed. In this respect,
it should be appreciated that text used to identify a data element
need not be provided in English characters, and may be provided in
Cyrillic, Arabic, Japanese, Chinese or any other suitable
characters.
[0108] As discussed above, a taxonomy need not identify a data
element by specifying text that normally accompanies the data
element. A taxonomy may specify any attribute of a data element,
such as its placement within source information, graphical
treatment, or any other suitable attribute. Further, a taxonomy
need not identify a data element using a single characteristic, as
it may do so using a combination of characteristics, only a subset
of which may need to be satisfied to identify the data element. As
a result, processing facility 1820 may perform one or more logical
operations to evaluate a combination of characteristics to identify
a data element. For example, a taxonomy may specify that two
characteristics must be satisfied for a specific data element to be
identified. As a result, processing facility 1820 may scan the
source information to determine that both characteristics are
satisfied before identifying the data element. In another example,
a taxonomy may specify that two of a group of three
characteristics, must be satisfied, in which case processing
facility 1820 may perform logical operations commensurate with this
identification criteria. Any combination of logical operations,
involving any combination of characteristics, may be performed to
identify a data element, as the invention is not limited in this
respect.
[0109] As discussed above, upon preliminarily identifying a data
element in source information, processing facility 1820 may prompt
a human user to confirm that the data element has been correctly
identified. The process by means of which a human user interacts
with the process to confirm the identification of one or more data
elements is described in further detail below. However, with
respect to the function of a taxonomy, it should be noted that a
response received from a human user as to whether a data element
has been correctly identified may be used to update the taxonomy.
For example; if a taxonomy fails to correctly identify a portfolio
manager data element within source information, perhaps because the
text "portfolio manager" accompanies information other than the
portfolio manager data element, then the user's input indicating
that the portfolio manager data element has not been correctly
identified may be used to update the taxonomy. For example, a GUI
may prompt the user to manually identify the portfolio manager data
element within the source information, and prompt the user to
provide one or more characteristics defining the correct portfolio
manager data element. For example, the GUI may enable the user to
specify that the correct portfolio manager so data element is, in
fact, accompanied by the text "portfolio manager" (e.g., it may be
one of many components of the source information which is
accompanied by that text) but also that the portfolio manager data
element is found at the top of a page within the source
information, is given a specific graphical treatment, or is
identifiable in some other manner. In another example, the GUI may
enable the user to specify that the portfolio manager data element
is not accompanied by the text "portfolio manager," but rather the
text "investment manager." In this manner, interaction with the
user may allow the taxonomy to flexibly adapt over time in
accordance to changes to source information, such as changes to
format and/or content of source information initiated by securities
issuers.
[0110] Even if a taxonomy correctly identifies a data element, a
user's input may be useful for keeping the taxonomy in conformance
with the characteristics of source information. For example, if a
taxonomy specifies that the portfolio manager data element is
normally accompanied by the text "portfolio manager" but fails to
specify that the data element also always appears in a specific
location within the source information, processing facility 1820
may cause the taxonomy to be updated to add the location
characteristic. Further, processing facility 1820 may indicate that
the new characteristic is one which must be satisfied for the data
element to be identified, or may be one of a combination of
characteristics which might be satisfied and which is examined as
part of a logical operation performed by processing facility 1820,
as described above. This manner of updating a taxonomy to more
closely conform to the characteristics of source information may be
performed automatically, or upon receiving confirmation by a user
that the update should occur. For example, processing facility 1820
may simply update the taxonomy over time upon observing
characteristics of the data element as it appears in the source
information, or may cause a user to be prompted (e.g., via a GUI)
as to whether an observed characteristic should be added to a
taxonomy.
[0111] At the completion of act 1720, the process of FIG. 17
completes.
[0112] After individual data items are identified, the identified
data item(s) may be tagged. For example, identified items may be
tagged using eXtensible Markup Language (XML) tags, as is known in
the art. In some embodiments, the elements contained in an XML
tagged document are defined in a Document Type Declaration (DTD). A
validating parser program may, for example, cheek an XML tagged
document for errors.
[0113] An example of a DTD, not intended to limit the present
invention, is shown in FIG. 19. A number of different elements,
some of which include sub-elements, are presented in this example
DTD. A compliance document that has been tagged is presented in
FIG. 20.
[0114] FIG. 21 depicts a MD wherein the element labeled
"performance.annualtotaireturns" may be used to generate a chart
presenting the annual total returns for the fund's past ten years.
For example, the annual return information within the DTD shown in
FIG. 21 may be used to generate a bar chart of the fund's annual
return for the years 1990-1999.
[0115] The processes described in this section may be used to not
only identify and tag individual items of information contained
within a summary prospectus, but also to identify and tag detailed
information which corresponds to these data items contained in
other compliance documents (e.g., a fill statutory prospectus,
statement of additional information (SAI), etc.). Once a logical
association is created between items of information, references
(e.g., hyperlinks) may be created between items in the summary
prospectus and more detailed information contained in an underlying
(in the following description, "source") document or
information.
[0116] In some embodiments, once a data element and its location
within the source information is identified, an indication of the
location (e.g., along with other information) may be stored in
electronic file storage. In the embodiment depicted in FIG. 18, the
indication of the location of the data element is denoted as anchor
1823.
[0117] Anchor 1823 may express the location of a data element
within source information in any of numerous ways. For example, a
location may be expressed as a beginning data character (i.e., in
an alphanumeric or text file containing the source information) for
the data element and a quantity of characters over which the data
element extends. In another example, a location may be expressed as
a section of a page, such as might be provided by an HTML hyperlink
containing a `#` section reference. In yet another example, a
location may be expressed as a collection of pixels in an image
file, such that the collection of pixels defines a portion of the
image. In still another example, an anchor may not specify a
particular location within source information, but may simply
specify the source information in its entirety. Any suitable manner
of expressing a location at which a data element appears within
source information may be employed, as the invention is not limited
in this respect.
[0118] The anchor 1823, as well as a corresponding data element
1821 and a representation of source information 1825, may be stored
in electronic file storage 1830. The representation of source
information 1825 may comprise, for example, source information 1800
in electronic form, as created by receipt facility 1810 (e.g., if
source information 1800 was provided in hard copy form). The
representation of source information 1825 may alternatively
comprise a copy of source information 1800, if it was provided in
electronic form to receipt facility 1810.
[0119] In some embodiments, storing anchor 1823, data element 1821
and source information 1825 in electronic file storage entails
creating a logical association therebetween. A logical association
may be established, for example, using conventional database
technology. For example, if anchor 1823, data element 1821 and
source information 1825 are stored in relational database tables, a
logical association may be established with a foreign key from one
table entry to another, as is well-known in the art. A logical
association may be established in any suitable manner.
[0120] Once the logical association is established, anchor 1823 may
be used to retrieve source information 1825 (or a portion thereof)
at which a data element resides. For example, a user viewing an
online version of a summary prospectus may retrieve, using
corresponding anchor 1823, source information 1825, which may
provide additional detail on an item of information included within
the online version of the summary prospectus.
[0121] One example of a process 2200 for retrieving source
information in this manner is shown in FIG. 22. Upon the start of
process 2200, a command is received to display the data element as
it is presented in source information. This command may be issued
by, for example, a human user via a GUI. The GUI may, for example,
display the data element in a manner which informs the user that
he/she may retrieve and display the data element as it was
presented in source information. This may be done in any of
numerous ways, such as with a graphical emphasis on the data
element (e.g., an underline) as it is presented on the GUI.
[0122] A command may be created and issued in any suitable fashion.
In one example, a command may be issued upon a user's invocation of
a hyperlink associated with the data clement and presented via a
GUI, such as a browser application executing on a device in
communication with the electronic file storage in which the anchor
and/or source information is stored electronic file storage 1830).
Upon invocation of the hyperlink, the browser application may
create and issue a command to the electronic file storage 1830, via
any suitable communication protocol. This description of an
exemplary command should not be construed as limiting, as a command
may be issued, generated or communicated in any suitable manner and
using any suitable mechanism, and may take any suitable form.
Further, the command may be issued to and from any suitable device.
When the command is received by the device, act 2210 completes.
[0123] Then the process proceeds to act 2220, wherein the command
is processed to determine the anchor corresponding to the data
element. In some embodiments, the hyperlink described above may be
encoded to specify the anchor. In other embodiments, the anchor
corresponding to the data element may be determined using a logical
association between the anchor and data element, such as which may
be provided by a database (as described above) or other data
structure. The identification of the anchor corresponding to the
data element may be performed in any suitable fashion, as the
invention is not limited in this respect. Upon the identification
of the anchor corresponding to the data element, act 2220
completes.
[0124] The process then proceeds to act 2230, wherein the anchor is
retrieved. This may be accomplished, for example, by executing an
instruction specifying the anchor to retrieve a record representing
the anchor from electronic file storage. Upon the retrieval of the
anchor, act 2230 completes.
[0125] The process then proceeds to act 2240, wherein the anchor is
employed to retrieve source information, and more specifically the
data element as presented in the source information. In some
embodiments, the record representing the anchor retrieved in the
act 2230 may supply an identifier for another record which contains
or refers to the source information. This other identifier may be
included in an instruction which is executed to retrieve the record
and access the source information. Upon the retrieval of the source
information, act 2240 completes.
[0126] The process then proceeds to act 2250, wherein the source
information, and more specifically the portion of the source
information which includes the data element, is presented. In some
embodiments, the electronic file storage may transmit the source
information to a device which executes a GUI (e.g., the GUI which a
user employed to issue the command received in the act 2210), and
the GUI may present the source information to the user.
Presentation need not occur via a GUI and may occur in any suitable
fashion, as the invention is not limited to any particular
implementation. Upon the completion of the act 2250, process 2200
completes.
[0127] It should be appreciated that the retrieval of source
information in which a data element was originally presented need
not entail retrieving the entire source information in which the
data element resides. That is, a subset of the source information,
such as a particular segment in which the data element appears, may
be retrieved and/or presented. Retrieval of a subset of the source
information may be accomplished in any of numerous ways. For
example, source information may be split into segments before it is
stored. In another example, only the portion of source information
in which the data element resides may be retrieved. Retrieval may
be performed in any suitable fashion as embodiments of the
invention are not limited in this respect.
[0128] It should be appreciated that the preceding section
discloses a capability to analyze one or more underlying documents
(e.g., a statutory prospectus) to identify the location(s) within
the document(s) at which detailed information corresponding to
high-level information provided in a summary prospectus is found.
Once the location(s) are identified, references may be created to
the detailed information. Portions of the information at the
identified location(s) may be used to generate a summary
prospectus, and the references may be inserted into the appropriate
sections of the summary prospectus, to enable investors to navigate
between high-level information in the summary prospectus and detail
contained in the statutory prospectus. Alternatively, if a summary
prospectus is made available by a securities issuer with the
statutory prospectus, references to portions of the statutory
prospectus may be inserted into sections of an online version of
the summary prospectus to enable investors to navigate between the
high-level information in the summary prospectus and the supporting
detail in the statutory prospectus.
V. Making Summary Prospectus Information Available to Investors
[0129] Commonly assigned U.S. patent application Ser. No.
10/916,718, filed in Aug. 12, 2004, entitled "Methods and Apparatus
for Managing Information Related to Securities," the entirety of
which is incorporated herein by reference and relevant portions of
which are reproduced herein, describes system and methods which may
be employed to information available to investors in various forms
(e.g., online, print, etc.). For example, when a securities issuer
makes available a new statutory and/or summary prospectus for a
security (e.g., via submission to EDGAR), some embodiments of the
invention may enable the automatic acquisition and processing of
the document(s) to enable the dissemination, in print and/or online
form, of information contained therein to investors.
[0130] One embodiment of a computer system for making information
available to investors is depicted in FIGS. 23A-23D. The system of
FIGS. 23A-23D may be employed to perform numerous information
management functions.
[0131] At a high level, the system includes various components
(e.g., software modules) configured to make information available
to investors in any of numerous forms. For example, extract module
10 may extract filing data from EDGAR database 2305, and mapping
module 2330 may identify individual compliance documents (e.g., one
or more summary prospectus documents, statutory prospectus
documents, statements of additional information, etc.) within the
filing data, and load these documents to electronic file storage.
Production module 2600 and Deployment module 2390 may generate
versions of one or more compliance documents in different formats,
to serve the needs of different users, and load document versions
to Delivery Servers 2435A and 2435B, which users may access to view
one or more compliance documents. Delivery Servers 2435A-2435B may
afford multiple access methods to compliance documents. For
example, Web delivery module 2800, which may comprise one or more
web servers, may respond to user requests by serving information
stored thereon. FTP server 2900 may respond to file transfer
protocol (FTP) requests to serve documents. Print On Demand (POD)
module 2800 may produce information in print form, customized to
specific investor needs. For example, POD module 2800 may be
configured to send compliance documents relating to individual
investor's holdings.
[0132] More detailed aspects of the system of FIGS. 23A-23D will
now be described with reference to the lifecycle of a securities
filing published by a securities issuer to the EDGAR database 2305
maintained by the SEC. In some embodiments, extract module 2310
issues encoded instructions over a network to perform an extract
from EDGAR database 2305, although an extract may be performed in
any suitable manner, and using any suitable form of system
interface and/or communications infrastructure.
[0133] In some embodiments, extract module 2310 identifies and
extracts various filings submitted to the EDGAR database 2305 by
mutual fund companies, corporations, or other issuers of
securities. For example, securities issuers may submit filings to
EDGAR in formats which include American Standard Code for
Information Interchange (ASCII), hypertext markup language (HTML),
portable document format (PDF), or a combination thereof. Extract
module 2310 may, for example, extract filings as they are submitted
to EDGAR, at some predetermined interval (e.g., daily), or at any
other suitable time. In the example process shown, extract module
2310 transmits ASCII file 2311A, HTML file 2311B, and/or PDF file
2311C to electronic filing warehouse 2315, which may comprise any
suitable combination of software and/or hardware components.
[0134] Filings 2311 stored in electronic filing warehouse 2315 are
then replicated to deployment server 2380, production server 2320
and PDF production server 2485, each of which may comprise any
suitable combination of hardware and/or software components. Each
of servers 2380, 2320 and 2485 execute modules designed to perforin
different functions, as described below.
[0135] As described above, EDGAR filings commonly include
information related to multiple securities, as well as multiple
types of information related to those securities. For example, a
single EDGAR filing may contain a prospectus for Fund A and an
annual report for Fund B, and three prospectus supplements for Fund
C. Thus, an investor seeking information on only Fund A, B, or C
may find the filing unwieldy, confusing, and difficult to
decipher.
[0136] In some embodiments, the techniques described above in
Section I may be employed to separate filings into distinct
components. In the example process shown in FIG. 23, filing data
arrives at production server 2320, and the components of module
2330 identifies one or more distinct filings within the data. In
particular, DAX module 2332, charting module 2335 and XDP module
2340 process filing data when filing data is received from filing
warehouse 2320.
[0137] DAX module 2332 includes programmed routines designed to
interpret data elements provided in an ASCII- or HTML-based EDGAR
filing to identify the filing's distinct components. For example,
DAX module 2332 may identify the portions of a filing relating to
different securities, the issuer of the filing, its effective date,
and any special rules which may apply (e.g., a supplement which may
only be displayed with an accompanying document). Thus, DAX module
2332 identifies the individual "documents" that comprise each
filing, representing information useful to an investor. DAX module
2332 may, for example, separate commingled filing data representing
prospectuses and supplements for eight different funds, and "tag"
documents so that subsequent processes may interpret the identified
documents. In the example process shown, data is tagged using
extensible markup language (XML) tags.
[0138] Charting module 2335 enables, in some embodiments, a
semi-automated process whereby data elements provided in ASCII- and
HTML-based filings may be interpreted to create charts. In this
respect, the SEC prescribes that certain compliance documents must
contain graphical representations of certain types of information
(e.g., charts showing historical performance of the considered
security). As ASCII and HTML data provided in filings submitted to
EDGAR are incapable of expressing information in graphical form,
charting module 2335 processes the ASCII and/or HTML data to create
the prescribed charts. In some embodiments, charting module 2335
may pre-identify data elements in a ASCII or HTML filing likely to
be used for creating a chart, prompt a human user to confirm that
the pre-identified elements are to be used for chart creation, and
if so, create XML tags and instructions which may be used by
subsequent processes to create one or more charts in graphical form
for the eventual document.
[0139] XDP module 2340 enables the processing described above in
Section H whereby a set of predefined data elements are located
within each filing and tagged (e.g., using XML tags). As described
above, any of numerous data elements may be identified and tagged,
such as data elements which may be useful to investors in comparing
one security to another. In some embodiments, XDP module 2340
employs various keywords and defined business rules to
preliminarily identify individual data elements, prompt a human
user to confirm whether each data element has been correctly
identified, and if so, creates a tag for each data element so that
subsequent processes may quickly identify their location within a
document.
[0140] In the example shown in FIGS. 23A-23D, DAX module 2332,
charting module 2335 and XDP module 2340 produce document metadata
2345, chart XML data 2350 and data point XML data 2355,
respectively, and transmits this information to production data
2360 and PDF production server 2485. This output may, for example,
comprise XML tags, instructions and other information which may be
employed by subsequent processes to separate a filing into document
components. By passing instructions, tags and other data, rather
than identified documents themselves, the system may conserve
network bandwidth and decrease the time required to transmit
information.
[0141] In the example depicted, PDF Production. Server 2485 also
receives filing data from filing warehouse 2315. In some
embodiments, PDF Production Server 2485 may enable a process
whereby filing data received from filing warehouse 2315 is
converted to typeset (i.e., non-editable) form, so that the
information may be transmitted or otherwise made available to
investors in that form. For example, in one embodiment, filing,
data may be converted to a Portable Document Format (PDF) document,
which may be transmitted or made available to investors via a web
site.
[0142] In the example shown, the process of converting filing data
to typeset form is performed by PDF Production Server 2485.
Specifically, in this example, PDF Production Server 2485 produces
a preliminary, preformatted version of a data structure
representing filing data, which is then transmitted to a user's
workstation (e.g., analyst 2515) for editing. The user may provide
various instructions via a GUI executing on the workstation to
invoke functionality provided by PDF Production Server 2485, so
that a typeset document 2465 may be created. The typeset document
is then transmitted to production data 2360.
[0143] In the example shown, the information stored at production
data 2360 (i.e., to document metadata 2345, chart XML data 2350,
data points XML data 2355, and PostScript file 2565) is sent, with
document data 2370, to deployment server 2380. As a result, at this
point in the process, deployment server 2380 stores filing data
2311 and the information required to separate the filings into
documents. This data is represented collectively as data 2385.
[0144] Extract module 2420 receives filing data 2311, as well as
information provided in document metadata 2345, to extract one or
more compliance documents from filing 2311. For example, extract
module 2420 may process instructions provided by document metadata
2345 to determine the start and end of each document included
within filing 2311. In some embodiments, extract module 2420
produces output in the form of an "un-styled" HTML document.
[0145] Module 2405 then adds a chart (and/or hyperlink to a chart)
to applicable documents. In some embodiments, module 2405 processes
information provided by chart XML data 2350 to construct a file
containing a graphical representation(e.g. chart) of information,
and may insert a hyperlink into the HTML document produced by
routine 2420 which references the file. The file may be created in
any suitable graphical file format, including jpg, .gif, or other
file formats.
[0146] In the example shown. HTML documents are then deployed to
delivery servers 2435A-2435B. In some embodiments, delivery servers
2435A-2435B are equipped to receive and transmit network-based
(e.g., web-based) communication. In the embodiment shown, all of
the HTML documents created are transferred to delivery servers
2435A-2435B, and deleted from deployment server 2390 (of course,
they may be recreated from the raw filing data and instructions
produced in routine 2330).
[0147] It should be appreciated that another drawback with
information on the EDGAR database (i.e., in addition to the
unwieldy nature of the filings discussed above) is that there is no
quick, reliable or easy way to determine the most current version
of filings for a particular security. For example, it is not
uncommon for a mutual fund company to file more than one prospectus
for each of its thuds on EDGAR. Each prospectus may be the subject
of a replacement (whereby the issuer files a newer version of a
prospectus to take the place of one already on file, but does not
remove the older version), a revision (whereby the issuer files a
newer version which modifies a prospectus already on file, but does
not remove the older version), and/or one or more supplements or
"stickers" (whereby the issuer indicates that a portion of the
version on file should be replaced or supplemented with new
information, but does not remove the older version). As a result,
it can be extremely difficult for an investor to determine which
version of an EDGAR is filing for a security is the most
current.
[0148] The system of FIGS. 23A-23D provides a capability to
identify, and direct an investor to, the most current versions of
compliance documents for a security, accounting for such filings as
revisions, replacements and supplements. In the example shown,
deployment module 2390, using update index module 2415, creates and
maintains a "compliance envelope" in which is stored the location
of the most current compliance document(s) for each security on
file. For example, a compliance envelope for a given security may
include the location of a most current prospectus, annual report,
semi-annual report, statement of additional information, and/or all
supplements for the security that satisfy certain requirements.
[0149] To create the compliance envelope, update index module 2415
determines whether a document contained within a given filing
represents the most current information for the security, and thus
warrants an update to the compliance folder. For example, update
index 2415 may process data in the filing to determine whether a
document should be designated as most current. In this respect, a
document may contain information, such as an effective date, which
defines when it should be made available to investors (documents
are often filed in advance of their effective date, so may have to
suspend their delivery for a time, then indicate when the effective
date arrives that the document is most current). The effective date
may also be used to determine when the document should be
designated as the most current document, as well as how long it
will remain effective. Thus, in some embodiments, although every
document is deployed to delivery servers 2435A-2435B, the update
index module 2415 uses the effective date to determine whether a
particular document is most current, and if so updates the location
for the considered type of document within the compliance envelope
to reflect this. For example, update index module 2415 may process
a number of rules to determine whether a particular document is the
most current of certain types (e.g., prospectus, annual report, and
semiannual report documents). In addition, rules may be processed
to determine whether to make available a compliance envelope entry
for a security. Example rules for determining whether a document is
the most current of its type and/or whether an entry for a
compliance envelope should be made available to investors are
provided in above-referenced co-pending U.S. application bearing
Ser. No. 10/916,781.
[0150] If update index module 2415 determines that a particular
document is the most current of its type, it modifies the
compliance folder to include the location of that document on
servers 2435A-2435B, so that the most current of each type of
compliance document may be easily accessed by investors. Thus, for
example, when an investor issues a web-based request for a
prospectus for Fund X, one of servers 2435A-2435B may access the
compliance envelope to determine the location of the most current
prospectus (as well as any additional information germane to the
request and/or document, such as applicable supplements), and serve
that data to the investor. In the embodiment shown, the compliance
envelope is implemented using a table which reflects the location
(i.e., within one or more file systems stored on delivery servers
2435A-2435B) of the most current document of each type for a
particular security. However, a compliance envelope need not be
implemented using a table, and may be implemented in any of
numerous ways, such as with any form of data structure. The system
is not limited to any particular implementation.
[0151] In some embodiments, using a compliance envelope to process
investor requests for documents relating to a security may minimize
the processing which a delivery server performs. For example,
having an identified location of the most current compliance
document of each type may mean that a delivery server need not
perform logical processing (e.g., to compare characteristics of
various compliance documents stored thereon) to determine the most
current, but rather can simply retrieve the document from the
identified location. In this manner, the response time of delivery
servers 2535 may be minimized.
[0152] As described above, delivery servers 2435A-2435B may provide
several vehicles through which an investor may access information
stored thereon. Three of these vehicles (i.e.; web delivery, FTP,
and POD) are depicted in FIG. 23, although an suitable vehicle(s)
may be employed.
[0153] In some embodiments, a web delivery vehicle may allow an
investor 2447 to access information stored on delivery servers
2435A-2435B via the worldwide web. For is example, investor 2447
may use a web browser to access a web site hosted by or for
investment institution 2450 or online broker 2420 (i.e., exemplary
entities that an investor uses to access information related to
securities) on one of delivery servers 2435A-2435B. When an
investor issues a request 2525 for information to the web site
validation module 2530 may authenticate the investor and determine
the security for which the investor seeks information (e.g., based
on a provided CUSIP).
[0154] In some embodiments, the format in which the information
should be provided as HTML, XML, PDF, etc.) is also determined. In
the example shown, an indication of the format is provided within
the URL used to issue the request, although this indication may be
provided using any suitable mechanism(s). Validation module 2530
may process the request to determine whether the entity for which
the site is hosted is approved to provide information for the
considered security in the format requested.
[0155] In the example shown, if the request is validated, then
module 2535 retrieves the requested information for the considered
security and provides it to investor 2447 (e.g., as either HTML/XML
document 2540 for "Level I/II" or PDF document 2545 for "Level
III"). The retrieval process may include using the compliance
envelope to determine the location of the document requested in the
specified format.
[0156] In some embodiments, information may nor be sent to an
investor 2447 in response to the investor's request, but rather in
response to a document having been published to EDGAR. For example,
an investor may have given prior consent to electronic delivery of
updates to certain types of documents for a particular security.
Thus, when an updated document is identified, the system may cause
the document (e.g., in PDF form) or a message indicating that a
document and the location at which it is available, to be sent to
the investor. Commonly assigned U.S. patent applications to bearing
Ser. Nos. 09/023,039 (entitled "Obtaining Consent for Electronic
Delivery of Compliance Information") and 09/785,630 (entitled
"Method and Apparatus for Providing Financial Transaction Data Via
The Internet") disclose example techniques for obtaining investor
consent to electronic delivery of information and for providing
data related to securities transactions, respectively, which may
also be employed to deliver compliance documents, such as a summary
prospectus, to art investor.
[0157] Of course, compliance documents such as a statutory and/or
summary prospectus need not be sent to investors electronically, as
they may also, or alternatively, be provided in hard copy form. The
embodiments of the invention which provide a capability for a
statutory and/or summary prospectus to be sent to an investor in
hard copy form may also provide functionality for suppressing
delivery to certain investors. In this respect, it should be
appreciated that although the SEC generally requires that a
prospectus for a security be delivered to an investor within a
specified timeframe after certain events occur (e.g., after the
investor purchases the security), there are exceptions to this
general rule. For example, a prospectus need not be sent to an
investor who previously received that prospectus, or who is
purchasing additional shares of the security (i.e., rather than
making an initial purchase). As such, embodiments of the present
invention provide a capability for determining, using data on
investor holdings, previous investor mailings, and filings acquired
from EDGAR to determine the investors to whom a newly published
statutory and/or summary prospectus should be sent. In particular,
some embodiments provide a capability for producing a "print
recipe" identifying investors to whom a summary prospectus should
be sent.
[0158] FIG. 24 depicts an example process 2700 for identifying
investors to which one or more documents (e.g., published statutory
and/or summary prospectuses) should be sent. At the start of
process 2700, a data structure containing information relating to
previous activity for an entity's (e.g., an issuer's,
intermediary's, etc) clients (e.g., investors) is retrieved in act
2710. This information may, for example, data on each investor's
investment positions, and mailings previously sent to each client
This file may be retrieved from electronic file storage (e.g., a
database maintained for the customer) which stores information
related to the entity and its clients.
[0159] Upon the completion of the act 2710, the process proceeds to
at 2720, wherein the holdings for each investor account which
qualify for the mailing are determined. One embodiment of a method
for determining client account holdings which qualify is depicted
in FIG. 25, which utilizes the data structure retrieved in act
2710. The method described with reference to FIG. 25 may also be
embodied in one or more software routines programmed in any
suitable programming language, and may be executed on any suitably
configured computer system. FIG. 25 depicts a simplified version of
this process; possible variations are described below.
[0160] In FIG. 25, historical holdings data 2810 and new holdings
data 2820 are compared in act 2830 to determine client holdings
changes 2840. Then, client holdings changes 2840 and EDGAR filings
data 2850 are compared in act 2860 to determine holdings which have
currently effective filings 2870. Then, the holdings with currently
effective filings 2870 and historical mailing data 2880 are
compared in act 2890 to determine the client account holdings to be
included in the mailing 2895.
[0161] There are numerous variations to the process of FIG. 25
which may be achieved by applying various business rules to the
process. Business rules may be provided in the form of a data
structure that is accessed during the execution of the process
shown, may be "hard coded" into one or more programmed routines
which comprise, either completely or in part, the process of FIG.
25, or provided in any other suitable manner. Business rules may be
provided which dictate that: [0162] If a client does not own a
certain security, documents related to that security should not be
mailed to the client. [0163] If a client has previously received a
document, the document should not be mailed to the client. [0164]
if a client purchases a security in the current period and has not
previously received a document with a current effective date for
that security, the document should be mailed to the client. [0165]
If a client has previously received a document with a current
effective date for a security, but has not received a supplement
which has a current effective date, the supplement should be mailed
to the client. [0166] If a client has previously received a
document which contains information related to a security that the
client purchased in the current period (e.g., if the document
previously received also contained information for another security
purchased by the client), the document should not be mailed to the
client. [0167] If a client previously received a document for a
security, then sold the security, then re-purchased the security
before the document's effective date had lapsed, the document
should not be mailed to the client. [0168] If a client account was
previously inactive because the client had stopped making
contributions, and the account became active in the current period,
a prospectus should only be sent for the securities in the account
if the effective date of the previously received prospectuses are
past. [0169] If a client is a new participant in a plan but has not
yet purchased a security under that plan, a prospectus for all
securities offered under the plan should be mailed to the client.
[0170] If a customer offers a new security under an existing
product (e.g., a variable annuity), send a prospectus to each
client who owns that product for that security.
[0171] Alternatively, client accounts may be selected for inclusion
in a mailing according to criteria which are unrelated to their
holdings or mailing history. For example, clients may be selected
that participate in a certain type of plan (e.g., a 401(k) plan),
own a certain type of product (e.g., a variable annuity), or own a
certain security (e.g., IBM stock) may be selected for a mailing.
In this manner, a customer may execute promotions related to
certain products, plans, or securities. The selection of client
accounts for a mailing may be performed in any suitable manner.
[0172] Referring again to FIG. 24, upon the completion of act 2720,
the process proceeds to act 2730, wherein unique accounts and
documents to be included in the mailing are determined. One method
for determining unique accounts is to consolidate multiple records
which share a common identifier (e.g., account number). However,
any suitable technique for identifying unique accounts may be
employed.
[0173] The determination of the documents to be included in a
mailing may include multiple steps. First, business rules may guide
whether document supplements are to be mailed. For example, the
rules may dictate that if a client mailing includes only a
supplement, the supplement should not be mailed, because the
expense is unjustified. On the other hand, rules may dictate that a
supplement is sent regardless of whether it constitutes the sole
mailing for that client. Second, the process may identify whether a
client holds multiple securities described in a combined document
(i.e. documents containing information related to more than one
security) and include that document in the mailing only once. There
are numerous ways to identify the documents to be included in a
mailing, and the process is not limited to a particular
implementation.
[0174] Upon the completion of act 2730, the process proceeds to act
2740, wherein a determination is made as to whether any clients
have consented to electronic delivery. This determination may be
made by comparing the client accounts to a data structure
containing client accounts which have consented to electronic
delivery. The records for clients who have not consented are passed
to the act 2770, while the records for clients who have consented
are passed to the act 2750. In the embodiment shown, act 2770 is
not performed until the completion of acts 7750 and 2760.
[0175] In act 2750, electronic delivery is attempted for those
clients which have consented. As described above, electronic
delivery may include a message sent to a client's e-mail address or
a text message sent to the client's wireless device (e.g., cell
phone or PDA) indicating that the document is available for
retrieval from a web site identified (e.g., with a URL) in the
message, or other form of notification.
[0176] Upon the completion of the act 2750, the process proceeds to
act 2760, wherein it is determined whether each attempt at
electronic delivery was successful. This may be performed by
determining whether a message was returned. If it is determined in
act 2760 that electronic delivery was successful for a particular
client record, the process ends for that client record. If it is
determined in act 2760 that electronic delivery was unsuccessful
for a client record, the record is passed to the act 2770, to be
processed with those client records that did not consent to
electronic delivery. In addition, the record may have an indicator
set which triggers the creation of a message (e.g., a mail-gram or
other notice) which notifies the client that electronic delivery
failed.
[0177] In act 2770, the unique recipients and print package for
each client mailing are determined. In one embodiment, the unique
recipients for a mailing are determined by executing a house
holding process. In some implementations, a householding process
seeks to identify multiple client records which belong to a single
household, so that only a single mailing may be sent to that
household. The process may be configured to identify records with a
common household in any of numerous ways, such as according to
regulations issued by the SEC, or according to business rules
supplied by a customer. For example, the process may be configured
to determine that client records having equivalent last name and
address fields should be assigned to the same household. In
addition, the process may also determine the unique funds held by
household members. For example, if two members of the same
household own the same security and were to receive the same
document for that security, the process may eliminate one of the
duplicate documents from the mailing.
[0178] The print package to be delivered to each recipient may be
configured in any of numerous ways, such as with business rules
provided by the customer. For example, the customer may specify
that documents sent to participants in particular plans, clients
who own specific products or securities, or clients in specific
geographic regions should be given customized covers, such as
covers which specify a product name, logo, return address, or other
information. The customer may also specify that documents sent to
particular clients should be given customized cover letters, such
as letters which specify; a plan name, fund name, or client e-mail
address.
[0179] Upon the completion of act 2770, the process proceeds to act
2780, wherein the print recipe is created and the documents which
are include in the print recipe are retrieved. According to one
embodiment, the recipe includes a collection of records, each of
which includes information describing a unique client, indications
of the documents that are to be sent to the client, and other
indicators for how the mailing is to be customized.
[0180] An exemplary print recipe record is depicted in FIG. 26.
Record 2601 includes portion 2610, in which name and address
information for a client is stored. This information may be the
result of the house holding process described above. Portion 2620
stores indicators which are interpreted by a print vendor to
customize the mailing to the client. For example, portion 2620 may
contain an indicator for the name of the plan in which the client
is a participant, so that the plan name may be printed on the cover
of the mailing sent to the client. Portions 2630, 2640, 2650 and
2660 store indications of the documents to be included in the
mailing to the client.
[0181] Referring again to FIG. 24, in act 2770, the process
retrieves the documents which are specified by the print recipe.
This may be accomplished in any of numerous ways, such as by
retrieving PDF documents from delivery servers 2435A-2435B (FIG.
23), or by requesting PDF documents from the customer.
[0182] The act 2780 may include splitting the print recipe file
into multiple files. This may be done for any of numerous reasons.
For example, a customer may have requested that its own PDF files
be used instead of those created in the PDF production process
shown in FIG. 23 (e.g., because the customer PDF files are smaller
and more decoratively styled than those created by the process of
FIG. 23), but may have sent only a portion of the PDF files which
are specified in the print recipe. In this case, act 2780 may
include splitting the print recipe file into a first portion
containing only the PDF documents received, and a second portion
which contains PDF documents not yet received. In another example,
the print recipe may be split into multiple files to accommodate
economic considerations. For instance, the print recipe may be
split into a first portion which will be offset printed, and a
second portion which will be digitally printed. In yet another
example, the documents for a particular security, plan or product
may need to be printed before others for various reasons, such as
to meet compliance requirements set by the SEC.
[0183] Upon the completion of act 2780, the process proceeds to act
2790, wherein the print recipe and the specified documents are used
to prepare a set of documents for delivery to investors. Upon the
completion of act 2790, the process 2700 ends.
[0184] The techniques for processing securities-related information
described above may be performed at a configurable periodicity. For
example, in some embodiments, information contained in a summary
prospectus and/or corresponding detailed documents may be processed
throughout the year (e.g., the calendar year and/or a securities
issuer's or intermediary's fiscal year) so that as new detailed
documents are made available, an online version summary prospectus
may provide access to this updated information, either in addition
to or instead of information previously made available by a
securities issuer or intermediary. For example, an exhaustive
repository of information relating to a security (e.g., multiple
online version summary prospectuses, which may have issued
periodically and include information that has changed over time,
with the detailed documents corresponding to each online version)
may be provided, or only the most current version of information
relating to a security (e.g., a single, most current online version
summary prospectus and the current documents it references) may be
made available, or some combination of these approaches may be
employed (e.g., by providing access to a single, most current
online version summary prospectus, and a repository of detailed
documents that include information that has changed over time, vice
versa, etc.). The invention is not limited to any particular
implementation.
[0185] Some embodiments may make provisions for compliance with
periodic update requirements set forth by the SEC and/or other
regulatory agencies. For example, if the SEC issued a new
requirement that securities issuers and/or intermediaries must make
available updates to a security's statutory and/or summary
prospectus, or portions thereof, more frequently than annually
(e.g., quarterly), then embodiments of the invention may be
configured to enable creation of a new online version summary
prospectus and/or updates to an existing online version summary
prospectus with updated information (e.g., updates to a mutual
fund's top holdings) at the required frequency. If an existing
online version summary prospectus is updated to include new or
revised information, this information may be acquired from any of
numerous sources. For example, information may be acquired (e.g.,
using the techniques described above in Sections I-III) from a new
statutory prospectus or other document published by the securities
issuer and/or intermediary (e.g., a new summary prospectus,
supplement, SAI and/or other document(s)) and/or other information.
Embodiments of the invention are not limited to any particular
implementation.
[0186] If updates to information on a security occur more
frequently than annually, and a new online version summary
prospectus is created, then embodiments of the invention may
provide a set of investor information resources which includes one
or more previous online version summary prospectuses, each
including links to corresponding detailed documents. For example, a
reference between each online version summary prospectus and the
detailed documents it references may be kept static over time, even
as new summary prospectus and/or detailed documents are published
by a securities issuer and/or intermediary. As such, embodiments of
the invention may enable an investor to review previous online
version summary prospectuses and the detailed documents referenced
thereby to determine how certain key information relating to a
security has changed over time, or to review information on a
security as of a certain date, enabling a more thorough analysis of
a security's history along dimensions which are important to the
investor. For example, the investor might gain insight into how a
mutual fund's top holdings changed over time (perhaps giving some
indication of how volatile are the fund's holdings), whether there
have been any increases in certain fees over time (perhaps giving
some indication of whether and when further fee increases might be
expected), etc.
[0187] Of course, the invention is not limited to being implemented
with static links from a given online version summary prospectus to
underlying detailed documents, as relationships between online
version summary prospectuses and underlying documents so need not
be one-to-one, and may change over time. For example, when a new
online version summary prospectus with links to updated detailed
documents is created, previous online versions may be retained, but
the links to detailed documents in those previous online versions
may be updated to reference the most recent versions of those
detailed documents, may be supplemented with links to the most
recent versions of those detailed documents, or may be otherwise
modified. In this manner, an investor who accesses an online
version summary prospectus which is not the most up-to-date (e.g.,
an investor who enters an outdated URL provided on a previous hard
copy summary prospectus mailed to the investor some time ago) may
be alerted that more current information is available, while still
enabling the investor to see how information on the security has
changed over time.
[0188] Some embodiments of the invention may enable making multiple
versions of a particular summary prospectus available to investors
in hard copy and/or online form. This may be desirable, for
example, because some investors in a given security may have who
purchased it directly from the issuer, while others may have
purchased the security through an intermediary (e.g., a
broker-dealer), and each entity which sells the security to
investors may wish to have the summary prospectus branded a
particular way to engender investor loyalty and brand awareness.
For example, each entity that sells the security to investors may
employ different branding elements (e.g., logos, text fonts,
formatting styles, etc.) in generating a hard copy summary
prospectus for delivery to investors. These branding elements may,
for example, be overlaid or otherwise added to preliminary version
of the summary prospectus made available by the security issuer
(e.g., via the EDGAR database). As a result, a first group of
investors who purchase the security directly from the issuer may
receive one version of a hard copy and/or online version summary
prospectus which contains branding elements specific to the issuer,
while a second group of investors who purchased the security
through an intermediary (e.g., a broker/dealer) may receive a
version of the hard copy and/or online version summary prospectus
which is specific to the intermediary from which the security was
purchased and which contains branding elements specific to the
considered intermediary. As a result, each entity may market its
services to the investors to whom it delivers the hard copy and/or
online version summary prospectus.
[0189] Some embodiments may provide for creating different versions
of a hard copy summary prospectus, each including a different URL
for a different online version summary prospectus, to accomplish a
similar objective. For example, one version of a hard copy summary
prospectus may be created for investors that purchased the security
through the issuer, with that version including a URL for an online
version summary prospectus hosted on the issuer's web site, and one
or more other versions may be created for investors that purchased
the security through an intermediary, with each version including a
URL for an online version summary prospectus hosted on a respective
intermediary's website. As such, each intermediary may have an
opportunity to markets its services to investors via its online
version summary prospectus version.
[0190] Versions of a hard copy and/or online version summary
prospectus may be created in any of numerous ways, as embodiments
of the invention are not limited to any particular technique. For
example, the processes described above in Section I may be employed
by an intermediary and/or service provider engaged thereby to
identify when a summary prospectus is published for a security held
by a customer of the intermediary (i.e., an investor). When a
summary prospectus is published, the techniques, described in
Section II-III may be employed to create a hard copy summary
prospectus for delivery to the investor which includes branding
elements specific to the intermediary, and a URL for an online
version summary prospectus which is hosted on the intermediary's
website (or a website created by the service provider for the
intermediary). Similarly, a securities issuer and/or service
provider engaged thereby may employ the techniques described above
when publishing a summary prospectus for a security held by
customers to create a hard copy summary prospectus for delivery to
each customer which includes branding elements specific to the
issuer and a URL for an online version summary prospectus which is
hosted on the issuer's website (or a website created by the service
provider for the issuer). Embodiments of the invention may be
employed to create different versions of a hard copy and/or online
version summary prospectus to accomplish various business
objectives in any of numerous ways, as the invention is not limited
to any particular implementation.
[0191] Various aspects of the systems and methods for practicing
features of the invention may be implemented on one or more
computer systems, such as the exemplary computer system 2800 shown
in FIG. 27. Computer system 2800 includes input device(s) 2802,
output device(s) 2801, processor 2803, memory system 2804 and
storage 2806, all of which are coupled, directly or indirectly, via
interconnection mechanism 2805, which may comprise one or more
buses, switches, networks and/or any other suitable
interconnection. The input device(s) 2802 receive(s) input from a
user or machine (e.g., a human operator), and the output device(s)
2801 display(s) or transmit(s) information to a user or machine
(e.g., a liquid crystal display). The processor 2803 typically
executes a computer program called an operating system (e.g., a
Microsoft Windows-family operating system, or any other suitable
operating system) which controls the execution of other computer
programs, and provides scheduling, input/output and other device
control, accounting, compilation, storage assignment, data
management, memory management, communication and dataflow control.
Collectively, the processor and operating system define the
computer platform for which application programs and other computer
program languages are written.
[0192] The processor 2803 may also execute one or more computer
programs to implement various functions. These computer programs
may be written in any type of computer program language, including
a procedural programming language, object-oriented programming
language, macro language, or combination thereof. These computer
programs may be stored in storage system 2806. Storage system 2806
may hold information on a volatile or non-volatile medium, and may
be fixed or removable. Storage system 2806 is shown in greater
detail in FIG. 28.
[0193] Storage system 2806 typically includes a computer-readable
and writable nonvolatile recording medium 2901, on which signals
are stored that define a computer program or information to be used
by the program. A medium may, for example, be a disk or flash
memory. Typically, an operation, the processor 2803 causes data to
be read from the nonvolatile recording medium 2901 into a volatile
memory 2902 (e.g., a random access memory, or RAM) that allows thr
faster access to the information by the processor 2803 than does
the medium 2901. The memory 2902 may be located in the storage
system 2806, as shown in FIG. 29, or in memory system 2804, as
shown in FIG. 28. The processor 2.803 generally manipulates the
data within the integrated circuit memory 2804, 2902 and then
copies the data to the medium 2901 after processing is completed. A
variety of mechanisms are known for managing data movement between
the medium 2901 and the integrated circuit memory element 2804,
2902, and the invention is not limited thereto. The invention is
also not limited to a particular memory system 2804 or storage
system 2806.
[0194] The above-described embodiments of the present invention can
be implemented in any of numerous ways. For example, the
above-discussed functionality can be implemented using hardware,
software or a combination thereof. When implemented in software,
the software code can be executed on any suitable processor or
collection of processors, whether provided in a single computer or
distributed among multiple computers. In this respect, it should be
appreciated that any component or collection of components that
perform the functions described herein can be generically
considered as one or more controllers that control the
above-discussed functions. The one or more controllers can be
implemented in numerous ways, such as with dedicated hardware, or
by employing one or more processors that are programmed using
microcode or software to perform the functions recited above. Where
a controller stores or provides data for system operation, such
data may be stored in a central repository, in a plurality of
repositories, or a combination thereof.
[0195] Further, it should be appreciated that a (client or server)
computer may be embodied in any of a number of forms, such as a
rack-mounted computer, desktop computer; laptop computer, tablet
computer, or other type of computer. Additionally, a (client or
server) computer may be embedded in a device not generally regarded
as a computer but with suitable processing capabilities, including
a Personal Digital Assistant (PDA), a smart phone or any other
suitable portable or fixed electronic device.
[0196] Also, a (client or server) computer may have one or more
input and output devices. These devices can be used, among other
things, to present a user interface. Examples of output devices
that can be used to provide a user interface include printers or
display screens for visual presentation of output and speakers or
other sound generating devices for audible presentation of output.
Examples of input devices that can be used for a user interface
including keyboards, and pointing devices, such as mice, touch
pads, and digitizing tables. As another example, a computer may
receive input information through speech recognition or in other
audible format.
[0197] Such computers may be interconnected by one or more networks
in any suitable form, including as a local area network or a wide
area network, such as an enterprise network or the Internet. Such
networks may be based on any suitable technology and may operate
according to any suitable protocol and may include wireless
networks, wired networks or fiber optic networks. Also, the various
methods or processes outlined herein may be coded as software that
is executable on one or more processors that employ any one of a
variety of operating systems or platforms.
[0198] Additionally, software may be written using any of a number
of suitable programming languages and/or conventional programming
or scripting tools, and also may be compiled as executable machine
language code or intermediate code that is executed on a framework
or virtual machine.
[0199] In this respect, the invention may be embodied as a storage
medium (or multiple storage media) (e.g., a computer memory, one or
more floppy disks, compact disks, optical disks, magnetic tapes,
flash memories, circuit configurations in Field Programmable (late
Arrays or other semiconductor devices, or other computer storage
media) encoded with one or more programs that, when executed on one
or more computers or other processors, perform methods that
implement the various embodiments of the invention discussed above.
The storage medium or media can be transportable, such that the
program or programs stored thereon can be loaded onto one or more
different computers or other processors to implement various
aspects of the present invention as discussed above.
[0200] The terms "program" or "software" are used herein in a
generic sense to refer to any type of computer code or set of
computer-executable instructions that can be employed to program a
computer or other processor to implement various aspects of the
present invention as discussed above. Additionally, it should be
appreciated that according to one aspect of this embodiment, one or
more computer programs that when executed perform methods of the
present invention need not reside on a single computer or
processor, but may be distributed in a modular fashion amongst a
number of different computers or processors to implement various
aspects of the present invention.
[0201] Computer-executable instructions may be provided in many
forms, such as program modules; executed by one or more computers
or other devices. Generally, program modules include routines,
programs, objects, components, data structures, etc. that perform
particular tasks or implement particular abstract data types.
Typically the functionality of the program modules may be combined
or distributed as desired in various embodiments.
[0202] Various aspects of the present invention may be used alone,
in combination, or in a variety of arrangements not specifically
discussed in the embodiments described in the foregoing and is
therefore not limited in its application to the details and
arrangement of components set forth in the foregoing description or
illustrated in the drawings. For example, aspects described in one
embodiment may be combined in any manner with aspects described in
other embodiments.
[0203] Use of ordinal terms such as "first," "second," "third,"
etc., in the claims to modify a claim element does not by itself
connote any priority, precedence, or order of one claim element
over another or the temporal order in which acts of a method are
performed, but are used merely as labels to distinguish one claim
element having a certain name from another element having a same
name (but for use of the ordinal term) to distinguish the claim
elements.
[0204] Also, the phraseology and terminology used herein is for the
purpose of description and should not be regarded as limiting. The
use of "including," "comprising," or "having," "containing,"
"involving," and variations thereof herein, is meant to encompass
the items listed thereafter and equivalents thereof as well as
additional items.
[0205] Having thus described several aspects of at least one
embodiment of this invention, it is to be appreciated various
alterations, modifications, and improvements will readily occur to
those skilled in the art. Such alterations, modifications, and
improvements are intended to be part of this disclosure, and are
intended to be within the spirit and scope of the invention.
Accordingly, the foregoing description and drawings are by way of
example only.
* * * * *
References