(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2002/0122547 A1
`(43) Pub. Date:
`Sep. 5, 2002
`Hinchey et al.
`
`US 20020122547A1
`
`(54) METHOD AND APPARATUS FOR
`TELEPHONY ROUTE SELECTION
`
`(52) US. Cl. .................................... .. 379/221.01; 379/219
`
`(76) Inventors: Allan J. Hinchey, Kanata (CA);
`Douglas W. J. Zolmer, Nepean (CA)
`
`(57)
`
`ABSTRACT
`
`Correspondence Address:
`Neil Mothew
`Nortel Networks Limited, IPS Legal Department
`P.O. Box 832130
`Mail Stop 468/05/B10
`Richardson, TX 75083-2130 (US)
`
`(21) Appl. No.:
`
`09/746,103
`
`(22) Filed:
`
`Dec. 21, 2000
`
`Publication Classi?cation
`
`(51) Int. Cl? .................................................... .. H04M 7/00
`
`A method and apparatus for providing access device input
`format independent translations and route selection for tele
`phony calls. A call request is received, the call request
`comprising input information being for a telephony call. At
`least one call attributes is then determined from the input
`information and a routing policy request is transmitted to
`query a route database. Responsive to the routing policy
`request a routing policy response is received, the response
`comprising at least one routing parameter. The at least one
`routing parameter is used to in?uence call set up. Route
`selection is therefore not constrained by the service request
`input format.
`
`1234
`
`GATEWAY
`
`116/
`
`GATEWAY
`GW2
`
`L
`
`120
`
`13s
`
`PSTN
`COUNTRY
`CODE=1
`DC=613, 81'
`
`MANAGEMENT
`SERVER
`
`1+
`
`ROUTE
`SERVER
`
`f
`
`x / GAgla/VZAY
`
`I
`
`.140
`
`5678
`
`CALL SERVER
`
`_
`
`CS1
`
`SIP-T
`MESSAGING
`
`17
`
`CALL SERVER
`CS2
`J
`
`(128
`\ GATEWAY
`
`i
`6789
`
`144
`
`PSTN
`COUNTRY
`CODE=69
`NDC=B8
`
`16135915298
`
`4419138008
`
`PETITIONER APPLE INC. EX. 1006-1
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 1 0f 10
`
`US 2002/0122547 A1
`
`ow?
`
`mmnm
`
`W
`
`rum-39E
`
`moowmrmwvv
`
`wmwmvmmmrow
`
`PETITIONER APPLE INC. EX. 1006-2
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 2 0f 10
`
`US 2002/0122547 A1
`
`204
`
`f
`CC
`
`210
`
`f 1
`NDC
`
`SN
`
`Max (15 - n) digits
`+21g€+ <—Nationa| (significant) number————>
`:
`Max 15 digits
`>
`
`<——-——lnternationai public telecommunications number for networks—————>
`
`FIGURE 2
`
`PETITIONER APPLE INC. EX. 1006-3
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 3 0f 10
`
`US 2002/0122547 A1
`
`PETITIONER APPLE INC. EX. 1006-4
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 4 0f 10
`
`US 2002/0122547 A1
`
`v MMDOE
`
`mmwmug
`
`vmO
`
`PETITIONER APPLE INC. EX. 1006-5
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 5 0f 10
`
`US 2002/0122547 A1
`
`Nmo
`
`5min:
`
`I!
`Q I’ Q
`
`\ I,
`I
`
`amiwiki y i immn; i iw‘wioi w imftioi
`
`
`
`N8 .07 IHIH 50 BEN‘ 50
`mmk?n: I l mwmmun: I vmNFuQ
`
`it; i _ it; i _ 511%“
`
`
`anal N8 Q 5
`
`
`wEmuQ @mvmuQ mwmwun:
`
`<m MEDOE
`
`?miwimi i imtlmi i i / Eiliiiiili
`
`PETITIONER APPLE INC. EX. 1006-6
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 6 0f 10
`
`US 2002/0122547 A1
`
`/ . ,
`
`wwO
`
`nwmwnn:
`
`E3: M iii _ E3: _ 511:3
`
`gill ? filo‘ _ It?‘ ‘ ‘iii
`
`mwhmimiwmwPo
`
`
`
`
`
`E mwmmunz wmwmuQ mwmwun:
`
`
`
`
`
`mwwmmnuvg mvwmwnnug EH wmrmmwnnuQ
`
`
`
`
`
`mwO FwO PwO
`
`mm M139"
`
`PETITIONER APPLE INC. EX. 1006-7
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 7 0f 10
`
`US 2002/0122547 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Emvue
`
`Nwo
`
`UmmmDmv—u—
`
`
`
`
`
`
`
`
`m38%.@3anmvmmug.
`mmoSo50
`
`
`
`
`
`
`
`among..mvmmueENWQ
`Nmof.mVo50“wL50
`
`
`
`
`
`
`
`
`
`PETITIONER APPLE INC.
`
`EX. 1006-8
`
`mm:Kw»own:3
`
`
`
`
`
`
`
`
`
`
`
`
`mw.......Nr
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`KmNmmwm
`
`
`
`
`
`PETITIONER APPLE INC. EX. 1006-8
`
`
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 8 0f 10
`
`US 2002/0122547 A1
`
`INGRESS CALL SERVER RECIVES CALL SETUP INFORMATION FROM
`ORIGINATING ENDPOINT
`
`4’
`
`FIGURE 6
`
`604
`
`/ DOES SIGNALED INFORMATION \\
`CONFORM TO INPUT SCHEMA
`/> 7' No>
`ASSOCIATED WITH THE ENDPoINTy
`I
`
`K"
`612
`
`NO
`
`608
`
`YES
`
`i/HAS ENOUGH INFORMATION BEEN\\ )
`COLLECTED FOR ANALYSIS? ///
`616
`
`SIGNAL ENDPOINT THAT INPUT DOES NOT
`CONFORM TO INPUT SCHEMA
`
`Is ROUTE HOSTED
`BY LOCAL CALL
`SERVER?
`
`644
`
`USE SIP-T FOR
`INé'IIEEEVCEARLL
`No» I
`S GNALLING TO
`THE REMOTE
`HOST
`
`K
`648
`
`YES
`
`I
`
`SIGNALED INFoRIvIATIoN IS ANALYZED To
`DETERMINE THE CALL ATTRIBUTES (FULLY
`QUALIFIED ALIAS, SERVICE PROVIDERY CALL
`TYPE,..)
`
`II
`
`APPLY ROUTING POLICIES, QUERY THE ROUTE
`DATABASE WITH THE CALL ATI'RIBUTES.
`QUERY RESPONSE CONTAINS A LIST OF CALL
`SERVER HOST AND ROUTE ID PAIRS‘
`
`620
`
`624
`
`SIGNAL
`ENDPOINT THAT
`THERE ARE NO
`ROUTES
`AVAILABLE
`
`SELECT NEXT ROUTE FROM LIST
`ROUTE SELECTED?
`
`YES
`
`EGRESS CALL
`SERVER CHECKS IF
`ROUTE AVAILABLE?
`
`NO
`
`652
`
`I
`I
`
`V
`
`YES
`
`APPLY SIGNALING POLICIES,
`K- FORMAT SIGNALING INFO FOR
`TERMINATING ROUTE
`
`656
`
`II
`
`I
`
`SEND CALL SETUP
`K INFORMATION TO TERMINATING
`ENDPOINT
`
`660
`
`I
`I
`I
`
`SIGNAL
`ENDPOINT
`THAT THE I<—N0
`CALL FAILED I
`‘ SCREENING I
`
`PF’LY SCREENING POLICIES T
`CALL ATTRIBUTES. IS THE CALL
`REQUEST AUTHORIZED‘?
`
`ESTABLISH MEDIA PATH
`
`664
`
`840
`
`PETITIONER APPLE INC. EX. 1006-9
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 9 0f 10
`
`US 2002/0122547 A1
`
`FIGURE 7
`
`711
`
`718 I
`F3
`
`7,12
`/
`
`709
`
`708W
`
`730 M7.
`
`713
`
`FIGURE 8
`
`804
`
`70°
`
`/
`
`,1 734
`
`‘"718
`
`808
`
`PETITIONER APPLE INC. EX. 1006-10
`
`

`

`Patent Application Publication
`
`Sep. 5, 2002 Sheet 10 0f 10
`
`US 2002/0122547 A1
`
`900
`
`{/T
`
`7
`\
`
`T\
`904
`
`<—> PROCESSOR
`
`\
`908
`
`\
`912
`
`OPERATING
`<—-—-——> MEMORY
`
`m
`D
`m
`
`920
`
`STORAGE
`DEVICE
`
`REMOVABLE
`STORAGE
`DEVICE
`
`.
`
`924
`
`-<———>
`
`K‘
`916
`
`REMOVABLE
`STORAGE
`UNIT
`
`1
`1
`
`928
`
`K /
`
`FIGURE 9
`
`PETITIONER APPLE INC. EX. 1006-11
`
`

`

`US 2002/0122547 A1
`
`Sep. 5, 2002
`
`METHOD AND APPARATUS FOR TELEPHONY
`ROUTE SELECTION
`
`TECHNICAL FIELD
`[0001] The invention relates to translating telephony calls.
`More particularly, this invention relates to route selection for
`telephony calls according to call attributes derived from a
`service request.
`
`BACKGROUND
`
`[0002] In a prior art circuit sWitched telecommunication
`switching system comprising a plurality of sWitching nodes,
`each sWitching node requires prede?ned knoWledge of the
`numbering plan of the telecommunication sWitching system
`and also of hoW the sWitching nodes are interconnected. An
`example of such a system is the public telephone netWork of
`the United States. Within the United States, the telephone
`numbers Were grouped in terms of area codes; and Within
`each area code, the telephone numbers Were further grouped
`by the ?rst three digits of the telephone number. This
`hierarchy of telephone numbers (also referred to as the
`numbering plan hierarchy) Was modeled after the hierarchy
`of sWitching nodes, e.g. central and tandem of?ces. Within
`each central of?ce, the routes to be utiliZed to reach area
`codes or other groups of telephone numbers Was prede?ned
`at initialiZation or during system operation by the actions of
`a system administrator in con?guring a translations data
`base. “Translations” is a term used to refer to the process of
`interpreting call request information (dialed digits for
`example) received from an end user device or incoming
`trunk, determining the requested call type and associated
`called destination, and resolving this information to an
`internal reference Which can be used by call processing to
`terminate calls to the appropriate service, end user device or
`outgoing trunk route.
`
`[0003] Translations databases in circuit-sWitched tele
`phony netWorks typically had been manually con?gured
`through static associations from originating-endpoints to
`routes based on a service request comprising dialed digits.
`The static associations had generated complex data models
`having a directed graph from each possible originating
`endpoint. This model has been in the form of a tree structure
`indexed by dialed telephony digits associated With each
`feasible route.
`[0004] This complex data model is manually adminis
`tered. With manual administration, a high cost is associated
`With maintaining and updating the data model. Furthermore,
`due to the human intervention required to recon?gure the
`translations and sWitching equipment When setting up or
`making any changes to netWork infrastructure, the update
`process becomes increasingly time consuming and error
`prone as the model siZe and complexity increases.
`[0005] Emerging packet-based telephony communications
`technology, such as Voice over Internet Protocol (“VoIP”)
`does not limit the service request input format to dialed
`digits as found on a telephony keypad. Furthermore, Whilst
`the most signi?cant digits of the dialed number had previ
`ously been associated With a predetermined central of?ce,
`this is no longer necessary since the netWork architecture is
`not hierarchical as With circuit-sWitched netWorks.
`
`coupled to the netWork. With the redundancy of hierarchic
`and geographic restrictions on the allocation of aliases,
`increased ?exibility in allocating aliases alloWs a more
`distributed usage of aliases. HoWever, the trade-off With this
`increased ?exibility is that the management and provision of
`the translations data to translations databases becomes
`increasingly complex and error-prone.
`[0007] It Would be desirable to provide a method and
`apparatus for translating a call to a called alias by deriving
`call attributes from a service request independent of the
`access device and request input format; and use the call
`attributes derived from the service request to translate the
`call to a destination or service associated With the called
`alias.
`
`SUMMARY
`
`[0008] Provided is a method and apparatus for providing
`access device input format independent translations and
`route selection for telephony calls. A translations method
`and apparatus consistent With the present invention provides
`route selection of telephony calls unconstrained by access
`device input format.
`
`[0009] An important aspect of translations in the tele
`phony domain is the interpretation of an alias, the alias being
`associated With an endpoint on the communications net
`Work, and the selection of a route connecting a calling-party
`to a called-party’s endpoint. As used here, an “alias” may be
`a telephony number, Web page URL (Universal Resource
`Locator), e-mail address, common name, or any other
`unique identi?er associated With the called party. The “alias”
`can use any combination of alphanumeric characters.
`
`[0010] A call request is received, the call request com
`prising input information being for a telephony call. At least
`one call attribute is then determined from the input infor
`mation and a routing policy request is transmitted to query
`a route database. Responsive to the routing policy request a
`routing policy response is received, the response comprising
`at least one routing parameter. The at least one routing
`parameter is used to in?uence call set up.
`
`[0011] In some embodiments, a call server maintains a
`route database of the aliases associated With its supported
`endpoints and services. The call attributes determine the
`routing policy used to query the translations database of the
`ingress call server to select appropriate routes satisfying the
`call attributes. In some embodiments, the database may
`provide a preferred routing based on the call attributes and
`routing policy being applied.
`[0012] In some embodiments, if the query to the ingress
`call server’s translations database does not yield a routing
`result, then a second query may be performed to a route
`database to determine the appropriate call server that sup
`ports the called endpoint, service or trunk endpoint that can
`route toWards the called destination. In a netWork With a
`plurality of call servers, each call server has responsibility to
`host pre-de?ned endpoints (terminals and/or trunks) and
`services. Such call server to endpoint and service associa
`tions may be statically or dynamically provisioned. Signal
`ing betWeen call servers may transfer the call handling from
`an ingress call server to an egress call server.
`
`[0006] As the demand for telephony services groWs, so
`does the requirement to allocate aliases for endpoints
`
`[0013] In some embodiments, a netWork management
`system (NMS) may be responsible for con?guring each call
`
`PETITIONER APPLE INC. EX. 1006-12
`
`

`

`US 2002/0122547 A1
`
`Sep. 5, 2002
`
`server in the network With data for each endpoint and service
`hosted by the call server, including associated translations
`data. In some embodiments, a netWork translations route
`database is provided to support inter call server translations.
`If a translations request cannot be resolved Within the local
`translations database of the ingress call server, a query is
`made to the netWork translations route database. The net
`Work translations route database is responsible for returning
`a reference to the call server hosting the called endpoint,
`service or trunk endpoint that can route toWards the called
`destination.
`
`[0014] An advantage of the invention is that route selec
`tion is made using call attributes rather than dialed digits,
`thus route selection is unconstrained by the request format of
`the access device. In communications netWorks, and more
`particularly data netWorks, terminals are not restricted to a
`tWelve button keypad used to dial digits, but other more
`elaborate forms of input may be used to express a service
`request and called party alias/address information, for
`example, an alphanumeric address, an email address or a
`URL.
`
`[0015] A further advantage of this invention is that it
`provides the ability to analyZe any form of user input
`representing the service request and interpret it in terms of
`generic call attributes to select an appropriate route. The call
`attributes and translations route selection policies can there
`fore be reused in a manner independent of the input alias.
`
`[0016] Further features of the invention, as Well as the
`structure and operation of various embodiments of the
`invention, are described in detail beloW With reference to the
`accompanying draWings. The draWing in Which an element
`?rst appears is indicated by the digit(s) to the left of the tWo
`rightmost digits in the corresponding reference number.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0017] The invention Will best be understood by reference
`to the folloWing detailed description When read in conjunc
`tion With the accompanied draWings, Wherein:
`
`[0018] FIG. 1 is a block diagram of an exemplary IP
`netWork topology;
`
`[0019] FIG. 2 is a diagram of international public tele
`communications number structure for geographic areas
`under the ITU-T E. 164 Recommendation;
`
`[0020] FIG. 3 is a diagram of a netWork translations
`subsystem to resolve called alias information to one or more
`terminating endpoints associated With the alias;
`[0021]
`[0022] FIGS. 5A, 5B and 5C is a flow chart for mapping
`called numbers according to a numbering plan and number
`range;
`
`FIG. 4 is a diagram of a number route database;
`
`[0023] FIG. 6 is a ?oWchart for a call server handling a
`call;
`[0024] FIG. 7 is a front vieW of a board carrier;
`
`[0025] FIG. 8 is a rear vieW of a board carrier;
`
`DETAILED DESCRIPTION
`
`[0027] In the folloWing description, numerous details are
`set forth to provide an understanding of the present inven
`tion. HoWever, it Will be understood by those skilled in the
`art that the present invention may be practiced Without these
`details and that numerous variations or modi?cations from
`the described embodiments may be possible. For example,
`although the description refers to telephony communications
`over data networks, certain aspects of the methods and
`apparatus described may be advantageously used With other
`types of communications systems, such as those used on
`circuit sWitched netWorks.
`
`[0028] FIG. 1 is a block diagram of an Internet Protocol
`(“IP”) netWork topology. The communications netWork 102
`is coupled to associated endpoints 116, 120, 124, 128, 148
`and 152. As shoWn, the endpoints can be provided as
`communications gateWays 116, 120, 124 and 128, and With
`terminals 148 and 152.
`
`[0029] It should be appreciated that many more endpoints
`may be connected to communications netWork 102; and
`these are shoWn merely as examples.
`
`[0030] Communications netWork 102 in this example may
`be a packet-based or message-based netWork. In one
`embodiment, the communications netWork 102 communi
`cates according to the Internet Protocol (IP), Which is one of
`the protocols on Which the Internet is based, as described in
`Internet Engineering Task Force (IETF) Request for Com
`ment 791, entitled “Internet Protocol,” dated September
`1981. Communications netWork 102 provides quality of
`service to voice calls sufficient to provide adequate band
`Width and loW latency.
`
`[0031] A suitable communications netWork 102 has a
`single netWork or link, Which can be coupled through
`gateWays, routers, and the like. It should be appreciated by
`those skilled in the art that further complex architectures
`could be implemented With multiple netWorks or links.
`Further, it should be noted that communications netWork
`102 could have geographically dispersed linked-data net
`Works in business environments. Examples of such data
`netWorks are Local Area NetWorks (LANs).
`
`[0032] As shoWn in FIG. 1, communications netWorks
`132, 136, 140 and 144 are coupled to communications
`netWork 102 via communications gateWays 116, 120, 124
`and 128 respectively, to provide the communications inter
`face betWeen the netWorks.
`
`[0033] Examples of suitable communications netWorks
`132, 136, 140 and 144 are a public sWitch telephone netWork
`(“PSTN”), a private branch exchange (“PBX”), a local area
`netWork (“LAN”), a metropolitan area netWork (“MAN”), a
`Wide-area netWork (“WAN”), a private netWork such as an
`Intranet, and public netWork such as the Internet. The
`underlying unifying factor of these netWorks is the ability to
`share data information under a common communications
`protocol, such as TCP/IP. Additional communications pro
`tocols can be implemented and data may be communicated
`betWeen communications protocols using adequate conver
`sion techniques.
`
`[0026] FIG. 9 is a computer system programmed for
`executing a computer program according to various embodi
`ments of the invention.
`
`[0034] Terminals 148 and 152 are capable of performing
`voice and other multi-media communications over a packet
`based or message-based data netWork. As used herein, a
`
`PETITIONER APPLE INC. EX. 1006-13
`
`

`

`US 2002/0122547 A1
`
`Sep. 5, 2002
`
`terminal may be a computer-based system having speech
`capability, or may be telephony units having interfaces to the
`communications network. Accordingly, terminals 148 and
`152 may be Internet Protocol (IP) telephones, each With an
`associated IP address; the IP address of each terminal having
`an associated phone number according to the E164 stan
`dard. The aforesaid IP address may be dynamically or
`statically allocated. Dynamic allocation of the IP address can
`be performed using Dynamic Host Con?guration Protocol;
`an existing IETF protocol that alloWs a server to assign IP
`addresses dynamically to endpoints as they connect to the
`netWork.
`
`[0035] As shoWn in FIG. 1, call servers 104 and 108 are
`coupled to the communications netWork 102. The call serv
`ers act to manage telephony communications (for eXample,
`call setup, processing, and termination) betWeen or among
`the endpoints. A suitable call server is available under the
`SuccessionTM Internet Product Portfolio from Nortel Net
`Works, Ltd., of Brampton, Ontario, Canada. A call server
`builds a composite vieW of the translations data for all its
`endpoints in a local translations database. Afunction that the
`call servers provide is in the called alias translation to alloW
`the call to progress throughout the netWork to its destination
`endpoint(s). As used here, an “alias” may be a telephony
`number, Web page URL (Universal Resource Locator),
`e-mail address, common name, or any other unique identi?er
`associated With the called party. The “alias” can use any
`combination of alphanumeric characters.
`
`[0036] Aroute database 114, accessible by the call servers
`104 and 108 through the communications netWork 102,
`provides support to inter-call server translations. Thus, if a
`called address translation request cannot be resolved Within
`the ingress call server local translations database, a query
`may be made to route database 114. The netWork transla
`tions database in the route database 114 returns a reference
`to the call server hosting the terminating endpoint. The
`ingress call server may then use Session Initiation Protocol
`for Telephony (SIP-T,) messaging or an equivalent to for
`Ward the call signaling to the terminating call server. SIP-T
`is an emerging ITU messaging protocol standard for com
`municating betWeen call servers. The terminating call server
`may then use its local translations database to locate the
`terminating endpoint and complete the call.
`
`[0037] Additionally, management server 112 may be
`coupled to the communications netWork 102 for the man
`agement of selected resources coupled to communications
`netWork 102. Management server 112 may send the con
`?guration data for each call server’s hosted endpoints to the
`respective call server. From this con?guration data, the
`respective call server may build run-time con?guration data
`and a local translations database for the hosted endpoints.
`Endpoint con?guration data may be provisioned through a
`management server and stored in a route database.
`
`[0038] Although only one route database 114, manage
`ment server 112 is illustrated, it should be appreciated that
`multiple route databases, management servers and call serv
`ers can be coupled to the communications netWork, as Well
`as additional netWork resources, suf?cient to handle the call
`traf?c. In a multiple server con?guration, the multiple call
`servers may be responsible for managing call requests from
`a group of terminals, and the route database may be respon
`sible for serving a predetermined set of call servers. A call
`
`server, route database, and management server may be
`implemented on separate platforms or in a platform includ
`ing some or all of the aforementioned components.
`
`[0039] FIG. 2 is a diagram of international public tele
`communications number structure for geographic areas
`under the ITU-T E. 164 Recommendation, titled “The inter
`national public telecommunication numbering plan”, dated
`May 1997, Which is hereby incorporated by reference. This
`recommendation details the components of the numbering
`structure and the digit analysis required to successfully route
`calls in international public telecommunication netWorks.
`
`[0040] The international public telecommunication num
`ber for geographic areas is composed of a variable number
`of decimal digits arranged in speci?c code ?elds. The
`international public telecommunication number code ?elds
`are the Country Code (CC) 204 and the National (Signi?
`cant) Number, 210. The National (Signi?cant) Number 210
`may be (15 -n) characters in length, Where n is the number of
`digits in the country code (1 to 3 digits).
`
`[0041] As used in the E164 description, a public number
`is a string of decimal digits that uniquely indicates the public
`netWork termination point. The number contains the infor
`mation necessary to route the call over a public netWork to
`this termination point; and this number is herein forth
`referred to as a “fully quali?ed” number. A public number
`can be in a format determined nationally or in an interna
`tional format. The international format is knoWn as the
`International Public Telecommunication Number, Which
`includes the country code and subsequent digits, but not the
`international pre?X.
`
`[0042] As used also in the E164 description, a numbering
`plan speci?es the format and structure of the numbers used
`Within that plan. It typically comprises decimal digits seg
`mented into groups in order to identify speci?c elements
`used for identi?cation (or aliasing), translations and charg
`ing capabilities, e.g. Within E.164 to identify countries,
`national destinations and subscribers. A numbering plan
`does not include pre?xes, suf?Xes, and additional informa
`tion required to complete a call (these are components of dial
`plans). A national numbering plan is a national implemen
`tation of the E164 numbering plan.
`
`[0043] Such an eXample of a national numbering plan is
`the North American Numbering Plan (NAN P). According to
`the NANP, the termination point has a number in the
`NXX-NXX-XXXX format, Where N represents a digit from
`2-9 and X represents a digit from 0-9. The ?rst group of
`three digits indicates the area code or Number Plan Area
`(NPA) of the subscriber, the second group of three digits and
`the last four digits comprise the Station Number and indicate
`the address of the subscriber Within the NPA. Digits 0 and
`1 are of course not available as the ?rst digit (N) alloWing
`them to be used as dial plan pre?Xes for operator and long
`distance services.
`
`[0044] In an enterprise telecommunications system, a pri
`vate numbering plan is used. Aprivate number is a string of
`decimal digits that uniquely indicates the private netWork
`termination point. Similar to a public number, the number
`contains the information necessary to route the call over a
`enterprise netWork to this termination point; and this number
`is herein forth referred to as a “fully quali?ed” number. A
`private numbering plan is in a format determined by the
`
`PETITIONER APPLE INC. EX. 1006-14
`
`

`

`US 2002/0122547 A1
`
`Sep. 5, 2002
`
`enterprise. Like a public numbering plan, a private number
`ing plan does not include pre?xes, suf?xes, and additional
`information required to complete a call (these are compo
`nents of private dial plans).
`
`[0045] Dial plans de?ne the method by Which number
`plans are used in terms of combinations of decimal digits
`dialed to place a call. Dial plans de?ne the meaning of pre?x
`and suf?x digits, abbreviated called number formats and any
`other information, supplemental to the number plan,
`required to complete a call.
`
`[0046] Public dial plans are de?ned at the national or
`regional level. Such an example of a dial plan is the one
`typically used in most areas of North America Which de?nes
`1 as pre?x for long distance calls, 0 as a pre?x for operator
`calls and alloWs for local calls to be dialed With a 7 digit
`abbreviated format of the 10 digit national number.
`
`[0047] In an enterprise telecommunications system, pri
`vate dial plans de?ne the combinations of digits that may be
`used to provide the subscriber With different enterprise
`telecommunications services. These dial plans may service
`predetermined combinations of dialed digits and translate
`them to the various different telecommunications services.
`For example, a user may dial the digit ‘9’ as a pre?x to a
`direct-outWard-dialed (DOD) number to make a call from
`the enterprise netWork to a subscriber in the Public SWitched
`Telephone Network (PSTN); and a user may dial the digit ‘6’
`
`is a private communications system
`“enterprise netWor
`linking up enterprise communications equipment and end
`points. Examples of private and public telecommunications
`call types are listed in Table 1 beloW. Examples of dialing
`plan digit patterns for each of the enterprise call types are
`listed in Table 2 beloW, Whilst examples of dialing plan digit
`patterns for DOD public call types are listed in Table 3
`beloW. It should be apparent to a person of ordinary skill in
`the art that further examples may be added to these.
`
`[0048] Call types are represented in Table 1 beloW.
`
`TABLE 1
`
`Call Type Reference
`
`Call Type
`
`AA
`DA
`DD
`DOD
`ES
`INTERiSITE
`INTRALSITE
`OA
`VSC
`
`Attendant Assisted
`Directory Assistance
`Direct Dial
`Direct OutWard Dial
`Emergency Service
`Inter-Site
`Intra-Site
`Operator Assisted
`Vertical Service Code
`
`[0049] Enterprise (Private) Dialing Plans are represented
`in TABLE 2 beloW.
`
`TABLE 2
`
`Case Call Type
`Number Description
`
`Dialing Plan Schema
`
`Private Call
`Type
`
`Example of
`Plan
`
`1
`2
`
`3
`
`4
`
`5
`
`6
`
`Intra-site call
`Inter-site call
`
`EXTN (extension)
`INTERSH‘ELPREFIX +
`LOCATIONLCODE + EXTN
`ATTENDANTLCODE
`
`INTRAiSITE 54000
`INTERLSITE 6 + 395 +
`54000
`0
`
`AA
`
`EMERGENCYLSERVICELCODE ES
`
`Enterprise
`Attendant Call
`Enterprise
`Emergency
`Call
`DODLPREFIX +
`Direct-
`outward-dialed PUBLICLDIALINGLPATTERN
`public call
`Vertical
`Service Code
`call
`
`VERTICALiSERVICEiCODE
`
`911
`
`9 + 765-4000
`9 + 1 + 613 +
`765 + 4000
`*72, *1172
`*831, *11831
`
`DOD
`
`VSC
`
`to pre?x a private enterprise number to make a call to
`another party on the enterprise netWork. As used here, an
`
`[0050] Direct OutWard Dialed access to a Public Dialing
`Plan is represented in TABLE 3 beloW.
`
`TABLE 3
`
`Case Call Type
`Number Description
`
`Dialing Plan Schema
`
`7
`
`8
`
`9
`
`10
`
`Direct- outward-dialed DODLPREFIX + SN
`local call
`Direct-outward-dialed DODLPREFIX +
`national call
`NATLLLDLPREFIX + NDC + SN
`Direct-outward-dialed DODLPREFIX +
`international call
`INTLiLDiPREFIX + CC +
`NDC + SN
`Direct-outward-dialed DODLPREFIX +
`operator assisted
`LOCALLOALPREFIX +
`national call
`NDC + SN
`
`Public
`Call Type Example (North
`Attribute
`America)
`
`DD
`
`9 + 745-1576
`
`DD
`
`DD
`
`OA
`
`9 + 1 + 613 + 745
`1576
`9 + 011 + 44 + 207
`+ 225-0603
`
`9 + 0 + 613 + 745
`1576
`
`PETITIONER APPLE INC. EX. 1006-15
`
`

`

`US 2002/0122547 A1
`
`Sep. 5, 2002
`
`TABLE 3-continued
`
`Case Call Type
`Number Description
`
`Dialing Plan Schema
`
`11
`
`12
`
`13
`
`14
`
`15
`
`Direct-outward-dialed DODLPREFIX +
`operator assisted
`INTLiOAiPREFIX + CC + NDC +
`international call
`SN
`Direct-outward-dialed DODLPREFIX +
`attendant call
`LOCALiOAiCODE
`Direct-outward-dialed DODLPREFIX +
`emergency call
`EMERGENCYLSERVICELCODE
`Direct-outward-dialed DODiPREFIX +
`directory assistance
`DIRECTORYLASSISTANCEL
`call
`CODE
`Direct-outward-dialed DODiPREFIX +
`national service call
`NAT IONALLSERVICELCODE
`
`Public
`Call Type Example (North
`Attribute
`America)
`
`OA
`
`9 + 01 + 44 + 207 +
`225-0603
`
`OA
`
`9 + O
`
`ES
`
`9 + 911
`
`DA
`
`9 + 411
`
`DD
`
`9 + 1 +
`800/888/877/866/90
`
`[0051] Call attributes may be derived by analysis of the
`dialed digits according to the dial plan in effect. One or more
`call attributes may be set as a result of the analysis. Table 4
`below lists the call attributes and their possible values.
`[0052] Call Attributes are represented in TABLE 4 below.
`
`TABLE 4
`
`Call Attribute
`
`Value
`
`PRIVATE CALL TYPE
`
`NoNE, DOD, AA, Es, rNTRALsrTE,
`INTERLsITE, vsc
`NONE, DD, oA, DA, Es, vsc
`NoNE, PREF, cAc
`PRIVATE, PUBLIC
`
`PUBLIC CALL TYPE
`EQUAL ACCESS TYPE
`ORIGINAT'ING
`ENVIRONMENT
`PUBLIC CALL REACH UNKNOWN, NATL, INTL
`LOCAL CALL
`BOOL
`INDICATOR
`PUBLIC LATA TYPE
`
`PUBLIC CARRIER ID
`NATIONAL SERVICE
`TYPE CODE
`FULLY QUALIFIED
`ALIAS
`
`NOTAPPLICABLE, INTRAiLATA
`INTERiLATA
`VALUE (range: 0 to 9999)
`NONE, FREEPHONE, PAYiPERiCALL
`
`STRING
`Example for telephony numbers:
`Numbering Plan ID: E.164 or private ID
`Number: fully quali?ed E.164 or private
`number
`
`[0053] A high-level block diagram of the network trans
`lations subsystem to resolve called alias information to one
`or more terminating endpoints associated with the alias is
`provided in FIG. 3. Arrows between the blocks indicate the
`general ?ow of execution. The functions provided by the
`translations subsystem 300 are organized into subcompo
`nents. A subcomponent function may be implemented using
`software executing on a computer platform or using logic
`circuitry deploying microcontroller or microcomputer cir
`cuitry. As used here, a “microcontroller” is generally a
`one-chip integrated system meant to be embedded in a single
`application; so it is likely to include all the peripheral
`features-program and data memory, ports, and related sub
`systems-needed for the computer aspect of the application.
`Also as used here, “microcomputer” circuitry drives a gen
`eral-purpose computer whose ultimate application is not
`known to the system designers.
`[0054] Network translations subsystem 300 may be hosted
`in a network resource such as call servers 104 and 108 of
`
`FIG. 1. The network translations subsystem 300 comprises
`subcomponents 308, 312, 316, 320, 324 and 332, which
`implement translations analysis and route selection logic and
`subcomponent 326, the route database, which contains the
`network routing data. The route dat