WO2002005520A2

WO2002005520A2 - System and method for creating usage and detail records, and allowing access to a communication node

Info

Publication number: WO2002005520A2
Application number: PCT/US2001/021638
Authority: WO
Inventors: Albal Nandakishore; Janusz Hyziak
Original assignee: Motorola Inc.
Priority date: 2000-07-11
Filing date: 2001-07-10
Publication date: 2002-01-17
Also published as: WO2002005520A3; AU7193901A

Abstract

A method of creating a usage record is provided. An input signal is received (500). A usage record is created in response to the received input signal. An event jacket is created (510). A command to send a message is received (520). A confirmation signal is received after the message has been sent (530). Finally, a leg jacket is created (540).

Description

SYSTEM AND METHOD FOR CREATING USAGE AND DETAIL RECORDS, AND ALLOWING ACCESS TO A COMMUNICATION NODE

FIELD OF THE INVENTION

The present invention generally relates to communication systems, and, more particularly, to methods and systems for creating email usage records, page usage records, transaction usage records, call usage records, and call detail records.

BACKGROUND OF THE INVENTION

In today's communication environment, telephone calls are usually placed through a telecommunication network. When a telecommunication network detects a telephone call, a call detail record, which tracks the usage of services offered by the telecommunication carrier and records various details associated with the call, is created. Typically, the call detail record includes, for example, such items as the called number, the calling number, the date, the time, the duration of the call and other information relating to the call.

The call detail record may be stored in accordance with any one of a number of formats, such as, the Data Message Handling (DMH) standard. The DMH standard generally includes five data-containing jackets: an activity jacket, a call jacket, a segment jacket, an event jacket and a leg jacket. Activity jackets contain radio resource usage data, which may include, for example, the frequency on which a wireless device is operating. Call jackets contain a record of the type of services used during a call. Segment jackets contain a record of communication network facility usage data, including, for example, trunk group usage and switch identifier usage. Event jackets contain a record of the time and date the end user accessed the communication network, as well as an authorization identifier. Finally, leg jackets contain a record concerning the routing of the call.

However, the DMH standard typically records data concerning voice calls, and may not address other telephone services, including, for example, email services, paging services, end user-location detection services, content delivery services, and the services from other types of network elements. Further, call detail records are created after the call is terminated, and the DMH standard currently does not provide for the authentication of an end user, allowing the end user access to the communication system in a manner consistent with the account provisions of the end user.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of a communication system in accordance with the present invention;

FIG.2A is a depiction of an email usage record in accordance with the present invention;

FIG.2B is a depiction of a page usage record in accordance with the present invention;

FIG. 2C is a depiction of a transaction usage record in accordance with the present invention;

FIG. 2D is a depiction of a call usage record in accordance with the present invention;

FIG. 2E is a depiction of a call detail record in accordance with the present invention;

FIG. 3A is a flowchart of an embodiment of an email usage record, page usage record, transaction usage record, call usage record or call detail record creation routine in accordance with the present invention;

FIG. 3B is a flowchart of an embodiment of an authentication and authorization routine in accordance with the present invention;

FIG. 4 is a depiction of a response page usage record in accordance with the present invention; and

FIG. 5 is an exemplary block diagram of another embodiment of a communication system in accordance with the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a block diagram that illustrates an embodiment of a communication system 10. The communication system 10 generally includes one or more network access devices or communication devices 12, 22, communication networks 14, 18 and a communication node 16. As further described below, the communication system 10 can provide various services and capabilities to cellular end users, wire-line telephone end users, paging end users, satellite end users, mobile or portable telephone end users, trunked end users, computer network end users (e.g., Internet or Intranet end users), wireless data end users, branch office end users and the like. The communication system 10 can also create an email record, a page record, a transaction record and/or a call record for recording the details of an e-mail transaction, a page transaction, a particular transaction and or a call, as further described below.

The communication devices 12, 22 of the communication system 10 can be utilized by end users 20, 32 to access and/or connect with the communication node 16. The communication devices 12, 22 can include, but are not limited to, wireline telephones, mobile telephones, paging units, radio units, wireless data devices, Web telephones, portable or wireless telephones, personal information managers (PIMs), personal digital assistants (PDAs), personal computers (PCs), network televisions (TVs), Internet TVs, Internet telephones, portable wireless devices (i.e., two-way pagers), security systems (both mobile and premises-based), workstations or any other suitable communication devices. The communication devices 12, 22 communicate with the communication

node 16 via the communication networks 14, 18. The communication networks 14, 18 can interface with the communication devices 12, 22 through wireline or wireless networks or systems (i.e., telephone or televisions systems, Integrated Services Digital

Network (ISDN) systems, coaxial lines, computer networks, digital end user lines, private networks, wireless local loop systems, etc.).

The communication networks 14, 18 of the communication system 10 can include, but are not limited to, intranets, extranets, the Internet, a Local Area Network (LAN), a telephone network, (e.g., a Public Switched Telephone Network (PSTN), private telephone networks, etc.), a cellular network, satellite networks, a personal communication system, a TV network (e.g., a cable TV system), local, regional, national or global paging networks, an email system, a wireless data network (e.g., satellite data or local wireless data networks), a wireless LAN, a wireless local

loop/distribution system (e.g., LMDS, MMDS or Code Division Multiple Access (CDMA) based system), a Voice Over Internet Protocol (VOIP) network, or any other

suitable network. The communication networks 14, 18 can also include a wide area network (WAN), such as, for example, the internet, the World Wide Web (WWW) or any other similar on-line service. It will be recognized that the communication

networks 14, 18 may have portions in common, may comprise two separate networks, or may be the same network.

The communication node 16 of the communication system 10 can include, but is not limited to, an interactive voice response node, a server computer, the MLXTM platform and the Myosphere™ Service provided by Motorola, Inc. of Schaumburg, IL

(as further described with reference to FIG. 4), or other suitable system. It will be recognized that the communication node 16 may be integrated within or may be remote from the communication networks 14, 18.

The communication node 16 records and maintains a call detail record, as well as an email, page, transaction and/or call usage record. The email, page and/or transaction usage record stores information about each email, page and/or particular transaction performed by the end user within the communication system 10. The call usage record and the call detail record provide an accounting of each communication transaction. For example, each time the end user sends a message or accesses the communication node 16, the communication node 16 will record an email usage, page usage, transaction usage, call usage and/or call detail record. Preferably, each email usage, page usage, transaction usage, call usage and/or call detail record is stored within memory (such as a memory bank) or a database, which may be located integral with or remote from the communication node 16.

The communication node 16 may also allow, and conversely limit, the access of an end user 20 to the communication node 16. This ensures that both the end user 20 and the communication device 12 are accessing the communication node 16 in a manner consistent with the end user's account. The present invention can preferably allow access to the communication node prior to the commencement of action by the end user. FIG.2A depicts an email usage record 100A. The email usage record 100A is preferably comprised of a set of data-containing jackets, with each jacket including a number of records. Each record may include a number of sub-records, as further described below. The email usage record 100A may be compatible with any suitable standard, such as the DMH standard.

The email usage record 100A preferably includes an event jacket 101 and an email leg jacket 109A. The event jacket 101 and email leg jacket 109A may be compatible with the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable standard.

The event jacket 101 and the email leg jacket 109A may include mandatory and/or optional parameters and fields depending on the operation of the communication system 10. The event jacket 101 preferably contains various information relating to the identity of the end user and the communication device, the time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. The email leg jacket 109A preferably includes the details of email transactions made by an end user, such as a destination email address, a source email address, the email size, attachments, the email provider, the email urgency, the delivery schedule, the email classification, the reoccurrence of the email, recipients, the creation time and date and any delivery receipts. Thus, the email usage record 100A preferably contains an event jacket 101, and may contain, dependent upon the number of email transactions, one or more email leg jackets 109A. As shown in FIG. 2A, the event jacket 101 preferably includes an end user identification record 102, an end user number identification record 104, an event jacket creation time record 106 and an event jacket creation date record 108. The end user identification record 102 may be a record identifying the sender of the input signal, such as the end user. The end user identification record 102 may also indicate whether the end user is authorized to use the features and services of the communication system (i.e., whether the end user is a subscriber to the communication system). Preferably, the communication node compares the input signal with stored data concerning the end user. For example, the end user may be required to input a Personal Identification Number, a calling line identifier, a password or Internet "cookies" or tokens.

The end user device identification record 104 maintains and authenticates the number of the communication device from which the end user is calling. Preferably, the communication node performs a comparison between the number received in the input signal and the stored end user identification record. Upon finding a match, the communication node continues to create the email usage record 100A. The event jacket creation time record 106 is preferably a record of the time at which the input signal was received at the communication node (which also coincides with the time of the creation of an email usage record 100A).

The event jacket creation date record 108 preferably corresponds to the calendar date on which the input signal was received by the communication node (also coinciding with the creation of the email usage record 100A). The communication node, when accessing an internal electronic clock, may create the event jacket creation time and date records 106, 108.

The email leg jacket 109A of the email usage record 100A, which may include a link to the event jacket, preferably includes a number of records, such as, for example, an email leg jacket identifier record 110A, a destination email address record 112A, a source email address record 114A, an email size record 116A, an attachment record 118A, an email provider record 120A, an email urgency record 122A, a delivery schedule record 124A, an email classification record 126A, a reoccurrence record 128A, a recipient record 130A, an email leg jacket creation time record 132A, an email leg jacket creation date record 134A, a delivery receipt record 136A and a bill-to record 138A. Preferably, the email leg jacket includes data collected from the instruction signal, the confirmation signal and the email message

itself.

The email leg jacket identifier record 110 A preferably identifies the email leg jacket 109A as an email message. Additionally, the email leg jacket identifier record 110A may include a link to the event jacket 101 of the current transaction. This link provides an organizational reference to the event jacket 101. As a result, if the email leg jacket 109A is stored in a location apart from the event jacket 101, there is an indication as to which transaction the email leg jacket 109A corresponds.

The destination email address record 112A preferably includes information relating to the email address to which the email message was sent. The destination email address record 112A may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the destination address signal as containing a destination email address, and a printable string sub-record, which may comprise a text version of the destination email address.

The source email address record 114A, relating to the email address of the end 5 user, is preferably derived from the end user's account with the communication node. Similar to the destination email address record 112A, the source email address record

114A preferably includes information relating to the email address from which the email message was sent. The source email address record 114A may include a number of sub-records, including, for example, an identifier sub-record, and a 1.0 printable string sub-record.

The email size record 116A preferably comprises information relating to the

size of the sent email message. The email size record 116A may include a positive integer sub-record comprising the size of the email message, including, for example, the number of words or characters in the email message, the byte size of the email 15 message, etc.

The attachment record 118A preferably includes information relating to any attachments that were sent with the email message. This information may include the

number, size and type of the attachments. The attachment record 118A may include an identifier sub-record, a number sub-record specifying the number of attachments 20 included with the email message, a size sub-record specifying the size of the

attachments, and a type sub-record, specifying the type of the included attachments, including, for example, a word processing document, a spreadsheet or a file containing the voice message.

The email provider record 120A preferably includes information relating to the Internet Service Provider (ISP) that transmits the email message. The email provider record 120A may include an identifier sub-record and a printable string sub-record, which comprises the name of the email provider. The email provider record 120A may include information relating to the email service provider, including, for example, the name of the provider, the cost, the quality of service or the time sensitivity of the email message.

The email urgency record 122A preferably includes information relating to the priority of the delivery of the email message that corresponds to how quickly the sender wishes the email message to be sent. For example, a value of "1" may signify that the email message should be sent as soon as possible, a value of "2" may correspond to normal delivery, a value of "3" may indicate to the email provider to send the message at the lowest cost possible, and a value of "0" may indicate an unknown or unspecified urgency rating. The priority of the email message may be pre-determined by the sender of the email message or may be determined by the communication node. The email urgency record 122A may also include an identifier sub-record as well as a value sub-record corresponding to the urgency of the email message.

The delivery schedule record 124A preferably includes information relating to when the email message should be sent. The delivery schedule record 124A may include an identifier sub-record, a request date sub-record, a request time sub-record, a delivery date sub-record, a delivery time sub-record, a request execution date sub-

record, a request execution time sub-record and a reoccurrence sub-record. The request date sub-record preferably specifies the date when the transaction request was made. The request time sub-record preferably specifies the time at which the transaction request was made. The delivery date sub-record preferably specifies the date of desired delivery of the email message. The delivery time sub-record preferably specifies the time of desired delivery of the email message. Finally, the reoccurrence sub-record preferably specifies whether the email message should reoccur; that is, whether the email message will be sent more than once.

The email classification record 126A preferably comprises information

relating to the classification of the email message. In this embodiment, email classification may be similar to classification of traditional mail, in which one class, for example, is designated for advertisements, and another class is designated for business mail. The email classification 126A may include an identifier sub-record as well as a value identifier sub-record corresponding to the class of the email message. For example, values may indicate that the email message is an advertisement. Other values may signify business class, non-business class or confidential email messages. Furthermore, other values may trigger additional information, including for example certified (requiring the certification by the system of email dispatch and delivery) or registered email messages (requiring dispatch and delivery certification by the system and certification by the recipient of receipt of the email message). The reoccurrence record 128A preferably comprises information relating to whether the email message is to be sent more than once. The reoccurrence record

128A may include an identifier sub-record. In addition, the reoccurrence record 128A may include a value sub-record corresponding to the reoccurrence of the email message. For example, values may indicate the email message be sent once, etc. daily, weekly, etc.

The recipient record 130A preferably comprises information relating to the total number of recipients receiving the email message. The recipient record 130A may include an identifier sub-record and a positive integer sub-record corresponding to the number of email recipients.

The email leg jacket creation time record 132A is preferably a record of the time at which the email message was sent. The email leg jacket creation date record

134A preferably corresponds to the date on which the email message was sent. As is the case with the event jacket creation time and date records, these two records may be obtained via the access of an internal electronic clock.

The delivery receipt record 136A will preferably contain a record specifying whether the transmitted email message requires a receipt of delivery notification, i.e., a notice to the sender that the email message was delivered to and/or received by the recipient.

The bill-to record 138A preferably contains a record of which party, if any,

will be billed for the transmission of the email message. The bill-to record 138A may be a "collect on delivery" type of record in cases in which the receiving party is charged for receiving the email message, as sending soft products via email or providing services using email are good candidates for the receiver to pay the fare. The bill-to record 138A may contain one or more of the following "billees:" the sender, the receiver or the third party.

FIG. 2B depicts a page usage record 100B. The page usage record 100B is preferably comprised of a set of data-containing jackets, with each jacket including a number of records. Each record may include a number of sub-records, defined according to the nature of the particular record, as further described below. The page usage record 100B may be compatible with any suitable standard, such as the DMH standard.

The page usage record 100B preferably includes an event jacket 101 and a page leg jacket 109B. For example, the event jacket 101 and page leg jacket 109B may be compatible with the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable standard.

The event jacket 101 and the page leg jacket 109B may include mandatory and/or optional parameters and fields depending on the operation of the communication system 10. The event jacket 101 preferably contains various information relating to the identity of the end user and the communication device, the time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. The page leg jacket 109B preferably includes the details of paging transactions made by an end user, such as a page address, a page trigger, a paging system identification, a page leg jacket creation time, a page leg jacket creation date, a delivery receipt, and a page content description. Thus, the page usage record 100B preferably contains an event jacket, 101, and may contain, dependent upon the number of paging transactions, one or more page leg jackets 109B.

As shown in FIG. 2B, the event jacket preferably includes an end user identification record 102, an end user number identification record 104, an event jacket creation time record 106 and an event jacket creation date record 108. The end user identification record 102 may be a record identifying the sender of the input signal, such as the end user. The end user identification record 102 may also indicate whether the end user is authorized to use the features and services of the communication system (i.e., whether the end user is a subscriber to the communication system). Preferably, the communication node compares the input signal with stored data concerning the end user. For example, the end user may be required to input a Personal Identification Number, a calling line identifier, a password or Internet "cookies" or tokens.

The end user device identification record 104 maintains and authenticates the number of the communication device from which the end user is calling. Preferably, the communication node performs a comparison between the number received in the input signal and the stored end user identification record. Upon finding a match, the communication node continues to create the page usage record 100B. The event jacket creation time record 106 is preferably a record of the time at which the input signal was received at the communication node (which also coincides with the time of

the creation of an page usage record 100B).

The event jacket creation date record 108 preferably corresponds to the calendar date on which the input signal was received by the communication node (also coinciding with the creation of the page usage record 100B). The communication node, when accessing an internal electronic clock, may create the event jacket creation

time and date records 106, 108.

The page leg jacket 109B of the page usage record 100B, which may include a link to the event jacket, preferably includes a number of records, such as, for example,

a page leg jacket identifier record HOB, a page address record 112B, a page trigger

record 114B, a paging system identification record 116B, a page leg jacket creation

time record 118B, a page leg jacket creation date record 120B, a delivery receipt record 122B and a page content description record 124B. Preferably, the page leg jacket includes data collected from the instruction signal, the confirmation signal and the page itself.

The page leg jacket identifier record HOB preferably identifies the page leg jacket 109B as a page message. Additionally, the page leg jacket identifier record HOB may include a link to the event jacket 101 of the current transaction. This link

provides an organizational reference to the event jacket 101. As a result, if the email

leg jacket 109B is stored in a location apart from the event jacket 101, there is an

indication as to which transaction the email leg jacket 109B corresponds. The page address record 112B preferably includes information relating to the address to which the page message was sent. The page address record 112B may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the page address signal as containing a page address, and a printable string sub-record, which may comprise a text version of the page address.

The page trigger record 114B preferably includes information relating to the entity that initiated the page message. The page trigger record 114B may include a number of sub-records, including, for example, an identifier sub-record, and a value sub-record. The value sub-record, which corresponds to the entity that sent the page, may include one value indicating that the end user sent the page message. Another value may indicate that the communication node initiated the page message. Another value may indicate that a third party requested the page message be sent. Another value may indicate that the page message is a "pass through" message, i.e., a page message automatically forwarded to the end user.

The paging system identification record 116B preferably includes information relating to the identity of the system, or commercial entity, that carried the page message. The paging system identification record 116B may include an identifier sub- record and a printable string sub-record, which may comprise a text reference of the system that carried the page message.

The page leg jacket creation time record 118B is preferably a record of the time at which the page was sent. The page leg jacket creation date record 120B preferably corresponds to the date on which the page was sent. As is the case with the event jacket creation time and date records, these two records may be obtained via the

access of an internal electronic clock.

The delivery receipt record 122B will preferably contain a record specifying whether the page message requires a receipt of delivery notification, i.e., a notice to the sender that the page was delivered to and/or received by the recipient.

The page content description record 124B is preferably a record of the content of the page message. For example, the page message may be a numeric page, a voice page, a text page, a graphic page, a musical page or any other type of page message

currently in use. Additionally, the page content description record 124B may also record the size of the page message. The purpose of the page content description record 124B may arise when determining the cost of delivery of the page message; that is, whether to charge the sender of the page according to the type of page message and/or according to the size of the page.

FIG. 2C depicts a transaction usage record 100C. The transaction usage record 100C is preferably comprised of a set of data-containing jackets, with each jacket including a number of records. Each record may include a number of sub-

records, as further described below. The transaction usage record 100C may be compatible with any suitable standard, such as the DMH standard.

The transaction usage record 100C preferably includes an event jacket 101 and a transaction leg jacket 109C. For example, the event jacket 101 and transaction leg

jacket 109C may be compatible with the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable

standard.

The event jacket 101 and the transaction leg jacket 109C may include mandatory and/or optional parameters and fields depending on the operation of the

communication system 10. The event jacket 101 preferably contains various information relating to the identity of the end user and the communication device, the

time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. The transaction leg jacket 109C preferably includes the details of transactions made by an end user, such as a transaction leg jacket identifier record, a transaction request record, a transaction delivery record, a transaction payment record and a delivery confirmation record. Thus, the transaction usage record 100C preferably contains an event jacket 101, and may contain, dependent upon the number of transactions, one or more transaction leg

jackets 109C.

As shown in FIG. 2C, the event jacket preferably includes an end user identification record 102, an end user number identification record 104, an event jacket creation time record 106 and an event jacket creation date record 108. The end

user identification record 102 may be a record identifying the sender of the input

signal, such as the end user. The end user identification record 102 may also indicate whether the end user is authorized to use the features and services of the communication system (i.e., whether the end user is a subscriber to the communication system). Preferably, the communication node compares the input signal with stored data concerning the end user. For example, the end user may be required to input a Personal Identification Number, a calling line identifier, a password or Internet "cookies" or tokens.

The end user device identification record 104 maintains and authenticates the number of the communication device from which the end user is calling. Preferably, the communication node performs a comparison between the number received in the input signal and the stored end user identification record. Upon finding a match, the communication node continues to create the transaction usage record lOOC. The event jacket creation time record 106 is preferably a record of the time at which the input signal was received at the communication node (which also coincides with the time of the creation of a transaction usage record 100C).

The event jacket creation date record 108 preferably corresponds to the calendar date on which the input signal was received by the communication node (also coinciding with the creation of the transaction usage record 100C). The communication node, when accessing an internal electronic clock, may create the event jacket creation time and date records 106, 108.

The transaction leg jacket 109C of the transaction usage record 100C, which may include a link to the event jacket, preferably includes a number of records, such as, for example, a transaction leg jacket identifier record HOC, a transaction request record 112C, a transaction delivery record 114C, a transaction payment record 116C, and a delivery confirmation record 118C. Preferably, the transaction leg jacket includes data collected from the instruction signal, the confirmation signal and the transaction itself.

The transaction leg jacket identifier record HOC preferably identifies the

transaction leg jacket 109C as a transaction. Additionally, the transaction leg jacket identifier record HOC may include a link to the event jacket 101 of the current transaction. This link provides an organizational reference to the event jacket 101.

As a result, if the email leg jacket 109C is stored in a location apart from the event

jacket 101, there is an indication as to which transaction the email leg jacket 109C corresponds.

The transaction request record 112C preferably includes information relating to the details of the transaction. The transaction request record 112C may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the page address signal as containing a page address, a date of request sub-record which preferably identifies the date when the transaction request was completed, and a time of request sub-record which identifies the time when the transaction request was completed. Also, the transaction request record 112C may

include a date of delivery sub-record which specifies the date when the transaction is to be processed and a time of delivery sub-record which specifies the time when the transaction is to be processed. Additionally, the transaction request record 112C may include a transaction entity specifying the entity with which the transaction has been processed, and a notification type string sub-record that may specify the type of notification required when the transaction is completed. The transaction request record 112C may include a sub-record describing or otherwise identifying the goods being purchased or sold. Preferably, the transaction request record 112C will be completed upon the receipt of the instruction signal at the communication node.

The transaction delivery record 114C preferably includes information relating to the details of the execution or delivery of the transaction. The transaction delivery record 114C may include a number of sub-records, including, for example, an identifier sub-record. The transaction delivery record 114C may also include a date of delivery sub-record corresponding to the date when the transaction was processed and a time of delivery sub-record corresponding to the time when the transaction was processed. Additionally, the transaction delivery record 114C may include a transaction sub-record specifying the entity with whom the transaction is to be, a transaction status sub-record specifying the status (i.e., number of attempts, current state, etc.) of the transaction, a notification status sub-record which specifies any status notifications required when the transaction has been completed, a delivery tracking subrecord, similar to a package delivery tracking number, which allows easy follow-up on progress of goods in transit, and a charge indicator delivery record 114C will be completed upon the receipt of the confirmation signal at the communication node.

The transaction payment method record 116C preferably includes information relating to the details of the exchange of payment for goods. The transaction payment method record 116C may include a number of subrecords, including, for example, the identity of a third party acting as a clearing house. The transaction payment method record 116C may also include sub-records corresponding to the type of payment,

payment terms and conditions, and any approval codes resulting from processing of

the offered payment. The transaction payment method record 116C may also include a record indicating any failed payment attempts, the reasons for failed payments, and, for aborted transactions, the reason for aborting the transaction.

The delivery confirmation record 118C preferably shows and notes the

physical delivery of the transaction at the intended recipient. The delivery confirmation record 118C may preferably contain a means with which to record a tracking number of the transaction, and potentially the signature of the recipient.

FIG. 2D depicts a call usage record 100D. The call usage record 100D is

preferably comprised of a set of data-containing jackets, with each jacket including a number of records. Each record may include a number of sub-records, as further described below. The call usage record 100D may be compatible with any suitable standard, such as the DMH standard.

The call usage record 100D preferably includes an event jacket 101 and a call

leg jacket 109D. For example, the event jacket 101 and call leg jacket 109D may be compatible with the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable standard.

The event jacket 101 and the call leg jacket 109D may include a set of

mandatory and/or optional parameters and fields depending on the operation of the

communication system 10. The event jacket 101 preferably contains various information relating to the identity of the end user and the communication device, the time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. The call leg jacket 109D preferably includes the details of call transactions made by an end user, such as a call leg jacket identifier record, a feature activation leg record and an origination leg record. Thus, the call usage record 100D preferably contains an event jacket 101, and may contain, dependent upon the number of email transactions, one or more call leg jackets 109D.

As shown in FIG.2D, the event jacket preferably includes an end user identification record 102, an end user number identification record 104, an event jacket creation time record 106 and an event jacket creation date record 108. The end user identification record 102 may be a record identifying the sender of the input signal, such as the end user. The end user identification record 102 may also indicate whether the end user is authorized to use the features and services of the communication system (i.e., whether the end user is a subscriber to the communication system). Preferably, the communication node compares the input signal with stored data concerning the end user. For example, the end user may be required to input a Personal Identification Number, a calling line identifier, a password or Internet "cookies" or tokens.

The end user device identification record 104 maintains and authenticates the number of the communication device from which the end user is calling. Preferably, the communication node performs a comparison between the number received in the input signal and the stored end user identification record. Upon finding a match, the communication node continues to create the call usage record 100D. The event jacket creation time record 106 is preferably a record of the time at which the input signal was received at the communication node (which also coincides with the time of the creation of an email usage record 100D).

The event jacket creation date record 108 preferably corresponds to the calendar date on which the input signal was received by the communication node (also coinciding with the creation of the call usage record 100D). The communication node, when accessing an internal electronic clock, may create the event jacket creation time and date records 106, 108.

The call leg jacket 109D of the call usage record 100D, which may include a link to the event jacket, preferably includes a number of records, such as, for example, a call leg jacket identifier record HOD, a feature activation leg record 112D, and an origination leg record 114D. Preferably, the call leg jacket includes data collected from the instruction signal, the confirmation signal and the call itself.

The call usage leg jacket identifier record HOD preferably identifies the call leg jacket 109D as a call. Additionally, the call leg jacket identifier record HOD may include a link to the event jacket 101 of the current transaction. This link provides an organizational reference to the event jacket 101. As a result, if the call leg jacket 109D is stored in a location apart from the event jacket 101, there is an indication as to which transaction the call leg jacket 109D corresponds. The feature activation leg record 112D preferably includes information relating to the establishment of the call. The feature activation leg record 112D may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the feature activation leg record 112D as containing information about the call, including, for example, whether the telephone call is a non-voice call or whether the call is a second, or other ordinal, call placed within the same session with the communication node 16.

Additionally, the feature activation leg record 112D may include a dialed digits sub-record, a leg number sub-record, a called digits sub-record, a call history count sub-record, a calling digits sub-record, a conversation usage sub-record, a feature indicator sub-record, a feature operation sub-record, a feature result indicator sub-record, a last leg indicator, a bearer indicator sub-record, an interaction digits sub- record, an account code digits sub-record, and a related leg number sub-record.

The dialed digits sub-record preferably specifies the actual digits dialed by the end user. The leg number sub-record preferably specifies the number of the present leg jacket. This sub-record becomes important if the corresponding call is one of a number of multiple telephone calls. The called digits sub-record preferably specifies the identity of the called party intended by the calling party. This sub-record may be different than the dialed digits sub-record in the cases when number expansion (i.e., speed dialing) or number translation applies. The calling digits sub-record preferably specifies the identity of the calling party. The conversation usage sub-record preferably measures the conversation between answer and release. The feature indicator sub-record preferably defines the particular call feature accessed (i.e., paging, email, transaction, etc.). The feature operation sub-record preferably defines the operations of the particular call feature accessed. The feature result indicator sub- record preferably records the result of an access request to the particular call feature. Preferably, the details of a non- voice call are recorded in leg jackets specific to the type of call. The last leg indicator sub-record preferably indicates if the call is the last c leg in a set of multiple calls. The bearer indicator sub-record preferably specifies the type of call (i.e., whether the call is a voice call or a multiple call, etc.). The interaction digits sub-record preferably records the digits entered in response to a voice or tone prompt. The account code digits sub-record preferably identifies the number that uniquely identifies the customer in the system (i.e., the "reach me" number). Finally, the related leg number sub-record preferably specifies the number of the call related to the total number of multiple calls (e.g., call 2 of 5).

The origination leg record 114D preferably comprises information relating to additional specifics concerning the call. The origination leg record 114D may include a number of sub-records also included in the feature activation leg record 112D, including, for example, an identifier sub-record, a dialed digits sub-record, a leg number sub-record, an account code digits sub-record, a called digits sub-record, a call history count sub-record, a conversation usage sub-record, a last leg indicator sub- record, an interaction digits sub-record, and a related leg number sub-record.

Additionally, the origination leg record 114D may further include a billing indicator sub-record, a call serial sub-record, a destination digits sub-record, an IEC connect usage sub-record, an interaction digits sub-record, and an outgoing trunk usage sub-record.

The billing indicator sub-record preferably specifies the type of billing to be applied (e.g., invoice, collection, third party, etc.). The call serial number sub-record preferably identifies the call by recording the ESN of the call. The destination digits sub-record preferably is the number which the call is routed, which may be different than the called number when translation (i.e., speed dialing) or redirection is used. The Inter Exchange Carrier (IEC) connect usage sub-record preferably specifies details on the EEC connection, if used, during the call. Finally, the outgoing trunk usage sub-record preferably record the parameters pertaining to outgoing trunk usage.

FIG.2E depicts a call detail record 100E. The call detail record of the present invention preferably stores payment information relating to the end user 20, such as, for example, a method of payment. The method of payment may be any payment method by which an end user 20 may conduct a transaction, such as, for example, a credit card, a debit card, a charge card, a prepaid card, a smart card, a telephony card, an e-check or a wire transfer. Additionally and in some cases (i.e., with an e-check), the method of payment may include a digital signature.

Preferably, the method of payment according to the present invention may be selected so as to prevent fraudulent usage of the actual method of payment. To this end, the call detail record may store an identification number referring to the account number (or other identifying mark) associated with the method of payment. The purpose for this identification number is to ensure that the entire account number of the end user 20 is never shown in plain text, either on the screen of the end user 20 or at the site of the communication transaction. As a result of the fact that the account number is never viewed in plain text, the security and integrity of the account number is preserved. Using the call detail record, the communication node 16 will preferably store the type of the method of payment and an identification number corresponding to the account number of the method of payment, such as, for example, a predetermined amount of digits. For example, if the end user 20 uses a Visa credit card to pay for a transaction, the entire credit card number is not displayed. Instead, the communication node 16 may display, for example, "VISA 1234."

When the transaction is to be consummated (i.e., paid), a signal may be sent from the communication node 16 to retrieve account information from a profile of the end user 20 making the transaction. At this point, the entire account number may be transmitted via any presently known means, such as, for example, a credit clearinghouse.

Furthermore, the call detail record 100E is preferably comprised of a set of data-containing jackets, as described above, with each jacket including a number of records. Each record may include a number of sub-records, as further described below. The call detail record 100E may be compatible with any suitable standard, such as the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable standard.

The call detail record 100E preferably includes an event jacket 101 and a call detail leg jacket 109E. The event jacket 101 and call detail leg jacket 109E may be compatible with the DMH standard, the Automatic Message Accounting standard, the Bellcore Account Format standard or any other suitable standard.

The event jacket 101 and the call detail leg jacket 109E may include mandatory and/or optional parameters and fields depending on the operation of the communication system 10. The event jacket 101 preferably contains various information relating to the identity of the end user and the communication device, the time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. The call detail leg jacket 109E preferably includes the details of the transaction, such as, for example, a call detail leg jacket identification record and an alternate billing digits record. Thus, the call detail record 100E preferably contains an event jacket 101, and may contain, dependent upon the number of transactions, one or more call detail leg jackets 109E.

As shown in FIG. 2E, the event jacket preferably includes an end user identification record 102, an end user number identification record 104, an event jacket creation time record 106 and an event jacket creation date record 108. The end user identification record 102 may be a record identifying the sender of the input signal, such as the end user. The end user identification record 102 may also indicate whether the end user is authorized to use the features and services of the communication system (i.e., whether the end user is a subscriber to the communication system). Preferably, the communication node compares the input signal with stored data associated with the end user. For example, the end user may be required to input a Personal Identification Number, a calling line identifier, a password or Internet "cookies" or tokens.

The end user device identification record 104 maintains and authenticates the number of the communication device from which the end user is calling. Preferably, the communication node performs a comparison between the input signal and the

stored end user identification record (i.e., the profile of the end user 20). Upon finding a match, the communication node continues to create the email usage record

100E. The event jacket creation time record 106 is preferably a record of the time at which the input signal was received at the communication node (which also coincides

with the time of the creation of an email usage record 100E).

The event jacket creation date record 108 preferably corresponds to the calendar date on which the input signal was received by the communication node (also

coinciding with the creation of the email usage record 100E). The communication node, when accessing an internal electronic clock, may create the event jacket creation

time and date records 106, 108.

The call detail leg jacket 109E, which may include a link to the event jacket, preferably includes a number of records, for example, a call detail leg jacket identification record HOE and an alternate billing digits record 112E. The call detail

leg jacket identifier record HOE preferably classifies the call detail leg jacket 109E as corresponding to a saved call detail parameter. Additionally, the call detail leg jacket

identifier record HOE may also include a link or reference to the event jacket 101 of the current transaction. The alternate billing digits record 112E preferably comprises information relating to the details of the call detail parameter. The alternate billing digits record 112E may include a number of sub-records, including, for example, an identifier sub- record, which preferably identifies the alternate billing digits record 112E as containing a call detail parameter and a printable string sub-record that may specify the call detail parameter i.e., the type of method of payment used and an identification of the method of payment, such as, for example, "VISA 1234"). Alternate billing digits record 112E may also include sub-records containing descriptions of electronic check account and band routing information, as well as descriptions of new and non- traditional exchange medium, such as, for example, Internet barter points or other electronic trading points.

FIG. 3A illustrates an embodiment of a routine for creating an email usage record, a page usage record, a transaction usage record, a call usage record or a call detail record. At block 500, the communication node receives an input signal from the communication device. The input signal is preferably received when the end user accesses the services of the communication node, such as, for example, dialing into the communication node from a communication device. The input signal may include a telephone number, an Electronic Serial Number (ESN), a login name or password (as in the case of a PC), or any other presently known method of accessing the communication node.

Once the input signal is received at the communication node, a usage record, detail record or event jacket is created at block 510. Examples of such records are shown in FIGS. 2A through 2E. The communication node preferably collects identification data from the input signal, such as the telephone number and the ESN, as well as from an internal electronic clock, and stores the identification information in the event jacket.

After creating the usage record, the end user may perform a variety of tasks or transactions, which may include, for example, sending an email message, sending a page, conducting a transaction, placing a call or storing account identification information, preferably commenced by the reception of a command signal at a communication node at block 520. The communication node may receive the instruction signal from a communication device. For example, the end user may transmit a command message to the communication node instructing the communication node to send an email message, such as, for example, "Send email message to John Doe." Similarly, the communication node may be instructed to send a page such as "Page John Doe", conduct a transaction such as "Pay MasterCard Bill", place a call such as "Call John Doe" and store account identification information such as "Record Visa Card Number".

Alternatively, the communication node itself may generate the instruction signal. This may occur when, for example, the communication node is preprogrammed to transmit an email alert, transmit a schedule notification, transmit a page, perform a transaction, place a call or store such information. For example, the end user may program the communication node to schedule an email delivery, send a page, place a call or make a purchase at 6:00 a.m. tomorrow. In this case, the event jacket and the leg jacket are created when the end user instructs or programs the communication node to perform such transaction.

Once the communication node determines (or generates) a command signal, the communication node begins recording information to the usage record. After the message has been sent, transaction has been conducted, call has been placed or information has been saved, the communication node then receives a confirmation signal at block 530. The confirmation signal indicates that the message has been sent, transaction has been conducted, call has been placed or information has been saved. The reception of the confirmation signal at the communication node will preferably trigger the communication node to complete the collection of data necessary to complete the leg jacket at block 540.

Additionally, the method of the present invention can record and maintain a response page usage record. FIG. 3A depicts a response page usage record 150. The response page usage record 150 may preferably be created when the communication device receives a page message requiring a response. In such situations, the communication device is preferably a two-way paging unit. The response page usage record 150 is similar to the page usage record 100, described above. However, the response page message is preferably sent automatically by the two-way paging unit itself. As a result, different infrastructure resources are required, which thus requires different records for the response page leg jacket 159, as described below.

The event jacket 151 preferably contains various information relating to the identity of the end user 20, the communication device 12 and the time of the transaction, such as, for example, end user identification, end user device identification record, time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. These records are similar to those described with reference to the event jacket 101 of the page usage record 100 in FIG. 3A.

Similar to the page leg jacket 109, the response page leg jacket 159 preferably includes the details of the page transactions, such as a response page leg jacket identifier, a page address, a paging carrier identification, the creation time and date and any delivery receipts.

The response page leg jacket identifier record 160 preferably identifies the response page leg jacket 159 as a response page message. Additionally, the response page leg jacket identifier record 160 may include an instant link to the event jacket 151 of the current transaction. This link provides an organizational reference to the event jacket 101.

The page address record 162 preferably includes information relating to the address to which the response page message was sent. The page address record 162 may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the page address signal as containing a response page address, and a printable string sub-record, which may comprise a text version of the response page address. The paging carrier identification record 164 preferably includes information relating to the identity of the system that carried the response page message. The paging carrier identification record 164 may include an identifier sub-record and a printable string sub-record, which may comprise a text version of the system that carried the response page message.

The response page leg jacket creation time record 166 is preferably a record of the time at which the page was sent. The response page leg jacket creation date record 168 preferably corresponds to the date on which the page was sent. As is the case with the event jacket creation time and date records, these two records may be obtained via the access of an internal electronic clock.

The delivery receipt record 170 preferably contains a record specifying whether the response page message requires a receipt of delivery notification, i.e., a notice to the sender that the page was delivered to and/or received by the recipient.

FIG. 3B illustrates an embodiment of a routine for allowing an end user access to a communication node via a communication device. At block 550, an end user, through a communication device, transmits an input signal to a communication node. The input signal is preferably received when the end user accesses the communication node, for example, by dialing a telephone number associated with the communication system.

The input signal may include a device number and a device identification. The device number may be a representation of a number corresponding to the communication device. Preferably, the device number signal is the telephone number of the communication device. The device identification may be a unique number (or other unique mark) identifying the communication device, including, for example, an Electronic Serial Number (ESN), a login and password on a PC or any other device identification.

The input signal may further include an authentication code. The authentication code can be utilized to minimize fraudulent usage of the communication device. This preferably occurs by validating the communication device, such as, for example, by including within the authentication code a Personal Identification Number (PIN). The authentication code may further include an authorization type signal and an authentication denied signal. Both of these signals, which are contained within the authorization code, are preferably embedded within the input signal.

The authorization type record may contain a number of values indicating the extent of the end user's access to the communication node. For example, one value may indicate that the end user may utilize the services of the communication node, but that each attempted contact with the communication node must be validated (i.e., the end user is authorized on a per call basis). Other values may indicate that the end user be authorized on an hourly, daily or weekly basis. Another value (an authorization count transaction value) may indicate that the end user be authorized for a specified number of calls per transaction. Another value (an authorization count value) may indicate that the end user's authorization be based on the amount of money contained within the account of the end user. In such a case, the amount of money charged for the current transaction, the date of the current transaction, and the updated value of the account of the end user will preferably be recorded in another value (an authorization charge value).

The authentication denied record corresponds to the validation of the communication device. The authentication denied record includes a number of values corresponding to the validation of the communication device. For example, one value may indicate that the communication device is unassigned to the end user, that the ESN is invalid, that the end user is temporarily denied service due to a delinquent account or that the communication device is a duplicate or cloned device. Another value (an unrecognized end user value) may indicate that the end user is not recognized or authorized to utilize the requested aspect of the communication node. A multiple subscription usage value may indicate that the end user's account is being used simultaneously or in near-real time from multiple locations. An insufficient funds usage value may indicate that the end user's account does not have enough funds for the requested transaction. Additionally, a superseding value, which may be programmed by the communication node to override the values stored on the communication device, may indicate that the communication device has been stolen.

At block 560, after receiving the input signal, the communication node compares the input signal with a database of device numbers and a database of device identifiers. Each database may be a memory bank located integral with, or remote from, the communication node. Preferably, the database of device numbers contains a series of device number signals, and the database of device identifiers contains a

series of particular device identifiers. The communication node compares the input signal received from the communication device with both databases.

Upon matching the device number in the input signal with a device number in the device number database, and matching a device identification with a device identifier in the device identifier database, the communication node can then ensure that the input signal is coming from a registered end user. Once the input signal has been matched, the end user is permitted access to the communication node at block

570.

The communication node then compares the authentication code received in

the input signal with a database of valid authentication values at block 580. The database of valid authentication values may be stored in a memory bank located integral with, or remote from, the communication node. As described above, each authentication value contained in the database preferably corresponds to a limitation

of the end user' s access to the communication node.

Once the authentication signal has been matched with an authentication value, the end user's access to the communication node may be limited based on the authentication value comparison with the database of valid authentication values at

block 590.

Additionally, the method of the present invention can record and maintain a response page usage record. FIG. 4 depicts a response page usage record 150. The response page usage record 150 may preferably be created when the communication device receives a page message requiring a response. In such situations, the communication device is preferably a two-way paging unit. The response page usage record 150 is similar to the page usage record 100B, described above. However, the response page message is preferably sent automatically by the two-way paging unit itself. As a result, different infrastructure resources are required, which thus requires different records for the response page leg jacket 159, as described below.

The event jacket 151 preferably contains various information relating to the identity of the end user 20, the communication device 12 and the time of the transaction, such as, for example, end user identification, end user device identification record, time and/or date of the transaction, etc. It will be recognized that the event jacket 101 may contain any other suitable information. These records are similar to those described with reference to the event jacket 101 of the page usage record 100 in FIG. 2B.

The page address record 162 preferably includes information relating to the address to which the response page message was sent. The page address record 162 may include a number of sub-records, including, for example, an identifier sub-record, which preferably identifies the page address signal as containing a response page address, and a printable string sub-record, which may comprise a text version of the response page address.

The paging carrier identification record 164 preferably includes information relating to the identity of the system that carried the response page message. The paging carrier identification record 164 may include an identifier sub-record and a printable string sub-record, which may comprise a text version of the system that carried the response page message.

The delivery receipt record 170 preferably contains a record specifying whether the response page message requires a receipt of delivery notification, i.e., a notice to the sender that the page was delivered to and/or received by the recipient. Referring now to FIG.5, an exemplary block diagram of another embodiment of a communication system 200 having the capability to create and maintain usage records is illustrated. The communication system can implement the routine described in FIG. 3A above.

The communication system 200 generally includes one or more communication devices 201, 202, 203, 204, 205 (five being shown), an electronic network 206, and one or more information sources (e.g., content providers 208, 221 (two being shown) and data and voice markup language servers 209, 251, 253, 257).

The end user can access the electronic network 206 by dialing a single direct access telephone number (e.g., a foreign exchange telephone number, a local telephone number, or a toll-free telephone number or PBX) from the communication device 201. The end user can also access the electronic network 206 from the communication device 202 via the Internet 220 or WWW, from the communication device 203 via a paging network 211, or from the communication device 205 via a LAN, a WAN, an email connection or in any other similar manner.

As shown in FIG.5, the electronic network 206 includes a telecommunication network 210 and a communication node 212. The telecommunication network 210 is preferably connected to the communication node 212 via a high-speed data link, such as, for example, a Tl telephone line, a LAN, a WAN or a VOIP network. The telecommunication network 210 preferably includes a PSTN 214 and a carrier network 216. The telecommunication network 210 can also include, for example, international or local exchange networks, cable TV networks, inter-exchange carrier or long distance carrier networks, cellular networks (e.g., mobile switching centers), PBXs, satellite systems, wireless data networks and other switching centers such as conventional or trunked radio systems (not shown), etc. The electronic network 206 can also include additional telecommunication networks, such as, for example, a wireless data network 207.

The PSTN 214 can include various types of communication equipment, such as, for example, ATM networks, Fiber Distributed Data networks (FDDI), Tl lines, cable TV networks, VOJJP networks and the like. The carrier network 216 generally includes a telephone switching system or central office 218.

It will be recognized that the carrier network 216 can be any suitable system that can route calls to the communication node 212, and the central office 218 can be any suitable wire-line or wireless switching system.

The communication node 212 is preferably configured to receive and process incoming calls from the carrier network 216 and the Internet 220. The communication node 212 can receive and process pages from the paging network 211 and can also receive and process messages (e.g., emails) from the LAN, WAN, wireless data or email system 213.

When an end user dials into the electronic network 206 from the communication device 201, the carrier network 216 routes the incoming call from the PSTN 214 to the communication node 212 over one or more telephone lines or trunks. The incoming calls preferably enter the carrier network 216 through one or more "888" or "800" Inward Wide Area Telecommunications Services trunk lines, local exchange or long distance trunk lines. It is also contemplated that the incoming calls can be received from a cable, cellular or VOJJ? network or any other suitable system.

The communication node 212 answers the incoming call from the carrier network 216 and retrieves an appropriate announcement (e.g., a welcome greeting) from a database, server or browser. The communication node 212 then plays the announcement to the caller. In response to audio inputs from the end user, the communication node 212 retrieves information from a destination or database of one or more of the information sources, such as the content providers 208, 221 or the markup language servers 209, 251, 253, 257. After the communication node 212 receives the information, it provides a response to the end user based upon the retrieved information.

The communication node 212 can provide various dialog voice personalities (e.g., a female voice, a male voice, etc.), and can implement various grammars (e.g., vocabulary) to detect and respond to the audio inputs from the end user. In addition, the communication node 212 can automatically select various speech recognition models (e.g., English, Spanish or English accent models) based upon an end user's profile, communication device and/or speech patterns. The communication node 212 can also allow the end user to select a particular speech recognition model.

When an end user accesses the electronic network 206 from a communication device 201, 202, 203, 204, 205 registered with the system (e.g., home telephone, work telephone, cellular telephone, etc.), the communication node 212 can by-pass an end user screening option and automatically identify the end user (or the type of

communication device) through the use of ANI or CLI. After the communication

node 212 verifies the call, the communication node 212 provides a greeting (e.g., "Hi, this is your personal agent, Maya. Welcome Bob. How may I help you?"). The communication node 212 then enters into a dialogue with the end user, and the end user can select a variety of services offered by the communication node 212.

When the end user accesses the electronic network 206 from a communication device not registered with the system (e.g., a payphone, a telephone of a non-end user, etc.), the communication node 212 answers the call and prompts the end user to enter his or her name and/or a personal identification number (PIN) using voice commands

or DTMF signals. The communication node 212 can also utilize speaker verification to identify the particular speech pattern of the end user. If the communication node 212 authorizes the end user to access the system, the communication node 212 provides a personal greeting to the end user (e.g., "Hi, this is your personal agent, Maya. Welcome Ann. How may I help you?").

The communication node 212 then enters into a dialogue with the end user,

and the end user can select various services offered by the communication node 212. Ii the name and/or PIN of the end user cannot be recognized or verified by the

communication node 212, the end user will be routed to a customer service representative.

Once the end user has accessed the communication system 200, the end user may implement a wide variety of services and features by using voice commands, such as, for example, voice dialing, voice paging, facsimiles, caller announcements, voice mails, reminders, call forwarding, call recording, content information (e.g., newspapers, etc.), read email, read calendars, read "to-do" lists, banking, e-commerce. The communication system 200 can place outbound calls and pages to business and personal parties or contacts (e.g., friends, clients, business associates, family members, etc.) in response to DTMF signals or voice commands. The calls can be routed through a telephone or electronic network to the selected party and the pagers can be sent to a selected party via a paging system. The communication system 200 can also receive calls routed through a telephone or electronic network.

As shown in FIG. 5, the communication node 212 preferably includes a telephone switch 230, a voice or audio recognition (VRU) client 232, a VRU server 234, a controller or call control unit 236, an Operation and Maintenance Office or a billing server unit 238, a LAN 240, an application server unit 242, a database server unit 244, a gateway server or router firewall server unit 246, a VOJP unit 248, a voice browser 250, a voice markup language server 251, a messaging server 255 and a data markup language server 253. Although the communication node 212 is shown as being constructed with various types of independent and separate units or devices, the communication node 212 can be implemented by one or more integrated circuits, microprocessors, microcontrollers or computers which may be programmed to execute the operations or functions equivalent to those performed by the devices or units shown. It will also be recognized that the communication node 212 can be carried out in the form of hardware components and circuit designs and/or software or computer programs. The communication node 212 can be located in various geographic locations throughout the world or the United States (e.g., Chicago, IL). The communication node 212 can be operated by one or more carriers (e.g., Sprint, Qwest, MCI, etc.) or independent service providers (e.g., Motorola, Inc.).

The communication node 212 can be integrated with the carrier network 216 or can be located remote from the carrier network 216. It is also contemplated that the communication node 212 may be integrated into a communication device, such as, for example, a wire-line or wireless telephone, a radio device, a PC, a PDA, a PDVI, etc., and can be programmed to connect or link directly to an information source.

The communication node 212 can also be configured as a standalone system to allow end users to dial directly into the communication node 212 via a direct access telephone number. In addition, the communication node 212 may comprise a telephony switch (e.g., a PBX or Centrix unit), an enterprise network or a LAN. In this configuration, the communication system 200 can be implemented to automatically connect an end user to the communication node 212 when the end user accesses a communication device.

When the telephone switch 230 receives an incoming call from the carrier network 216, the call control unit 236 sets up a connection in the telephone switch 230 to the VRU client 232. The communication node 212 then enters into a dialog with the end user regarding various services and functions. The VRU client 232 preferably generates pre-recorded voice announcements and/or messages to prompt the end user to provide inputs to the communication node 212 using voice commands or DTMF signals.

In response to the inputs from the end user, the communication node 212 retrieves information from a destination of one of the information sources and provides outputs to the end user.

The telephone switch 230 is preferably connected to the VRU client 232, the VOIP unit 248 and the LAN 240. The telephone switch 230 receives incoming calls from the carrier network 216. The telephone switch 230 also receives incoming calls from the communication device 202 routed over the Internet 220 via the VOD? unit 248. The telephone switch 230 also receives messages and pages from communication devices 203, 205, respectively. The telephone switch 230 is preferably a digital cross-connect switch, Model LNX, available from Excel Switching Corporation, Hyannis, MA. It will be recognized that the telephone switch 230 can be any suitable switch.

The VRU client 232 is preferably connected to the VRU server 234 and the

LAN 240. The VRU client 232 processes voice communications, DTMF signals, pages and messages (e.g., emails). Upon receiving voice communications, the VRU client 232 routes the speech communications to the VRU server 234. When the VRU client 232 detects DTMF signals, it sends a command to the call control unit 236. It will be recognized that the VRU client 232 can be integrated with the VRU server 234. The VRU client 232 preferably comprises a PC, such as, for example, a Windows NT compatible PC, with hardware capable of connecting individual

telephone lines directly to the telephone switch 230 or carrier network 216. The VRU client 232 preferably includes a microprocessor, random access memory, read-only memory, a Tl or ISDN interface board, and one or more voice communication processing boards (not shown). The voice communication processing boards are preferably Dialogic boards, Antares Model, available from Dialogic Corporation, Parsippany, NJ. The voice communication boards may include a voice recognition engine having a vocabulary for detecting a speech pattern.

The voice recognition engine is preferably a RecServer software package, available from Nuance Communications, Menlo Park, CA.

The VRU client 232 can also include an echo canceler (not shown) to reduce

or cancel ITS or playback echoes transmitted from the PSTN 214 due to hybrid impedance mismatches. The echo canceler is preferably included in an Antares Board Support Package, also available from Dialogic.

The call control unit 236 is preferably connected to the LAN 240, and sets up

the telephone switch 230 to connect incoming calls to the VRU client 232. The call

control unit 236 also sets up incoming calls or pages to the communication node 212 over the Internet 220 and pages and messages sent from the communication devices

203, 205 via the paging network 211 and email system 213, respectively. The control call unit 236 preferably comprises a PC, such as, for example, a Windows NT compatible PC. The LAN 240 allows the various components and devices of the communication node 212 to communicate with each other via twisted pair, fiber optic, coaxial cables or the like. The LAN 240 may use Ethernet, Token Ring or other suitable types of protocols. The LAN 240 is preferably a 100 Megabit per second Ethernet switch, available from Cisco Systems, San Jose, CA, and can comprise any suitable network system. The communication node 212 may include a plurality of LANs.

The VRU server 234 is connected to the VRU client 232 and the LAN 240. The VRU server 234 receives voice communications from the end user via the VRU client 232. The VRU server 234 processes the voice communications and compares the voice communications against a vocabulary or grammar stored in the database server unit 244 or a similar memory device.

The VRU server 234 provides output signals, representing the result of the voice communications processing, to the LAN 240. The LAN 240 routes the output signal to the call control unit 236, the application server unit 242 and/or the voice browser 250. The communication node 212 then performs a specific function associated with the output signals.

The VRU server 234 preferably includes a TTS unit 252, an automatic speech recognition (ASR) unit 254, and a STT unit 256. The TTS unit 252 receives textual data or information (e.g., email, web pages, documents, files, etc.) from the application server unit 242, the database server unit 244, the call control unit 236, the gateway server unit 246, the application server unit 242 and the voice browser 250. The TTS unit 252 processes the textual data and converts the data to voice data or information.

The TTS unit 252 can provide data to the VRU client 232, which reads or plays the data to the end user. For example, when the end user requests information (e.g., news updates, stock information, traffic conditions, etc.), the communication node 212 retrieves the desired data (e.g., textual information) from a destination of the

one or more of the information sources and converts the data via the TTS unit 252 into

a response.

The response is then sent to the VRU client 232. The VRU client 232 processes the response and reads an audio message to the end user based upon the response. It is contemplated that the VRU server 234 can read the audio message to the end user using human recorded speech or synthesized speech. The TTS unit 252 is preferably a TTS 2000 software package, available from Lernout and Hauspie Speech Product NV, Burlington, MA.

The ASR unit 254 provides speaker dependent or independent automatic voice recognition of voice communications from the end user. It is contemplated that the

ASR unit 254 can include speaker dependent voice recognition. The ASR unit 254 processes the voice communications to determine whether a word or a speech pattern

matches any of the grammars or vocabulary stored in the database server unit 244 or downloaded from the voice browser 250. When the ASR unit 254 identifies a

selected speech pattern of the voice communications, the ASR unit 254 sends an output signal to implement the specific function associated with the recognized speech pattern. The ASR unit 254 is preferably a speaker independent voice recognition software package, RecServer Model, also available from Nuance Communications. It is contemplated that the ASR unit 254 can be any suitable voice recognition unit to detect voice communications.

The STT unit 256 receives voice communications and converts the voice communications to textual information (e.g., a text message). The textual information can be sent or routed to the communication devices 201, 202, 203, 204, 205, the content providers 208, 221, the markup language servers 209, 251, 253, 257, the voice browser 250 and the application server unit 242. The STT unit 256 is preferably a Naturally Speaking software package, available from Dragon Systems, Newton, MA.

The VOIP unit 248 is preferably connected to the telephone switch 230 and the LAN 240. The VOIP unit 248 allows an end user to access the communication node 212 via the Internet 220 or VOJP public network using voice commands. The VOIP unit 248 can receive VOIP protocols (e.g., H.323 protocols) transmitted over the Internet 220 or Intranet, and can convert the VOD? protocols to voice information or data. The voice information can then be read to the end user via the VRU client 232.

The VOIP unit 248 can also receive voice communications from the end user and convert the voice communications to a VOIP protocol that can be transmitted over the Internet 220. The VOIP unit 248 is preferably a Voice Net software package, also available from Dialogic Corporation. It will be recognized that the VOIP unit 248 can be incorporated into a communication device. The communication node 212 also includes a detection unit 260. The detection unit 260 is preferably a phrase or key word spotter unit, detecting incoming audio inputs or communications or DTMF signals from the end user. The detection unit 260 is preferably incorporated into the telephone switch 230, but can be incorporated into the VRU client 232, the carrier network 216 or the VRU server 234. The detection unit 260 is preferably included in a RecServer software package, also available from Nuance Communications.

The detection unit 260 records the audio inputs from the end user and compares the audio inputs to the vocabulary or grammar stored in the database server unit 244. The detection unit 260 continuously monitors the end user's audio inputs for a key phase or word after the end user is connected to the node 212. When the detection unit 260 detects the key phrase or word, the VRU client 232 plays a prerecorded message to the end user. The VRU client 232 then responds to the audio inputs provided by the end user.

The billing server unit 238 is preferably connected to the LAN 240. The billing server unit 238 can record data about the use of the communication node 212 by an end user (e.g., length of calls, features accessed by the end user, etc.). Upon completion of a call by an end user, the call control unit 236 sends data to the billing server unit 238. The billing server unit 238 can subsequently process the data in order to prepare customer bills. The billing server unit 238 can use the ANI or CLI of the communication device to properly bill the end user. The billing server unit 238 preferably comprises a Windows NT compatible PC. The gateway server unit 246 is preferably connected to the LAN 240 and the Internet 220. The gateway server unit 246 provides access to the content provider 221 and the voice markup language server 257 via the Internet 220. The gateway server unit 246 allows end users to access the communication node 212 from the communication device 202 via the Internet 220. The gateway server unit 246 can function as a firewall to control access to the communication node 212 to authorized end users. The gateway server unit 246 is preferably a Cisco Router, also available from Cisco Systems.

The database server unit 244 is preferably connected to the LAN 240. The database server unit 244 preferably includes a plurality of storage areas to store data relating to end users, such as, for example, speech vocabularies, dialogs, personalities, end user entered data, various usage records, and other information. Preferably, the database server unit 244 stores a personal file or address book. The personal address book can contain information required for the operation of the communication system 200, including end user reference numbers, personal access codes, personal account information, contact's addresses, telephone numbers, etc. The database server unit 244 is preferably a PC, such as, for example, a Windows NT compatible PC.

The application server unit 242 is preferably connected to the LAN 240 and the content provider 208. The application server unit 242 allows the communication node 212 to access information from a destination of the information sources, such as the content providers 208, 221 and the markup language servers 209, 251, 253, 257. For example, the application server unit 242 can retrieve information (e.g., weather reports, stock information, traffic reports, restaurants, flower shops, banks, calendars, "to-do" lists, e-commerce, etc.) from a destination of the information sources. This application server unit 242 may include Starfish Software to provide the address book, calendar and to-do lists, and to allow the end user to organize information. The application server unit 242 processes the retrieved information and provides the information to the VRU server 234 and the voice browser 250. The VRU server 234 can provide an audio announcement to the end user based upon the information using TTS synthesizing or human recorded voice. The application server unit 242 can also send tasks or requests (e.g., transactional information) received from the end user to the information sources (e.g., a request to place an order for a pizza). The application server unit 242 can further receive end user inputs from the VRU server 234 based upon a speech recognition output. The application server unit 242 is preferably a PC.

The voice markup language server 251 is preferably connected to the LAN 240. The voice markup language server 251 can include a database, scripts and markup language documents or pages. The voice markup language server 251 is preferably a PC, such as, for example, a Windows NT compatible PC. It will also be recognized that the voice markup language server 251 can be an Internet server (e.g., a Sun Microsystems server).

The messaging server 255 is preferably connected to the LAN 240, the paging network 211, an email system 213 and a short message system (SMS) 290. The messaging server 255 routes pages between the LAN 240 and the paging network 211. The messaging server 255 is preferably a PC, such as, for example, a Windows NT compatible PC. The messaging server 255 can also provide direct storage. It is contemplated that the messaging server 255 can reside externally from the

communication node 212.

The voice browser 250 is preferably connected to the LAN 240. The voice

browser 250 preferably receives information from the markup language servers 209,

251, 253, 257, the database server unit 244 and the content providers 208, 221. In response to voice commands or DTMF signals, the voice browser 250 generates a content request (e.g., an electronic address) to navigate to a destination of one or more of the information sources. The content request can use at least a portion of a Uniform Resource Locator, an Internet Protocol, a page request, or email.

After the voice browser 250 is connected to an information source, the voice

browser 250 preferably uses a Transmission Control Protocol/Internet Protocol connection to pass requests to the information source. The information source responds to the requests, sending at least a portion of the requested information, represented in electronic form, to the voice browser 250. The information can be stored in a database, and can include text content, markup language document or

pages, non-text content, dialogs, audio sample data, recognition grammars, etc. The voice browser 250 then parses and interprets the information, further described below.

The voice browser 250 can be integrated into the communication devices 201, 202, 203, 204, 205.

As shown in FIG. 5, the content provider 208 is connected to the application

server unit 242 of the communication node 212, and the content provider 221 is connected to the gateway server unit 246 of the communication node 212 via the Internet 220. The content providers 208, 221 can store various content information, such as, for example, news, banking, commerce, weather, traffic conditions, etc. The content providers 208, 221 can include a server to operate WWW pages or documents in the form of a markup language. The content providers 208, 221 can also include a database, scripts and/or markup language documents or pages. The scripts can include images, audio, grammars, computer programs, etc. The content providers 208, 221 execute suitable server software to send requested information to the voice browser 250.

The voice mail unit 274 is preferably connected to the telephone switch 203 and the LAN 240. The voice mail unit 274 can store voice mail messages from parties trying to send messages to the communication node 212. When an end user accesses the electronic network 206, the voice mail unit 274 can notify the end user of new and stored messages. The end user can access the messages to play, delete, store and forward the messages. When the end user accesses a message, the message can be read to the end user or can be displayed as textual information on a communication device (e.g., a pager, a SMS 290, or a PDA, etc.). The end user can also access and operate external messages or mail systems remote from the electronic network 206.

The FAX server unit 272 is preferably connected to the telephone switch 230 and the LAN 240. The FAX server unit 272 receivers and stores facsimile information sent via the electronic network 206 or the carrier network 216. Subscribers can access the facsimile information to play, store, delete, and forward the information. The facsimile information can be read via the TTS unit 252 or can be displayed as textual information on a suitable communication device. The FAX server unit 272 preferably comprises a PC, such as, for example, a Windows NT compatible PC or a Dialogue Fax Server.

Further information regarding communication system 200 is disclosed in U.S.

Patent Application No. 09/141,485, entitled Telecommunication System and Methods Therefor, filed August 27, 1998, the entire disclosure of which is incorporated herein.

It should be appreciated that the embodiments described above are to be considered in all respects only illustrative and not restrictive. The scope of the invention is indicated by the following claims rather than by the foregoing description. All changes that come within the meaning and range of equivalents are to be embraced within their scope.

Claims

WE CLAIM:

1. A method of creating a usage record comprising: receiving an input signal; creating a usage record in response to the input signal; creating an event jacket associated with the usage record; receiving a command to send a message; receiving a confirmation signal after the message has been sent; and creating a leg jacket including at least one record, the at least one record including information relating to the message.

2. The method of claim 1, wherein the input signal is received from a communication device.

3. The method of claim 2, wherein the communication device includes one of a telephone, a paging unit, a cellular telephone, a satellite telephone, an Internet telephone and a personal computer.

4. The method of claim 1, wherein the instruction signal is received at a communication node from a communication device.

5. The method of claim 1, wherein the instruction signal is generated by a

communication node.

6. The method of claim 1, wherein the confirmation signal is received at a

communication node.

7. The method of claim 1, wherein the event jacket includes at least one of an end user identification record, an end user device identification record, a first time record and a first date record.

8. The method of claim 1, wherein the leg jacket includes at least one of an identifier record, a destination address record, a source address record, a size

record, an attachment record, a provider record, an urgency record, a delivery record, a class record, a reoccurrence record, a recipient record, a second time record, a second date record, a delivery receipt record and a bill-to record.

9. A system for creating a usage record comprising: computer readable program code to receive an input signal; computer readable program code to create a usage record in response to the input signal; computer readable program code to receive a request to send a message; computer readable program code to receive a confirmation signal after the message has been sent; and computer readable program code to create a leg jacket including at least one record, the at least one record including information relating to the message.

10. The system of claim 9, wherein the input signal is received from a communication device.

11. The system of claim 10, wherein the communication device includes one of a telephone, a paging unit, a cellular telephone, a satellite telephone, an Internet telephone and a personal computer.

12. The system of claim 9, wherein the instruction signal is received at a communication node from a communication device.

13. The system of claim 9, wherein the instruction signal is generated by a communication node.

14. The system of claim 9, wherein the confirmation signal is received at a communication node.

15. The system of claim 9, wherein the event jacket includes at least one of an end user identification record, an end user device identification record, a first time record and a first date record.

16. The system of claim 9, wherein the leg jacket includes at least one of an identifier record, a destination address record, a source address record, a size record, an attachment record, a provider record, an urgency record, a delivery record, a class record, a reoccurrence record, a recipient record, a second time record, a second date record, a delivery receipt record and a bill-to record.

17. A method of allowing an end user access to a communication node comprising:

receiving from a communication device an input signal having a device number signal and a device identification signal; comparing the input signal with a database of device numbers; comparing the input signal with a database of device identifiers; and allowing the end user access to the communication node when one of the device numbers in the database of device numbers matches the input signal and one of the device identifiers in the database of device identifiers matches the input signal.

18. The method of claim 17, wherein the input signal further includes an authentication signal.

19. The method of claim 18, further comprising: comparing the authentication signal with a database of authentication values; and limiting the access to the communication node based on the database of authentication values.

20. The method of claim 17, wherein the input signal is received from a communication device.

21. A system for allowing access to a communication node comprising: computer readable program code to receive an input signal, the input signal including a device number signal and a device identification signal; computer readable program code to compare the input signal with a database of device numbers; computer readable program code to compare the input signal with a database of device identifiers; and computer readable program code to allow the end user access to the communication node when one of the device numbers in the database of device numbers matches the input signal and one of the device identifiers in the database of device identifiers matches the input signal.

22. The system of claim 21, wherein the input signal further includes an authentication signal.

23. The system of claim 22, further comprising: computer readable program code to compare the authentication signal with a database of authentication values; and computer readable program code to limit the access to the communication node based on the database of authentication values.

24. The system of claim 21, wherein the input signal is received from a communication device.