U.S. patent application number 09/823431 was filed with the patent office on 2002-02-14 for address presentation system.
Invention is credited to Bain, Sabyasachi, Bernard, Warren E., Brannen, Patrick E., Clay, Thomas J.B., Friedman, Michael B., Hajdo, Lisa F., McCarty, John M., Nettimi, Vidyadhar, Sangineni, Malathi.
Application Number | 20020019699 09/823431 |
Document ID | / |
Family ID | 22712788 |
Filed Date | 2002-02-14 |
United States Patent
Application |
20020019699 |
Kind Code |
A1 |
McCarty, John M. ; et
al. |
February 14, 2002 |
Address presentation system
Abstract
An approach for providing retrieval of information via a
geographic information system that uses a robust, standardized
architecture. A user utilizing a client station is able to obtain,
for example, telecommunication information by supplying input
address information and optionally, user supplied selection
criteria. An application server receives the input address
information. A database server communicates with the application
server; the database server is configured to validate and geocode
the input address information. The database server outputs
validated address information and positional information to the
application server. The database server is coupled to numerous data
sources. The database server retrieves the telecommunication
information based upon the selection criteria and transmits the
telecommunication information to the application server, which can
generate a map graphic based upon the validated address and the
positional information from the database server. The application
server permits overlay of the telecommunication information onto
the map graphic.
Inventors: |
McCarty, John M.; (Clifton,
VA) ; Friedman, Michael B.; (Reston, VA) ;
Clay, Thomas J.B.; (Fredrick, MD) ; Nettimi,
Vidyadhar; (Oakton, VA) ; Bain, Sabyasachi;
(Herndon, VA) ; Sangineni, Malathi; (Reston,
VA) ; Hajdo, Lisa F.; (Sterling, VA) ;
Brannen, Patrick E.; (State College, PA) ; Bernard,
Warren E.; (Bethesda, MD) |
Correspondence
Address: |
WORLDCOM, INC.
TECHNOLOGY LAW DEPARTMENT
1133 19TH STREET NW
WASHINGTON
DC
20036
US
|
Family ID: |
22712788 |
Appl. No.: |
09/823431 |
Filed: |
March 30, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60193241 |
Mar 30, 2000 |
|
|
|
Current U.S.
Class: |
701/431 ;
707/E17.018; 709/201 |
Current CPC
Class: |
G06F 16/29 20190101;
G09B 29/007 20130101 |
Class at
Publication: |
701/211 ;
701/208; 701/213; 709/201 |
International
Class: |
G06F 015/16; G01C
021/34 |
Claims
What is claimed is:
1. A method of utilizing a geographical information system, the
method comprising: receiving input address information; geocoding
the input address information; and outputting positional
information in response to the geocoding step.
2. The method according to claim 1, further comprising retrieving
requested information based upon the positional information.
3. The method according to claim 2, further comprising receiving
selection criteria corresponding to the requested information,
wherein the retrieving step is further based upon the selection
criteria.
4. The method according to claim 2, further comprising: validating
the input address information; and selectively outputting validated
address information based upon the validating step.
5. The method according to claim 2, wherein the geocoding step
comprises determining the positional information at a rooftop level
in response to the validating step.
6. The method according to claim 5, wherein the geocoding step
further comprises: determining the positional information at a
ZIP-9 level in response to invalid rooftop level validation; and
alternatively determining the positional information at a ZIP-5
level in response to invalid ZIP-9 level validation.
7. The method according to claim 2, further comprising: selectively
generating a map graphic based upon the positional information; and
transmitting the map graphic and the requested information to a
client station based upon the selectively generating step.
8. The method according to claim 7, wherein the selectively
generating step comprises: interfacing a map database to retrieve
mapping data corresponding to the positional information; and
rendering the map graphic based upon the mapping data.
9. The method according to claim 2, further comprising interfacing
with an applications client via a CORBA (Common Object Request
Broker Architecture) object request broker (ORB).
10. The method according to claim 2, wherein the requested
information comprises at least one of wire center data, rate center
data, PSAP (Public Safety Answering Point) data, CAP (Competitive
Access Provider) data, switch collolocation data, and switch
location data.
11. The method according to claim 2, further comprising: displaying
the requested information on a client station.
12. The method according to claim 7, further comprising: supporting
a graphical user interface (GUI) that is on a client station, the
GUI providing zoom capability of the map graphic by performing at
least one of (1) drawing a rectangle on the map graphic with a
cursor and (2) positioning a cursor along a zoom bar.
13. The method according to claim 12, wherein a zoom distance is
concurrently displayed corresponding to a position of the
cursor.
14. The method according to claim 1, wherein the positional
information in the outputting step comprises latitude/longitude
information.
15. A geographic information system comprising: an application
server configured to receive input address information and
selection criteria corresponding to requested information; a
database server communicating with the application server, the
database server configured to validate and geocode the input
address information, the database server outputting validated
address information and positional information to the application
server; and a data source coupled to the database server, wherein
the database server retrieves the requested information from the
data source based upon the selection criteria and transmits the
requested information to the application server, and wherein the
application server selectively generates a map graphic based upon
validated address and positional information from the database
server.
16. The geographic information system according to claim 15,
wherein the application server is further configured to optionally
provide map scaling information and generate the map graphic based
upon the map scaling information.
17. A geographic information system comprising: an application
server configured to receive requested information including input
address information; a database server communicating with the
application server, wherein the database server is configured to
geocode the input address information; and a data source coupled to
the database server, wherein the database server is configured to
retrieve the requested information based upon geocoded input
address.
18. The system according to claim 17, wherein the application
server is further configured to receive selection criteria which
corresponds to the requested information, wherein the database
server outputs validated address information and positional
information to the application server, and wherein the database
server retrieves the requested information based upon the selection
criteria.
19. The system according to claim 18, wherein the application
server selectively generates a map graphic based upon the validated
address and the positional information received from the database
server and based upon map scaling information received from a
client station.
20. The system according to claim 17, wherein the database server
comprises a CORBA (Common Object Request Broker Architecture)
object request broker (ORB) to interface with an applications
client.
21. The system according to claim 17, wherein the database server
comprises: an address validation and geocode module configured to
validate and geocode the input address information; and a spatial
information database module configured to store and retrieve
spatial data associated with the requested information.
22. The system according to claim 21, wherein the address
validation and geocode module determines the positional information
according to a predetermined order of precision based upon whether
the input address information is valid.
23. The system according to claim 22, wherein the predetermined
order of precision is at least one of rooftop, ZIP-9, and
ZIP-5.
24. The system according to claim 19, wherein the application
server comprises: a map database containing mapping data; and a
mapping module configured to interface with the map database to
retrieve the mapping data corresponding to the positional
information and to generate the map graphic.
25. The system according to claim 19, wherein the application
server further comprises a JAVA servlet to process the input
address information, selection criteria corresponding to the
requested information, and map scaling information from the client
station.
26. The system according to claim 17, wherein the requested
information comprises at least one of wire center data, rate center
data, PSAP (Public Safety Answering Point) data, CAP (Competitive
Access Provider) data, switch collolocation data, and switch
location data.
27. The system according to claim 19, wherein the application
server supports a graphical user interface (GUI) on a client
station, the GUI providing zoom capability of the map graphic by at
least one of (1) drawing a rectangle on the map graphic with a
cursor and (2) positioning the cursor along a zoom bar.
28. The system according to claim 27, wherein a zoom distance being
concurrently displayed corresponding to a position of the
cursor.
29. The system according to claim 19, wherein the application
server supports a graphical user interface (GUI) on a client
station, the GUI providing a movable map legend associated with the
map graphic.
30. The system according to claim 17, wherein the application
server supports a graphical user interface (GUI) on a client
station, the application server providing a user with a plurality
of push-pin icons for use in determining distance calculation
representative of positions of the push-pin icons on a map
graphic.
31. The system according to claim 17, wherein the application
server and the database server communicates using TCP/IP
(Transmission Control Protocol/Internet Protocol).
32. The system according to claim 17, wherein the positional
information comprises latitude/longitude information.
33. A computer-readable medium carrying a sequences of instructions
for utilizing a geographical information system, the sequences of
instructions including instructions which, when executed by a
processor, cause the processor to perform the steps of: receiving
input address information; geocoding the input address information
to generate positional information; and retrieving requested
information based upon the positional information.
34. The computer-readable medium according to claim 33, wherein the
processor further performs the steps of: outputting positional
information in response to the geocoding step; and receiving
selection criteria corresponding to the requested information,
wherein the retrieving step is further based upon the selection
criteria.
35. The computer-readable medium according to claim 33, wherein the
processor further performs the step of: validating the input
address information; and selectively outputting validated address
information based upon the validating step.
36. The computer-readable medium according to claim 33, wherein the
processor further performs the steps of: selectively generating a
map graphic based upon the positional information; and transmitting
the map graphic and the requested information to a client station
based upon the selectively generating step.
37. The computer-readable medium according to claim 36, wherein the
selectively generating step comprises: interfacing a map database
to retrieve mapping data corresponding to the positional
information; and rendering the map graphic based upon the mapping
data.
38. The computer-readable medium according to claim 33, wherein the
processor further performs the steps of: interfacing with an
applications client via a CORBA (Common Object Request Broker
Architecture) object request broker (ORB).
39. The computer-readable medium according to claim 35, wherein the
geocoding step comprises determining the positional information at
a rooftop level in response to the validating step.
40. The computer-readable medium according to claim 39, wherein the
geocoding step further comprises: determining the positional
information at a ZIP-9 level in response to invalid rooftop level
validation; and alternatively determining the positional
information at a ZIP-5 level in response to invalid ZIP-9 level
validation.
41. The computer-readable medium according to claim 33, wherein the
requested information comprises at least one of wire center data,
rate center data, PSAP (Public Safety Answering Point) data, CAP
(Competitive Access Provider) data, switch collolocation data, and
switch location data.
42. The computer-readable medium according to claim 33, wherein the
positional information comprises latitude/longitude
information.
43. A method of determining service availability using a
geographical information system, the method comprising: providing
address information and a selection criterion; retrieving requested
information based upon the address information and the selection
criterion, the retrieving step comprising, geocoding the address
information, and outputting positional information.
44. The method according to claim 43, further comprising:
validating the address information; and selectively outputting
validated address information based upon the validating step.
45. The method according to claim 43, further comprising
selectively generating a map graphic based upon the positional
information.
46. The method according to claim 45, wherein the selectively
generating step comprises: interfacing a map database to retrieve
mapping data corresponding to the positional information; and
rendering the map graphic based upon the mapping data.
47. The method according to claim 43, wherein the geocoding step
comprises determining the positional information at a rooftop level
in response to the validating step.
48. The method according to claim 47, wherein the geocoding step
further comprises: determining the positional information at a
ZIP-9 level in response to invalid rooftop level validation; and
alternatively determining the positional information at a ZIP-5
level in response to invalid ZIP-9 level validation.
49. The method according to claim 43, wherein the requested
information comprises at least one of wire center data, rate center
data, PSAP (Public Safety Answering Point) data, CAP (Competitive
Access Provider) data, switch collolocation data, and switch
location data.
50. The method according to claim 43, wherein the positional
information in the outputting step comprises latitude/longitude
information.
51. The method according to claim 43, wherein the providing step
comprises initiating a telephone call to a customer service
representative (CSR).
52. The method according to claim 43, wherein the providing step
comprises interfacing with the geographical information system
using a web browser.
53. A memory for storing spatial data and requested information,
comprising a data structure including: an address table for storing
input address information, the input address information being
geocoded to generate positional information, the address table
comprising a positional information field for storing the generated
positional information; and an information table for storing the
requested information, the requested information being retrieved
based upon the generated positional information.
54. The memory according to claim 53, wherein the information table
comprises at least one of: a CAP building table for storing vendor
code data and capability data; a PSAP (Public Safety Answering
Point) table for storing PSAP spatial geometry data, agency data,
and directory number information; an exchange information table for
storing wire center data, OCN (Operating Company Number) data, and
exchange spatial geometry data; a collocation information table for
storing collocation switch data and switch capability data; a
switch information table for storing switch CLLI (Common Language
Location Identification) code data, and LEC (Local Exchange
Carrier) identification data; a rate center table for storing rate
center name data, and rate center spatial geometry data; and a
customer information table for storing customer name data,
directory number data, revenue data, address data, and customer
positional information.
Description
CROSS-REFERENCES TO RELATED APPLICATION
[0001] This application is related to, and claims the benefit of
the earlier filing date of U.S. Provisional Patent Application No.
60/193,241, filed Mar. 30, 2000, entitled "Address Presentation
System", the entirety of which is incorporated herein by
reference.
[0002] This application is also related to U.S. Patent Application
No.__/__,__ (Attorney Docket No. WMA-00-003), filed on even date
herewith and entitled "Address Presentation System Interface," the
entirety of which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0003] 1. Field of the Invention
[0004] The present invention relates to an information processing
system, and is more particularly related to a geographic
information system supporting location of potential customers
and/or facilities relative to existing facilities and/or
infrastructure for retail, wholesale, commercial, utilities, or
other purposes.
[0005] 2. Discussion of the Background
[0006] Companies seeking to deliver products and/or services to
existing or potential customers face a number of challenges
relating to decisions as to how best serve customers in a
particular geographic region. For example, all types of companies
face decisions dealing with provisioning products or services
within a particular geographic region by relating address
information to existing or potential delivery capabilities. These
decisions pose a number of information management challenges with
respect to providing products or services to a customer which
directly impacts the ability to be competitive and responsive to
customers.
[0007] For example, telecommunication service providers, which
include exchange carriers, access providers, and content providers
and the like, face information management challenges with respect
to their networks, spanning engineering and marketing
organizations. Because telecommunication services are regional in
nature, geographic considerations arise throughout the process of
providing telecommunications services to a customer. These
considerations directly impact the ability to be competitive and
responsive to customers.
[0008] However, the ability to be competitive and responsive to
customers is certainly not unique to telecommunications companies.
In fact, these challenges are faced with respect to all entities
delivering products and/or services based on: location of
customers; location and availability of resources; or any other
business-related data or selection criteria related to geographic,
such as input address information, or non-geographic
information.
[0009] Examples of industries facing such challenges include, but
are by no means limited to agriculture, forestry, fishing, mining,
construction, manufacturing, transportation, communications,
electric, gas, sanitary services, wholesale trade, retail trade,
finance, insurance, real estate, provision of any services in
general, public administration, and nonclassifiable establishments.
Additional examples include railroad transportation, local and
interurban passenger transit, trucking and warehousing, postal
service, water transportation, transportation by air, pipelines,
transportation services, and sanitary services, electric utilities,
cable television providers, internet service providers. Still
further examples include owners of and suppliers of/to: building
materials and garden supplies, general merchandise stores, food
stores, automotive dealers and service stations, apparel and
accessory stores, furniture and home-furnishings stores, eating and
drinking places, and miscellaneous retail. The list of product
and/or service providers is literally endless.
[0010] Yet, what all these providers have in common is the need to
better service their existing or potential customers/resources in a
particular geographic locale. Traditionally, when companies perform
prospecting, market analysis, and network planning the focus has
been on using demographic data alone, without factoring in customer
location information. As markets for any product or service
continue to open up, competition necessarily steers attention to
better serving the needs of the customers. All companies in all
types of industries seek to delivery products and/or services
better, faster, and more efficiently. This enables the company to
better ensure their survival as compared to the way their
competitors do business in the particular geographic region of
interest.
[0011] Taking the telecommunications market purely as an example,
the needs discussed herein require the telecommunication service
providers to target customers with greater precision. Misdirected
marketing results in waste of valuable resources. Information
regarding service availability and rates within a target area are
useful in supporting customers' service requirements. Additionally,
knowledge of the locations of the facilities that best serve the
target market promotes network efficiency. For instance, in
targeting potential customers, product and/or service providers
need to know where the best prospects are located. The selection of
collocation sites, mapping of service areas, and determination of a
prospect's proximity to the local city network are difficult, if
not impractical, tasks to perform. Geographic information, thus,
plays an ever-increasing role in servicing customers. The
conventional approach to processing geographic information employs
numerous disparate, non-integrated legacy systems to consolidate
information on location of facilities, extent of network service
coverage, and so on. These legacy systems, from which information
are gathered and processed, do not share a standardized interface,
and thus, require costly customized development to interact with
external systems.
[0012] The traditional Bellcore solution to the problem of
maintaining spatial (i.e., geographical) information is a
combination of vertical and horizontal coordinates and the SAG
(Street Address Guide). For example, buildings are located using
Bellcore Vertical and Horizontal (V&H) coordinates. In the case
of access services, vertical and horizontal coordinates lack
granularity because it is a "large area" geographical solution with
resolution of one mile. This solution has been adequate for large
customers with large orders; however, as telecommunication service
providers penetrate smaller markets, geographic inaccuracies will
result in increased costs. A number of other industry changes in
the local telecommunications service arena, including local number
portability, rate center consolidation, and number pooling require
a solution that overcomes the deficiencies of a large area
geographical system.
[0013] For example, placement of long distance facilities have been
dictated by the ILEC (Incumbent Local Exchange Carrier) wire center
and LATA (Local Access and Transport Area). By and large, the ILEC
has been responsible for providing access to the customer location.
With the advent of new technologies, such as digital subscriber
line (DSL), the emergence of CLECs (Competitive Local Exchange
Carriers) has been steady. It is evident that reliance on the ILEC
as the source of geographical information is no longer a viable
solution as ILECs would inherently be reluctant to assist their
competition.
[0014] Because of the increased competition, for example, in the
local exchange market, the customers are afforded the choice of
selecting among a number of telecommunication service providers.
However, the customers demand that they be able to maintain their
local telephone numbers. Undoubtedly, local number portability
presents a key issue to these telecommunication service providers;
namely, the new telecommunication service provider has only the
phone numbers associated with the incumbent telecommunication
service provider for locating appropriate facilities to serve new
customers.
[0015] The traditional approach has been to obtain the incumbent
provider's facilities information using the customers' phone
numbers, and subsequently mapping such information to the
facilities of the new telecommunication service provider. In other
words, CLECs have relied on a customer's existing and/or nearby
telephone number for switch homing, wire center determination, rate
center determination, and the customer's PSAP (Public Safety
Answering Point) area; however, the relationship between the
customer's NPA/NXX (Numbering Plan Area/3-digit telco central
office number) and address continually changes. Consequently,
relying on a customer's NPA/NXX to determine a switch service area
is not practical in the long-term. It is clear that phone numbers
provide an inefficient way to capture spatial information.
[0016] Based on the foregoing, there is a clear need in all
industries for improved approaches for maintaining geographic
information relating to all types of products and service
availability, as well as customer availability and location. As
stated above, this information is useful in many arenas, and is not
limited to use in providing telecommunication services.
[0017] There is also a need to provide an integrated system for the
retrieval and maintenance of spatial information related to a
region of business interest.
[0018] There is also a need to minimize development cost by
utilizing standardized hardware and software platforms.
[0019] There is yet a further need to increase the accuracy and to
streamline the processes of prospecting, marketing, and strategic
planning of product/service/infrastructure provisioning. Based on
the need of prospecting, marketing, and strategic planning of the
delivery of products/services and infrastructure, an approach for
implementing a geographically enabled information system is highly
desirable.
[0020] There is also a need for a map-graphic based icon distance
calculator that allows for easy distance calculations to transpire,
either alone or in conjunction with other aspects of the invention
based on relevant geographic or non-geographic information, based
upon input address information and specific desired criteria.
[0021] There is still further need for a movable map legend
associated with a map-graphic to allow for easy positioning of the
legend so as not to interfere with viewing presented information.
This need extends for use either alone or in conjunction with other
aspects of the invention based on relevant geographic or
non-geographic information, based upon input address information
and specific desired criteria.
[0022] There is yet a still further need for a continuous zoom bar
associated with a map-graphic to allow for quick and precise
zooming of the map-graphic. This need extends for use either alone
or in conjunction with other aspects of the invention based on
relevant geographic or non-geographic information, based upon input
address information and specific desired criteria.
SUMMARY OF THE INVENTION
[0023] The invention, and exemplary embodiments described within,
could have application, in whole or in part, in many different
utilities and other non-utilities industries, as well as in
commercial ventures in general. The examples of uses of the
inventions described herein, either as a group or individually,
include the telecommunications industry and other utilities to
track network or other assets and facilities, to determine
placement of new facilities, to determine relevant facilities for a
new customer, or to track facilities used by customers. Non-utility
industries and other commercial ventures could use individual tools
associated with this invention described herein. For example, any
industry could benefit from using a push-pin distance calculator
for calculating distances between relevant facilities, in single
steps (`straightline`) or multiple steps (e.g. street distance); or
to present information to customers or potential customers, or to
visualize geographic information to display for use in sales,
marketing, ordering, or delivery, and so on.
[0024] Of course, any other aspects of the present invention may
also be used in combination with other industry-specific
applications or alone. For example, this invention, with
modifications which are clearly understood by those within ordinary
skill in the art, would be able to serve non-telecommunications
industry areas in addition to the telecommunications industry
examples disclosed. Exemplary changes to the telecommunications
examples mentioned herein include the trucking and warehousing
industry, or the food stores and grocery delivery industry, or even
the real estate industry.
[0025] In the case of trucking and warehousing, a warehousing
company might have specific warehouse facilities locations which
store inventory for a given geographic region corresponding in much
the same way as the wire center in the exemplary telecommunications
embodiments described herein. The invention could be used the
determine, based on the input address of the client, which of the
warehouses should be used to store the inventory for that client,
and therefor which truck dispatch should occur. The invention can
be used to plan routes using a push-pin distance calculator based
on selected criteria based on geographic and non-geographic
data.
[0026] In the case of food stores, a food store might have specific
locations which supply retail food to a given geographic area,
corresponding in much the same way as the wire center in the
exemplary telecommunications embodiments described herein. The
invention could be used to determine, based on the customers
address, which food store that customer should visit for their
provisions, or which food store should fill the customers' order if
it is remotely requested by that customer.
[0027] In the case of real estate, a real estate company could
designate specific regions, zones, or territories for their real
estate agents to work within, corresponding in much the same way as
the wire center in the exemplary telecommunications embodiments
described herein. Additionally, they could establish certain
regions or zones for specific real estate features (e.g., school
districts) corresponding to rate centers. The inventions could be
used to identify agents with territories in certain school
districts; or addresses (listings) in an agent's territory, and so
on.
[0028] For the specific capabilities, like the push pin tool: the
distance calculation capability described herein could be used in
industries such as construction. In an industry like construction,
the push pin distance calculation tool could be used to measure the
street distance along truck routes from interstate exits to job
sites in order to ensure trucks are taking the shortest, and likely
fastest, path to the designated site. The invention can be used to
plan routes using the push-pin distance calculator based on
selected criteria based on geographic and non-geographic data. This
allows criteria to be considered in route planning, such as whether
construction trucks are allowed on certain streets or highways. The
push-pin distance calculator can be used either alone or in
conjunction with other aspects of the invention relating to the
planning of routes based on relevant geographic or non-geographic
information, based upon input address information and specific
desired criteria.
[0029] Another exemplary use of the push-pin distance calculator is
for determining distances of marathons, races, an even for tax
purposes related to mileage, either alone or in conjunction with
other aspects of the invention relating to the planning of routes
based on relevant geographic or non-geographic information, based
upon input address information and specific desired criteria.
[0030] Another specific capability includes a movable map legend
that can be used, either alone or in conjunction with other aspects
of the invention relating to the planning of routes based on
relevant geographic or non-geographic information, based upon input
address information and specific desired criteria. The movable map
legend allows a user to move a map legend within a user interface,
and have the legend return to the position the legend was placed
last by the particular user.
[0031] Yet another specific capability includes a continuous zoom
bar that can be used in conjunction with or separate from a system
that provides the industry-specific information relative to a
geographic region. The continuous zoom bar allows a user to
position an input device such as a cursor over a zoom bar which has
a level of zoom associated with the position within the zoom bar.
This feature allows users to easily specify the level of zoom.
[0032] According to one aspect of the invention, a method is
provided of utilizing a geographical information system, the method
comprising receiving input address information; geocoding the input
address information; and outputting positional information in
response to the geocoding step. Under this approach, prospecting,
marketing, and strategic planning of services are accomplished with
increased accuracy and efficiency. This approach in particularly
useful with respect to telecommunication services, but is not
limited to this use.
[0033] According to another aspect of the invention, a geographic
information system is provided, comprising: an application server
configured to receive input address information, selection criteria
corresponding to the requested information; a database server
communicating with the application server, the database server
configured to validate and geocode the input address information,
the database server outputting validated address information and
positional information to the application server; and a data source
coupled to the database server, the database server retrieving the
requested information based upon the selection criteria and
transmitting the requested information to the application server,
wherein the application server selectively generates a map graphic
based upon the validated address and the positional information
from the database server. The above arrangement advantageously
provides use of standardized hardware and software platforms,
thereby minimizing development costs.
[0034] According to yet another aspect of the invention, a
geographic information system is provided, comprising: an
application server configured to receive requested information
including input address information; a database server
communicating with the application server, the database server
configured to geocode the input address information; and a data
source coupled to the database server, the database server
retrieving the requested information based upon the geocoded input
address. The above arrangement also advantageously provides use of
standardized hardware and software platforms, thereby minimizing
development costs.
[0035] In a still further aspect of the invention, a
computer-readable medium carrying a sequences of instructions for
utilizing a geographical information system is provided, the
sequences of instructions including instructions which, when
executed by a processor, cause the processor to perform the steps
of: receiving input address information; geocoding the input
address information to generate positional information; and
retrieving requested information based upon the positional
information.
[0036] In another aspect of the invention, a method is provided for
determining service availability using a geographical information
system, the method comprising: providing address information and a
selection criterion; retrieving requested information based upon
the address information and the selection criteria, the retrieving
step comprising, geocoding the address information, and outputting
positional information. Under this arrangement, users can provision
products/services rapidly and efficiently.
[0037] In a still further aspect of the invention, a memory is
provided for storing spatial data and requested information,
comprising a data structure including: an address table for storing
input address information, the input address information being
geocoded to generate positional information, the address table
comprising a positional information field for storing the generated
positional information; and an information table for storing the
requested information, the requested information being retrieved
based upon the generated positional information. The memory is
structured to enable access of relevant industry-specific
information based on geographic and non-geographic data, based upon
input address information and specific desired criteria.
[0038] These approaches advantageously enhance business processing
of any type of product and/or service, whether it is related to
utility services such as telecommunications, or the broad array of
business applications discussed above. An example of the universal
application of the inventive subject matter includes any type of
product or service sales distribution resource. The map and
requested information may relate to location of existing customers,
potential customers, consumers of related or non-related
products/service, location of product, location of sales personal,
location of sales facilities, and so on. The possibilities are
endless. Many of the examples described herein relate to utilizing
address information converting the information to geospatial
information, and relating the geospatial information to other
information for comparison purposes. However, it is readily
understood by one of ordinary skill in the art that this invention
has applicability to any other industry and would be readily
adaptable thereto without undue experimentation using the
principles described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0039] A more complete appreciation of the invention and many of
the attendant advantages thereof will be readily obtained as the
same becomes better understood by reference to the following
detailed description when considered in connection with the
accompanying drawings, wherein:
[0040] FIG. 1 is a block diagram of the hardware architecture of
the address presentation system (APS), in accordance with an
embodiment of the present invention;
[0041] FIG. 2 is diagram of the software architecture of the system
of FIG. 1;
[0042] FIG. 3 is a diagram illustrating the operation of the APS of
FIG. 1;
[0043] FIG. 4 is a flow chart of the address validation and
geocoding process, according to an embodiment of the present
invention;
[0044] FIG. 5 is an address entry screen of a graphical user
interface (GUI) of the APS, according to an embodiment of the
present invention;
[0045] FIGS. 6A and 6B are a map and information screen of a GUI,
according to an embodiment of the present invention;
[0046] FIG. 6C is a flow chart of the distance calculation
operation supported by the GUI of FIG. 6B;
[0047] FIG. 7 is a diagram of a map legend in the GUI of FIG.
6A;
[0048] FIG. 8 is an address entry screen of a GUI, according to an
embodiment of the present invention;
[0049] FIG. 9 is a retrieved information screen of a GUI indicating
unavailability of service, according to an embodiment of the
present invention;
[0050] FIGS. 10A and 10B are a retrieved information screen of a
GUI indicating availability of service, according to an embodiment
of the present invention;
[0051] FIG. 11 is a failed address validation screen of a GUI,
according to an embodiment of the present invention;
[0052] FIG. 12 is a diagram of the data structure used in the
address presentation system of FIG. 1; and
[0053] FIG. 13 is a diagram of a computer system that can perform
in accordance with an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0054] In the following description, for the purpose of
explanation, specific details are set forth in order to provide a
thorough understanding of the invention. However, it will be
apparent that the invention may be practiced without these specific
details. For instance, repeated use of telecommunications-related
products/services are used to provide a consistent exemplary
industry application, but are in no way intended to limit the scope
of the invention to applicability to only this industry since
universal application to any other product/service arena is
intended. In some instances, well-known structures and devices are
depicted in block diagram form in order to avoid unnecessarily
obscuring the present invention. Although the present invention is
discussed with respect to exemplary protocols, computer languages,
and operating systems, the inventions can be implemented on any
computer system regardless of protocols, languages, or operating
system platform.
[0055] The present invention accomplishes effective retrieval of
spatial information relating to, for example, telecommunication
services and associated networks by utilizing a robust
client/server architecture. Through a web client application, the
user specifies various requested relevant geographic or
non-geographic information regarding telecommunication facilities,
services, and so on (collectively referred to as telecommunication
information) and inputs address information into an address
presentation system (APS). In turn, the APS sends a map, if
requested, along with the requested telecommunication information
to a client station, which displays the map and the requested
information via a robust and intuitive graphical user interface
(GUI). Among other functional capabilities, the GUI provides
extensive zooming functionalities, distance calculation using
"push-pin" icons, a user-customizable movable map legend, and map
redraw capability within a single screen. The APS also supports
desktop applications with targeted functionality, so that spatial
information can be readily obtained through many types of client
applications. The APS is based upon standards compliant
client/server architecture, which includes an application server
(e.g., web server) and a database server. Additionally, the APS
utilizes a Common Object Request Broker Architecture (CORBA),
thereby permitting any CORBA compliant system to utilize the
resources of the APS.
[0056] Although the present invention is discussed with respect to
exemplary protocols, computer languages, and operating systems, the
APS can be implemented on any computer system regardless of
protocols, languages, or operating system platform. Furthermore, it
is recognized by one of ordinary skill in the relevant art that the
present invention relates to gathering any type of information in
general, even though the present invention is discussed with
respect to telecommunication information.
[0057] The APS is a geographic information system that supports,
for example, telecommunication service providers in their mission
to deploy telecommunication services and to manage their network
infrastructure. In general terms, the APS is an organized
collection of computer hardware, software and geographic data that
provides entry, storage, query and display of geographic reference
information related to facilities and service coverage.
[0058] FIG. 1 shows the hardware architecture of the APS, in
accordance with an embodiment of the present invention. The APS
system 101 includes a web server 103 that communicates with a
database server 105 over, for example, a local area network (LAN)
(not shown). The web server 103 interfaces with a map database 107
to retrieve map data; according to one embodiment, the database 107
resides within the web server 103 itself (as shown in FIG. 3).
Alternatively, the database 107 can be situated external to the web
server 103. In an exemplary embodiment, the web server 103 is a
server-class IBM-compatible running the Microsoft Windows NT
operating system.
[0059] The APS 101 provides a web application that returns a map
and associated attribute information (e.g., telecommunication
information) based on user input of a service address (e.g.,
city/state/zip code, street address/zip, or and so on). The input
address is validated and mapped to reference information, which,
according to one exemplary embodiment, includes rate centers, ILEC
wire centers, on-ring and LIT/CAP (Competitive Access Provider)
buildings, switch information, and switch collocation (COLLO)
information. A wire center is the geographic serving area of an end
office (or central office) that describes the location of the local
loop between the customer and the first (highest numeric class)
switch. Traditionally, the end office has been limited by the
maximum transmission length of copper wires. Rate center pertains
to telephone company-designated geographic locations assigned
vertical and horizontal coordinates between which mileage are
determined for the charging of private lines. That is, the distance
between two rate centers is used to compute the charge rates for
telecommunication services provided in the area between the rate
centers. COLLO information pertains to the facilities of a third
party where a piece of equipment of the telecommunication service
provider resides.
[0060] To retrieve, for example, requested telecommunication
information, client stations 109 access the web server 103 using
standardized web browsers (e.g., Microsoft Internet Explorer,
Netscape, and so on); this retrieval operation is more fully
discussed in FIG. 3. To serve these client stations 109, web server
103 executes JAVA applications (e.g., JAVA servlets). JAVA provides
operating system independence, enabling language flexibility and
code-reuse. Additionally, the web server 103 supports non-web
enabled client stations, such as client station 111, via a mapping
module application, which is more fully discussed in FIG. 2.
[0061] As described above, the APS 101 supports two deployments:
(1) a client/server solution, and (2) a web application. In the
client/server distribution, desktop mapping software (e.g., MapInfo
Professional) is loaded on a client station 111 to access the
spatial information within APS 101. The desktop geographic
application enables the user to perform complex geographic analysis
by processing the information provided by the web server 103 and
the database server 105.
[0062] The database server 105 operates on a UNIX platform (e.g.,
HP-UX 10.20 by HewlettPackard); according to one embodiment, the
hardware is a Hewlett-Packard server (e.g., T-class). The database
server 105 interacts with database 113, which stores information
(e.g., telecommunication information such as wire centers, rate
centers, PSAP, LIT/CAP, switch locations) from a myriad of data
sources 115. The data sources 115, in one embodiment, include
commercially available data (e.g., rate center, wire center, PSAP,
customer demographic information) as well as data from the
information systems of the telecommunication service provider
(e.g., switch information, switch collocation information, and CAP
buildings). As used herein, the term telecommunication information
include information from these data sources 115. (A myriad of
non-telecommunication information may also be used in another
embodiment of the invention accordance with other industries
seeking to relate address information to data sources about regions
which have access to or near the address.) Furthermore, the APS 101
interfaces with many external systems (not shown) using CORBA 119.
Specifically, (as seen in the figure) client station 117 can access
information from database server 105 using CORBA 119.
[0063] The architecture of the APS 101 enables the return of a
standard API (Application Programming Interface) that outputs all
pertinent geographic information. This approach advantageously
reduces development and implementation time for new interfaces to
other systems by leveraging an existing multi-purpose (or generic)
API, rather than requiring new development for each new system
interface. Additionally, APS 101 brings the power of geographical
based analysis and decision support tools to client stations 109,
111, and 117. These aspects are very helpful in applying the
concepts described with respect to the telecommunications examples
to other applications in a variety of industries.
[0064] As a geographical information system, APS 101 defines three
distinct types of geographical information: (1) points, (2) lines,
and (3) polygons. APS 101 provides the client stations 109, 111,
and 117 with the ability to query this "spatial" data; for example,
to map an input address to a rate center (a point to a polygon),
determine the distance from a building to a switch (point to point)
or view all collocation switches within a serving wire center
(point to polygon). A spatial query combines geographic polygons,
lines and points; this information can be represented by different
icons on a map, displayed as text on a screen, or distributed to
other systems via a messaging interface. Once again, these options
allow easy transition from the telecommunications examples provided
herein to applications in other industries.
[0065] JAVA applications coupled with CORBA compliant middleware
enables object to object communication between the objects in
client and server roles. Middleware is software that is transparent
to a user, which takes two or more applications and makes them work
seamlessly together. With middleware technology, a user can design
an ordinary component to provide its regular function, and then
insert an appropriate middleware mix when the component is built or
created at run time. In a CORBA environment, an Object Request
Broker (ORB) receives request for services of software modules from
programs on clients (e.g., client stations 109, 111, and 117) and
servers 103 and 105. The JAVA/CORBA ORB middleware enables
distribution of objects, making the APS 101 appear as a single
system.
[0066] In a CORBA environment, a program makes a request for
services of software modules through an ORB, and thus, does not
need to know the design and composition of the program, which
includes the software. In client/server applications, an ORB is an
interface to which the client station 117 makes a request for
service from a software object, which in this case is within
database server 105. The ORB then directs the request to the server
(e.g., server 105) hosting the software object and returns the
resulting value(s) of the service to the client (e.g., client
station 117).
[0067] In an object-oriented programming environment, a client is
defined as a member of a class or group that uses the services of
another class or group to which the client is not related by way of
inheritance from a common class or group. More generally, a client
is a software module that requests a service provided by another
software module. The client uses the requested service without
having to know any working details about the other software module
or the service. In a network environment, a server is defined as a
computer or program that responds to commands from a client.
[0068] CORBA software objects are components of intelligence that
may reside anywhere on a network. They are packaged as binary
components which remote clients may access via method invocations.
Both the language and compiler used to create server software
objects are transparent to clients. Clients have no need to know
where the distributed software object resides or on what operating
system it executes. The distributed software object may be in the
same process or on a machine that sits across a large network.
Additionally, clients have no need to know how a server software
object is implemented. For example, a server software object may be
implemented, for example, as a set of JAVA classes, or it may be
implemented as a large COBOL (Common Business-Oriented Language)
program. The client only needs to know the interface its server
software object publishes. The interface then serves as a binding
contract between client stations 109, 111, and 117 and servers 103
and 105.
[0069] Such interface specifications are written in a neutral
Interface Definition Language (IDL) that defines a component's
boundaries; that is, its contractual interfaces with potential
clients. Components written to IDL are accessible across languages,
tools, operating systems, and networks.
[0070] IDL-specified methods can be written in and invoked from any
language that provides CORBA bindings. Examples of such languages
include JAVA, C, C++, Ada and Smalltalk. Programmers interact with
CORBA software objects using native language constructs. IDL
provides operating system and programming language independent
interfaces to all the services and components that reside on a
CORBA bus. This allows client and server software objects written
in different languages to communicate with one another. OMG IDL is
utilized to specify a component's attributes, the parent classes
from which the component inherits, the exceptions it raises, the
typed events it emits, and the methods its interface supports,
including the input and output parameters and their data types. The
CORBA IDL allows component providers to specify in a standard
definition language the interface infrastructure of the software
objects that they provide.
[0071] The CORBA Object Request Broker is the software object bus.
As previously indicated, the ORB enables software objects to
transparently make requests to, and receive responses from, other
software objects located locally or remotely. The client is not
aware of the mechanisms used to communicate with, activate, or
store these server software objects. A CORBA ORB provides a wide
variety of distributed middleware services. The ORB allows software
objects to discover each other at run time and invoke each other's
services. An ORB is much more sophisticated than alternative forms
of client/server middleware, including traditional Remote Procedure
Calls (RPCs), Message-Oriented Middleware, database stored
procedures, and peer-to-peer services. Nevertheless, all these
alternative forms could be implemented by one skilled in the art to
achieve equivalent functionalities.
[0072] FIG. 2 shows the software architecture of the APS, according
to one embodiment of the present invention. The client stations
109, 111, and 117 and the servers 103 and 105 run TCP/IP
(Transmission Control Protocol/Internet Protocol) 201 to
communicate among themselves as well as to other external systems
(not shown). In particular, web server 103 communicates with
database server 105 over a TCP/IP socket. Client station 111 also
uses TCP/IP to exchange information with database server 105. One
of ordinary skill in the art would recognize that other transport
layer protocols can be utilized (e.g., User Datagram Protocol
(UDP)).
[0073] As web clients, client stations 109 employ the Hypertext
Transfer Protocol (HTTP) 203 to exchange information with web
server 103. HTTP 203 is an application-level protocol for
distributed, collaborative, hypermedia information systems; IETF
(Internet Engineering Task Force) RFC (Request for Comment) 2616
specifies this protocol and is incorporated by reference herein in
its entirety. HTTP 203 advantageously provides development or
modification of the APS 101 independent of the data being
transferred.
[0074] According to one embodiment, the two primary operating
systems supported by APS 101 are UNIX 205 and Microsoft Windows NT
207. Database server 105 runs UNIX 205 in the form of HP-UX 10.20,
which complies with the following standards: X/Open's Single UNIX
Specification (SPEC1170); X/Open Portability Guide, Issue 4 (XPG4);
(System V Interface Definition, Issue 3 (SVID3) level 1 APIs; Open
Software Foundation (OSF) Application Environment Specification
(AES); and Common Desktop Environment (CDE) standard. Windows NT
207 is run on web server 103.
[0075] The APS 101 utilizes a number of applications to provide
efficient retrieval of requested information, such as
telecommunication information for example. In particular, the web
server 103 contains a mapping module 209 as well as a variety of
JAVA servlets 211. The JAVA servlets 211 provide interaction with a
web browser 215 on the client station (e.g., client stations 109).
The mapping module 209 permits the overlay of telecommunication
information from the database server 105 onto a map with street
level detail. In an exemplary embodiment, the street map is
StreetPro by MapInfo. As will be described more fully in FIG. 3,
the mapping module 209 generates a map graphic based upon the
received telecommunication information. The mapping module 209,
according to one embodiment of the present invention, is the
mapping application server MapXtreme by MapInfo. The mapping module
209 provides connectivity to live data sources 115 by interfacing
with the spatial information database module 213 within database
server 105. The mapping module 209 provides the capability to draw
customized objects onto a map and to display a specific point on
the map (based upon address information). Additionally, the mapping
module 209 supports spatial selection, whereby a specific location
and its associated spatial data can be selected for examination.
The location can be specified for example according to a
rectangular area, a radial area, or a polygon.
[0076] The database server 105 runs UNIX 205 to support the spatial
information database module 213 and an address validation and
geocode module 217. The database server 105 implements a relational
database 219, for example, Informix 9. It is recognized that other
relational database platforms (e.g., ORACLE 8.05) can be used in
the APS 101. The spatial information database module 213 enables
the integration of spatial data with the existing data of database
219 by providing a SQL (Structured Query Language) database for
spatial operations. Additionally, data from the data sources 115
can be efficiently and rapidly loaded onto the database 113 by the
spatial information database module 213, which further supports the
mapping module 209 in web server 103. According to one embodiment
of the present invention, the spatial information database module
213 is SpatialWare DataBlade by MapInfo; optionally, it is
recognized by one of ordinary skill in the art that other
equivalent spatial technology products can be utilized.
[0077] Furthermore, the database server 105 possesses an address
validation and geocode module 217 to provide address validation and
geocoding. The term geocoding, as used herein, denotes
determination of positional information based upon address
information; the positional information may be any of latitude and
longitude coordinates, Cartesian coordinates, spherical
coordinates, polar coordinates, and so on. The operational details
of the address validation and geocode module 217 are discussed
below in FIG. 3. In terms of its functional capabilities, the
address validation and geocode module 217 validates an input
address by comparing it with address ranges within a United States
Postal Service (USPS) address ZIP+4 database, and subsequently,
outputs a validated address (which is in standard format according
to the USPS address ZIP+4 database). The address validation and
geocode module 217 then geocodes the validated address, returning
positional information (e.g., latitude and longitude) to the web
server 103. In an exemplary embodiment, the address validation and
geocode module 217 includes the CODE-1 Plus software by Group 1
Software to perform the address validation. This operation as well
as the operation of the overall APS 101 is described in FIG. 3.
[0078] FIG. 3 shows the operation and interaction among the
software modules of the APS 101. In step 301, a client station 109
submits an input address via the web browser 215 to the web server
103, which has a JAVA servlet 211 that processes the input address.
The address, as in step 303, is transmitted by the web server 103
to the database server 105, where the address is validated and
geocoded by the address validation and geocode module 217. In turn,
the address validation and geocode module 217 outputs a validated
address and positional information (e.g., latitude and longitude)
to the web server 103 (step 305). In step 307, a JAVA servlet
(e.g., MapXtreme servlet (MAPJ)) accesses the spatial information
database module 213 to query the database 113 (e.g., Informix
database). Exemplary queries are as follows: point-in-polygon to
rate_center for rate_center_name and boundary, point-in-polygon to
wire_center for wire_center_name, point-in-polygon for PSAP name
and boundary, CAP buildings, and switches and collocation switches
in the rate_center. In step 309, the database server 105 returns a
mapped object to the web server 103. The web server 103, as in step
311, accesses the map data 107 via the mapping module 209.
Thereafter, map data 107 is retrieved (step 313). In an exemplary
embodiment, the map data 107 is street data layer associated with
MapInfo StreetPro. In step 315, all spatial data are processed by
the mapping module 209, which renders a map graphic (e.g., GIF
(Graphical Interchange Format) file). The map graphic, per step
317, is sent to the JAVA servlets 211, for transmission to the web
browser 215 (step 319).
[0079] FIG. 4 shows a flow chart of the address validation and
geocoding process performed by the address validation and geocode
module 217. In general, the address validation process validates an
input address and then geocode on a rooftop level of precision. If
the input address fails validation, the address validation and
geocode module 217 attempts to determine positional information
(e.g., latitude and longitude) at the ZIP-9 level, and then the
ZIP-5 level (the ZIP-9 level exhibiting greater than ZIP-5
precision because the location area is narrower). In step 401, the
input address is received. The address validation and geocode
module 217, as in step 403, compares the input address with the
addresses in the USPS database (not shown). Next, in step 405 the
address validation and geocode module 217 determines whether a
match is found in the USPS database; if a match is found, the
address is valid. Upon determination that a valid USPS address
exists, this validated address is geocoded at the rooftop level to
yield the latitude and the longitude. The validated address is
returned to the web server 103 (step 409); thereafter, as in step
411, the positional information is also sent to the web server 103.
However, if the input address is invalid, then the address
validation and geocode module proceeds to geocode either at the
ZIP-9 level (i.e., with the precision of all nine ZIP digits) or
the ZIP-5 level, depending on the closest address match (step 413).
The ZIP code (5 digits) or ZIP+4 code (9 digits), per step 415, is
forwarded to the web server 103. Under this scenario, the latitude
and longitude information can represent the center of the ZIP code
area, according to one embodiment of the present invention.
[0080] Other embodiments include attributing the latitude and
longitude information to other characteristics of the ZIP code
area, such as for example, the center of concentration of the
population associated with the ZIP code. Alternatively, other
attributes for returning a match in step 413 may be based on any
information related to application in a particular industry. For
example, road location and traffic volume near a particular
latitude and longitude associated with an input address may be
useful to a particular industry. This example might be of use in
any industry determining where to locate an aspect of their
business (e.g., gasoline station, customer service center of
agents, product sales site, and so on).
[0081] FIG. 5 shows a GUI that provides a user with a mechanism to
enter an address of a service location. According to an embodiment
of the present invention, the GUI is an address entry screen 501
that is supported by a web browser 215 on a client station (e.g.,
client stations 109). The address entry screen 501 includes an
address field 503 with a text box 505 for entering street
information. Another text box 507 permits entry of the city of the
service location. The address entry screen 501 also has a pull-down
text box 509 to designate the state of the service location. The
user may enter the abbreviation of the state directly in box 509 or
click on an arrow 511 to trigger a scrolling list of state
abbreviations. The ZIP+4 code field has two text boxes 513 and 515
for entry of the 5-digit ZIP code and the 4-digit extension,
respectively. Any of the fields 505, 507, 509, 513 and 515 can be
made optional, so long as an individual field or a combination
thereof permits the address validation and geocoding process
performed by the database server 105 to return valid positional
information.
[0082] As seen in FIG. 5, the address entry screen 501 displays a
number of selection criteria in form of check boxes 517 that
corresponds to various information, e.g., telecommunication
information. However, as mentioned previously, any type of
information can be processed; for instance, a manufacturer can
maintain product information with the APS 101 based upon
demographics of the region. As an additional example, a courier
service may wish to manage its distribution channels; in this
manner, distribution hubs and their coverage areas can be easily
determined. According to one embodiment of the present invention,
the selection criteria include the following: rate center (Rate
Cntr); wire center (Wire Cntr); switch of a particular
telecommunication service provider, e.g., MCI (MCI Switch);
end-office collocation switch (EO COLLO); public safety access
point (PSAP); and LIT and CAP building (LIT/CAP). LIT/CAP buildings
denote facilities in which the telecommunication service provider
has agreements with other CLECS Competitive Access Providers (CAP)
to provide access and lease equipment. A building may have many
CAPs associated with it. LIT building signifies that the building
is ready to carry traffic and that the customer is ready to
provision service.
[0083] In an exemplary embodiment, the user can check any one or
number of boxes 517 based upon the telecommunication information
that is desired. Also, any one of these check boxes 517 can be
checked as a default. Checking of each selection criteria boxes
determines that particular map layers that are to appear on the
generated map graphic. An "All Clear" field 519 unchecks all the
boxes 517.
[0084] As shown, an "All" check box 521 associated with the Desired
Text Details field allows the user to designate whether all
available telecommunication information corresponding to the
checked boxes 517 should be retrieved. In accordance with one
embodiment of the present invention, the All check box 521 is
programmed to always be checked; thus, as a default, the APS 101
returns all the text details of the telecommunication information.
The address entry screen 501 additionally permits the user to enter
a value in text box 523, which is associated with the Initial
Display Size field, thereby, specifying the scale of the map that
is to be generated by the web server 103. According to this
example, the value represents miles. The range of this value
depends on the sizing and capacity of the APS 101; in an embodiment
of the present invention, the range is from 1 to 200 miles. A Yes
check box 525 of the Return A Map field permits the user to
indicate whether a map graphic is to be generated. If the Yes check
box 525 is unchecked, text of the telecommunication information
will be displayed, without the map graphic.
[0085] The address entry screen 501 has two buttons 527 and 529,
which are labeled "MapIt" and "Clear", respectively. The Clear
button 529 clears all the fields 503, 505, 507, 509, 513, and 523
and all the check boxes 517, 521, and 523. That is, the Clear
button 529 essentially clears and refreshes the screen 501 for a
new address. The Maplt button 527 initiates the query to the APS
101 to create a map and display telecommunication available for a
particular service location as indicated by the input address
information.
[0086] The About field 531 on the upper right-hand corner of the
address entry screen 501 provides a brief description of the APS
101 as well as version information. Also on the upper right-hand
corner is a Help field 533 that refers the user to an online APS
User Guide, which provides explanatory information on the address
entry screen 501 as well as other information on the APS 101.
[0087] FIGS. 6A and 6B show a map and information screen 601 of the
GUI, which is displayed based upon address information and the
specified selection criteria of the address entry screen 501.
Assuming the user has indicated that a map graphic is to be
generated by checking box 525 and has selected all the available
selection criteria boxes 517, a map and information screen 601 (as
shown in FIG. 6B) is displayed to the user on the client station
109. FIG. 6A shows the first view of the map and information screen
601; upon scrolling to the end of the map and information screen
601, a client station displays the view shown in FIG. 6B. The map
and information screen 601 includes a map graphic 603 that
illustrates the service location (as specified by the input
address) at a street level. The scale of the map graphic 603
corresponds to the value of the display size in box 523, which, in
this example, is 10 miles.
[0088] The map graphic 603 contains the overlay of icons
representing the telecommunication information corresponding to the
chosen selection criteria. The map and information screen 601
includes a map legend 605 to identify these icons. For example, a
diamond icon 607 denotes a location of the collocation switch
within the area of the service location.
[0089] The telecommunication information, in text form, are
displayed in text box 609 of the rate centers, text box 611 of the
wire centers, text box 613 of the MCI switches, text box 615 of the
collocation switches, text box 617 of the PSAP, and text box 619 of
the CAP/LIT buildings. The map and information screen 601
automatically displays scroll bars for these text boxes (e.g., 613,
615, 617, and 619) if the telecommunication information in the
respective categories exceed a predetermined number of lines. That
is, frames are used to display information, as appropriate. In this
case, the telecommunication information relating to rate centers
and wire centers occupy only a single line each; their respective
text boxes 609 and 611 do not have scroll bars. It should be noted
that screen 601 may represent a map graphic apart from, or in
combination with, other information, and any other information need
not be displayed with the map graphic.
[0090] When information is displayed, such as for example, the
telecommunication information, it is associated with each of the
selection criteria are specific to the exemplary category. The
fields of the Rate Centers text box 609 include the Rate Center
Name field 609a and the State field 609b. The Wire Centers box 611
has a Wire Center Name field 611a, a State field 611b, a LATA
(Local Access and Transport Area) field 611c, and an NPA (Numbering
Plan Area) field 611d. The switch information text box 613 includes
a Label field 613a to identify the switch, a switch CLLI (Common
Language Location Identification) code field 613b, a Switch Type
field 613c, and a Company field 613d to indicate the company that
owns the respective switch. The collocation switch text box 615
encompasses the following fields: a Label field 615a to identify
the collocation switch, a COLLO CLLI field 615b, a Within WC (wire
center) field to indicate whether the collocation switch falls
within the boundary of the wire center, and a Distance From Input
Point field 615d to specify the distance from the input address to
the particular collocation switch. The PSAP text box 617 includes
an Agency field 617a to identify the particular agency, a Coverage
field 617b to specify the area of coverage of the PSAP, a FIPS
field 617d, a County field 617e, and a Routing Number field 617e to
specify the number that the emergency number is translated to (or
resolved to).
[0091] To inform the user on the information that has been provided
to the APS 101, the map and information screen 601 displays the
selection criteria check boxes 517 of the Desired Map Details field
as well as the input address information 621 (as shown in FIG. 6B),
which is the actual search address used in the address validation
and geocoding process. Additionally, the map and information screen
601 provides a USPS Validated Address field 623, which includes a
ZIP+4 code. It should be noted that if no valid address is found,
an appropriate message is displayed under the USPS Validated
Address field 623; for example, "None Found." The Latitude and
Longitude field 625 is displayed; in this example, this positional
information has been calculated with rooftop precision. The map and
information screen 601 has a ReDrawMap button 627, which triggers
the regeneration of the map graphic 603. The user can click on the
ReDrawMap button 627, for example, if different selection criteria
are desired or the map graphic 603 display size has been
altered.
[0092] In addition to the map and attributes listed above, APS 101
can provide distance information from the input address to, for
example, switch, collocation switch and building locations.
Distance information can be provided either from a straight-line
perspective or along the streets from the starting address to the
destination. With APS 101, the user also has the flexibility to
perform running distance calculations from one point on the map to
another, with any number of intermediate points; this operation is
more fully described below with respect to FIG. 6C.
[0093] The APS 101 is designed to support a number of business
functions (e.g., the order entry process). As an illustration,
customer service representatives (CSRs) routinely need to determine
the distance from the customer location to an ILEC end office for
DSL (Digital Subscriber Line) provisioning and the distance from
CAP and on-ring buildings for near ring solutions. With the
distance calculation capability, the CSRs are able to make the
distance determination quickly.
[0094] The map and information screen 601 enables distance
calculation using the map graphic 603. Specifically, the user can
designate numerous points on the map graphic 603 for distance
calculation by placing two or more icons (which, in an exemplary
embodiment, resemble pushpins) onto the map graphic 603. The
distance calculation is performed in two ways: (1) between a latest
push-pin and the immediately preceding push-pin (i.e., current
distance); and (2) from the first push-pin through the last
push-pin including all intermediate push-pins (i.e., cumulative
distance). In other words, the current distance indicates
calculated distance from the previous point to the last point. The
cumulative distance indicates total road distance from the starting
point through the last point. Alternatively, straight-line
distances are calculated directly from the first push-pin to the
most-recently positioned push-pin, that need not be a road-distance
calculation.
[0095] FIG. 6C shows a flow chart of the distance calculations, in
accordance with an embodiment of the present invention. The ability
to place the push-pins 629, 631, and 639 (as shown in FIG. 6B) is
triggered by first clicking on Distance button 633 (step 671). In
step 673, the user places a first push-pin and a second push-pin;
for example, the user places a starting push-pin 629, and an
intermediate push-pin 631 (FIG. 6B). Next, as in step 675, the
current distance is calculated and displayed based upon the
placement of the push-pins 629 and 631. Additionally, the
cumulative distance is calculated and displayed, per step 677. At
this point, the Current Distance field 635 and the Cumulative
Distance field 637 would show equal values. If the user has not
completed tracing out a route (step 679), the user places another
push-pin onto the map graphic 603 (step 681). Upon placing the last
push-pin 639, the Current Distance field 635 would display the
distance between the intermediate push-pin 631 and the last
push-pin 639, while the Cumulative Distance field 637 would show
the cumulative distance from push-pin 629 to push-pin 631 plus the
distance from push-pin 631 to push-pin 639. If the user has
finished tracing out a route, the process ends. As seen in FIG. 6B,
a Reset button 641 clears the Current Distance field 635 and the
Cumulative Distance field 637, eliminating any push-pin icons on
the map graphic 603. The distance calculation functionality
advantageously provides a mechanism to easily trace out a route and
determine its distance, which is useful in effecting engineering
changes or answering service availability inquiries.
[0096] The map and information screen 603 also provides expansive
zooming capabilities: rectangular zooming, and zooming via a zoom
bar. The user can elect to draw a rectangle 643 of any size within
the map graphic 603; a subsequent map graphic 603 is generated with
a scale corresponding to the size of the rectangle 643.
Alternatively, the user can position a cursor 645 along a zoom bar
647, in which a zoom distance 649 is concurrently displayed
corresponding to the position of the cursor 645. In this
embodiment, the zoom bar 647 provides the ability to specify
continuous zoom values (shown as zoom distance 649). Alternatively,
the zoom bar 647 can be configured to specify discrete zoom values
corresponding to discrete areas depicted in the zoom bar 674. Upon
positioning the cursor 645 over an area of the zoom bar 647
corresponding to the desired level of zoom, as reflected by zoom
distance 649, the user can select this level of zoom, for example,
by clicking a mouse (not shown) The map and information screen 601
further supports panning of the map graphic 603 via directional
icons in form of pan arrows 651.
[0097] FIG. 7 shows a large view of the map legend 605. The map and
information screen 601 permits the user to move the map legend 605
about the screen 601 (FIG. 6A) so that the user can customize where
the map legend 605 should be situated. The APS 101 retains this
customization by the user so that the map and information screen
601 will display the map legend 605 at the location where the user
last specified. In other words, the APS 101 stores information
regarding the location of the map legend 605 for each individual
user independently for each such users; accordingly, the location
information of the map legend 605 is retrieved by the APS 101 in a
subsequent user session. Effectively, other users can move the map
legend 605 according to their preferences without imposing any
particular preference to another user. The map legend 605 can also
be minimized to avoid obstructing significant portions of the map
and information screen 601.
[0098] In view of the functionalities discussed above, the APS 101
supports a number of critical functions within an organization, the
exemplary the telecommunication service provider. These functions
can include prospecting, sales and marketing, network planning,
site or agent location, product distribution, and service
provisioning. The APS 101 permits visually targeting prospective
customers based on proximity to, for example, LIT/CAP buildings and
switches to determine the lowest access cost. Additionally, the APS
101 also supports identification of clusters of prospects with high
revenue potential. The APS 101 ensures that no prospects will be
targeted in municipalities that cannot be served by
telecommunication service provider, without excluding surrounding
or overlapping rate centers.
[0099] Further, the sales and marketing department can utilize APS
101 to identify the correct rate center based on physical location
rather than NPA/NXX. As such, by using the information retrieved by
the APS 101, the telecommunication service provider can minimize
the number of rejected orders arising from incorrect switch and
NPA/NXX assignment. APS 101 also provides the sales organization
the capability to identify the services available for a location
(e.g., HDSL (High-bit-rate Digital Subscriber Line)), which is only
available to customers within 12,000 feet of a switch). Further,
the sales organization can rapidly identify the correct PSAP area
so that E911 service routing and dispatch is set up correctly. The
marketing organization of the telecommunication service provider,
using APS 101, can define key business areas (tariff areas,
promotional areas, and so on). As indicated above, the APS 101 has
applicability to non-telecommunication services. A food delivery
service business or door-to-door sales organization, for instance,
can quickly tell a potential customer whether the customer's
residence falls within the service area.
[0100] With respect to service provisioning of telecommunication
services, the APS 101 provides the following support functions:
determination of the most cost-effective service delivery method to
use by basing this selection on address rather than NPA/NXX, and
determination of which switches/collocation switches a customer can
be provisioned to based on serving wire center or LATA. The APS 101
also supports the capability to provision service based upon
"political" considerations in that the APS 101 can filter and/or
sort out information with respect to deployment of services
requiring the use of a competitor's facilities, services, and so
on. For example, the collocation switches can be prioritized
according to the third party telecommunication service provider (or
vendor). In a competitive environment, it is preferred that a
telecommunication service provider utilize the facilities or
services of another provider that poses the least threat to the
telecommunication service provider's market position. A weighting
function can be applied to all providers in a service area to
prioritize preferred providers over, for example, competitors.
Additionally, the engineering organization can utilize APS 101 to
plan and man age network growth. Specifically, APS 101 permits
network planners with the capability to identify the best place to
locate new facilities for a target market.
[0101] The APS 101 provides a more targeted GUI for rapidly
obtaining specific telecommunication information. FIG. 8 shows a
GUI, according to an embodiment of the present invention, which is
used to determine service availability with respect to a particular
location. The GUI includes two screens: a service location address
entry screen, and a service availability result screen. In this
example, the service is HDSL, which is a distance dependent
service. Similar to the address field of the address entry screen
501, as discussed above, the service location address entry screen
801 has an address text box 803 for the street, a city text box 805
for the city, a state pull-down text box 807 for the state, and
ZIP+4 text boxes 807 and 811. A Clear button 815 is provided to
allow the user to clear all the entry text boxes 803, 805, 807,
809, and 811. The user launches the query to the APS 101 by
clicking a Go button 813.
[0102] FIG. 9 shows a service availability result screen 901,
according to one result scenario (i.e., service is not available).
The service availability result screen 901 displays an Input
Address field 903 to repeat the address information that was
entered by the user as a way to ensure that the user has entered
the correct address information. Next to the Input Address field
903 is a Validated Address field 905. Additionally, the positional
information is captured in the Latitude and Longitude field 907.
The telecommunication information that was obtained from the APS
101 include the identity of the wire center that is nearest the
service location (as specified by the input address) under the Wire
Center field 909, the collocation switch that is HDSL capable under
the HDSL Capable Collocation switches field 911, and a Within Range
field 913 to indicate whether the HDSL is within range of the
service location. The service availability result screen 901 also
provides a text box 915 to provide a detailed description of why
the service is not available.
[0103] FIGS. 10A and 10B show the service availability result
screens under two different scenarios in which service has been
indicated as available. FIG. 10A shows the case where HDSL is
available in the service location specified, as evident by the
Within Range field 913. In FIG. 10B, the input address failed
validation; therefore, the validated address is based upon
ZIP-9.
[0104] FIG. 11 illustrates the case in which the input address also
failed USPS address validation. This scenario differs from that of
FIG. 10B because geocoding cannot be performed based on ZIP-9 or
ZIP-5.
[0105] FIG. 12 shows a data model used in the address presentation
system, according to an embodiment of the present invention. It is
recognized by one of skilled in the art that the particularities of
the data definitions are not needed to implement the APS 101; these
particularities can be tailored and defined according to the design
requirements of the telecommunication service provider. The APS 101
utilizes a number of tables associated with the telecommunication
information, as follows: CAP_BUILDING table 1201, PSAP table 1203,
EXCHANGE_INFO table 1205, COLLO_INFO table 1207, SWITCH_INFO table
1209, and RATE_CTR table 1211. The APS 101 also use an ADDR_INFO
table 1213 and a CUSTOMER_INFO table 1215.
[0106] The three key polygon type tables are the EXCHANGE_INFO
table 1205, the RATE_CTR table 1211, and the PSAP table 1203. The
EXCHANGE_INFO table 1205 pertains to the wire center boundary and
includes the following fields: a WIRE_CTR field 1205a, an OCN
(Operating Company Number) field 1205b, and a SPATIAL_GEOMETRY
field 1205c. The RATE_CTR table 1211 has a RATE_CTR_NAME field
1211a and a SPATIAL_GEOMETRY field 1211b. The PSAP table 1203,
which provides spatial data for the PSAP area, has a
SPATIAL_GEOMETRY field 1203a, an AGENCY field 1203b for the
identity of the agency, and a TEN_DIGIT_NO field 1203c for storing
the ten-digit phone number that the emergency number translates
into. Each of the SPATIAL_GEOMETRY fields 1203a, 1205c, and 1211b
contains a spatial description for the respective polygon.
[0107] The tables that provide point data are the CAP_BUILDING
table 1201, the ADDR_INFO table 1213, the COLLO_INFO table 1207,
and the SWITCH_INFO table 1209. The CAP_BUILDING table 1201 stores
fields relating to the CAP buildings. These fields include the
following: a VNDR_CODE field 1201a for vendor code, which
identifies the vendor of the equipment; and a CAPABILITY field
1201b for indicating various attributes of the equipment within the
building (e.g., capacity). The CAP_BUILDING table 1201 has a
one-to-many relationship with the ADDR_INFO table 1213. The
ADDR_INFO -table 1213 has the following fields: STREET field 1213a,
CITY field 1213b, STATE field 1213c, ZIP field 1213d for the
5-digit ZIP code, a ZIP-4 field 1213e for the 4-digit extension, a
LATITUDE field 1213f, and a LONGITUDE field 1213g. The COLLO_INFO
table 1207 includes a COLLO_SWITCH_CLLI field 1207a for storing the
CLLI of the collocation switch, and a SWITCH_CAP field 1207b for
specifying the capabilities of the particular switch. The
SWITCH_INFO table 1209 has a SWITCH_CLLI_CODE field 1209a for
storing the CLLI of the switch and a LEC_ID field 1209b for storing
the identity of the LEC (Local Exchange Carrier) associated with
the particular switch. The COLLO_INFO table 1207 and the
SWITCH_INFO table 1209 are both related to the ADDR_INFO table 1213
in that the addresses of the collocation switch and the switch are
maintained.
[0108] The CUSTOMER_INFO table 1215 provides information on
existing and prospective customers of the telecommunication service
provider. The CUSTOMER_INFO table 1215 has the following fields: a
CUSTOMER_NAME field 1215a, a PHONE field 1215b, a REVENUE field
1215c for indicating the revenue that the customer generates for
the telecommunication service provider, an ADDRESS field 1215c, a
LATITUDE field 1215d, and a LONGITUDE field 1215e. Essentially, the
CUSTOMER_INFO table 1215 stores customer information that enable a
more targeted marketing effort.
[0109] Each of the above examples illustrate the flexibility of the
present invention. As shown above, any variety of detailed
information may be used in a system such as that described herein
for use in any industry for decisions such as, for example,
prospecting, sales and marketing, network planning, site or agent
location, product distribution, and service provisioning.
[0110] FIG. 13 illustrates a computer system 1301 upon which an
embodiment according to the present invention may be implemented.
Computer system 1301 includes a bus 1303 or other communication
mechanism for communicating information, and a processor 1305
coupled with bus 1303 for processing the information. Computer
system 1301 also includes a main memory 1307, such as a random
access memory (RAM) or other dynamic storage device, coupled to bus
1303 for storing information and instructions to be executed by
processor 1305. In addition, main memory 1307 may be used for
storing temporary variables or other intermediate information
during execution of instructions to be executed by processor 1305.
Computer system 1301 further includes a read only memory (ROM) 1309
or other static storage device coupled to bus 1303 for storing
static information and instructions for processor 1305. A storage
device 1311, such as a magnetic disk or optical disk, is provided
and coupled to bus 1303 for storing information and
instructions.
[0111] Computer system 1301 may be coupled via bus 1303 to a
display 1313, such as a cathode ray tube (CRT), for displaying
information to a computer user. An input device 1315, including
alphanumeric and other keys, is coupled to bus 1303 for
communicating information and command selections to processor 1305.
Another type of user input device is cursor control 1317, such as a
mouse, a trackball, or cursor direction keys for communicating
direction information and command selections to processor 1305 and
for controlling cursor movement on display 1313.
[0112] According to one embodiment, displaying the GUI screens 501
and 601 is provided by computer system 1301 in response to
processor 1305 executing one or more sequences of one or more
instructions contained in main memory 1307. Such instructions may
be read into main memory 1307 from another computer-readable
medium, such as storage device 1311. Execution of the sequences of
instructions contained in main memory 1307 causes processor 1305 to
perform the process steps described herein. One or more processors
in a multi-processing arrangement may also be employed to execute
the sequences of instructions contained in main memory 1307. In
alternative embodiments, hard-wired circuitry may be used in place
of or in combination with software instructions. Thus, embodiments
are not limited to any specific combination of hardware circuitry
and software.
[0113] Further, the data structure of FIG. 12 may reside on a
computer-readable medium. The term "computer-readable medium" as
used herein refers to any medium that participates in providing
instructions to processor 1305 for execution. Such a medium may
take many forms, including but not limited to, non-volatile media,
volatile media, and transmission media. Nonvolatile media includes,
for example, optical or magnetic disks, such as storage device
1311. Volatile media includes dynamic memory, such as main memory
1307. Transmission media includes coaxial cables, copper wire and
fiber optics, including the wires that comprise bus 1303.
Transmission media can also take the form of acoustic or light
waves, such as those generated during radio wave and infrared data
communications.
[0114] Common forms of computer-readable media include, for
example, a floppy disk, a flexible disk, hard disk, magnetic tape,
or any other magnetic medium, a CD-ROM, any other optical medium,
punch cards, paper tape, any other physical medium with patterns of
holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory
chip or cartridge, a carrier wave as described hereinafter, or any
other medium from which a computer can read.
[0115] Various forms of computer readable media may be involved in
carrying one or more sequences of one or more instructions to
processor 1305 for execution. For example, the instructions may
initially be carried on a magnetic disk of a remote computer. The
remote computer can load the instructions relating to displaying
the GUI screens 501 and 601 remotely into its dynamic memory and
send the instructions over a telephone line using a modem. A modem
local to computer system 1301 can receive the data on the telephone
line and use an infrared transmitter to convert the data to an
infrared signal. An infrared detector coupled to bus 1303 can
receive the data carried in the infrared signal and place the data
on bus 1303. Bus 1303 carries the data to main memory 1307, from
which processor 1305 retrieves and executes the instructions. The
instructions received by main memory 1307 may optionally be stored
on storage device 1311 either before or after execution by
processor 1305.
[0116] Computer system 1301 also includes a communication interface
1319 coupled to bus 1303. Communication interface 1319 provides a
two-way data communication coupling to a network link 1321 that is
connected to a local network 1323. For example, communication
interface 1319 may be a network interface card to attach to any
packet switched local area network (LAN). As another example,
communication interface 1319 may be an asymmetrical digital
subscriber line (ADSL) card, an integrated services digital network
(ISDN) card or a modem to provide a data communication connection
to a corresponding type of telephone line. Wireless links may also
be implemented. In any such implementation, communication interface
1319 sends and receives electrical, electromagnetic and/or optical
signals that carry digital data streams representing various types
of information.
[0117] Network link 1321 typically provides data communication
through one or more networks to other data devices. For example,
network link 1321 may provide a connection through local network
1323 to a host computer 1325 or to data equipment operated by a
service provider, which provides data communication services
through an IP (Internet Protocol) network 1327 (e.g., the
Internet). LAN 1323 and IP network 1327 both use electrical,
electromagnetic or optical signals that carry digital data streams.
The signals through the various networks and the signals on network
link 1321 and through communication interface 1319, which carry the
digital data to and from computer system 1301, are exemplary forms
of carrier waves transporting the information. Computer system 1301
can transmit notifications and receive data, including program
code, through the network(s), network link 1321 and communication
interface 1319.
[0118] The techniques described herein provide several advantages
over prior approaches to providing and processing spatial data
associated with telecommunication information. The APS 101 provides
the user the ability to select the type of spatial geography and
telecommunication information via a robust and user-friendly GUI.
The APS 101 returns a map that displays the selected information
for the geographic area, along with the accompanying textual data.
The user is able to run geographic queries in an ad-hoc mode to
answer a wide range of engineering and business problems.
[0119] Obviously, numerous modifications and variations of the
present invention are possible in light of the above teachings. It
is therefore to be understood that within the scope of the appended
claims, the invention may be practiced otherwise than as
specifically described herein.
* * * * *