WO2000059191A1

WO2000059191A1 - Phone status monitor

Info

Publication number: WO2000059191A1
Application number: PCT/US1999/027892
Authority: WO
Inventors: James A. Jorasch; Jay S. Walker; Magdalena Mik; John B. Dickerson; Marc D. Kessman
Original assignee: Walker Digital, Llc
Priority date: 1999-03-31
Filing date: 1999-11-24
Publication date: 2000-10-05
Also published as: AU2029700A

Abstract

The phone status monitor utilizes digital technology for monitoring the status of a first client telephone, and for sending this status information via a central server to an authorized second client telephone. The remote central server stores a database of registered client telephones and corresponding client telephones that the client has registered to monitor. A user of a registered client telephone monitors in real time the telephone status of registered friends, family, or co-workers that have agreed to be monitored by the user.

Description

PHONE STATUS MONITOR

TECHNICAL FIELD OF THE APPLICATION

This invention relates generally to telephones and more specifically to a method and apparatus for monitoring the status of telephones.

BACKGROUND OF THE INVENTION

People have been demanding more convenient systems and methods for initiating and receiving telephone calls. For example, before answering a call, people want to know who is calling. Conventional telephone caller identification systems attempt to meet this need by displaying the originating number of an incoming call before the call is answered. Such systems, typically referred to as "Caller ID" systems, trace the call as it is received by the telephone company's central office. It allows the person receiving the call to view the identity of the caller in order to decide whether to answer the call. Generally a display screen connected to or provided with the telephone displays the number and person or business assigned to the originating number of the incoming call.

Caller ID systems have a number of applications. For example, a person is able to monitor and report calls that are disturbing. A business person may answer calls only when prepared. A customer service center may prepare for a customer's call by pulling up a customer's system record before answering the incoming call. Customer call service centers may utilize intra-office Private Branch Exchange (PBX) systems with display screens that identify which lines are being used and the person who is using each line.

A number of conventional Caller ID systems interconnect with a user's personal computer (PC) software. These conventional systems display, for a receiving party, incoming calls on a PC. For example, one Caller ID System, Xantel Connex, by Xantel Corporation of Phoenix, Arizona, uses Computer Telephony Integration (CTI) software based on the WINDOWS operating system by Microsoft, Inc. of Redmond, Washington. This system provides subscribers the ability to micro-manage incoming and outgoing phone calls on a PC. The subscriber views incoming phone calls on a PC and decides whether to answer the call, divert the call to voice mail or divert the phone calls to a pre-selected telephone number. A major limitation of the Xantel Connex System is that its high cost prohibits the average user from purchasing this system. A factor attributing to its high cost is that a Xantel Connex System requires at least two separate phone lines.

Telephone customers have also been demanding more efficient systems and methods for initiating and sending telephone calls. For example, FIG 1 shows that a caller using a conventional telephone system 100 is not notified of the status of a line until after the caller has entered the telephone number. More particularly, conventional telephone system 100 electrically connects a caller telephone 102 and callee telephone 106, of a person being called, to a local central office 104. When caller telephone 102 goes off-hook, a complete tip and πng circuit results where caller telephone 102 receives a dial tone from local central office 104. Caller telephone 102 sends a Dual Tone Multi-Frequency (DTMF) code to central office 104 that identifies callee telephone 106. Central office 104 routes the call to the appropπate telephone based on the DTMF code and generates an AC ringer voltage at callee telephone 106. In response to the ringer voltage, the callee telephone 106 rings. Callee telephone 106 goes off-hook, which establishes the circuit of caller telephone 102, local central office 104 and callee telephone 106. If callee telephone 106 is using the phone when caller telephone 102 attempts to call callee telephone 106, the AC ring generator fails and central office 104 sends a busy signal to caller telephone 102. Consequently, the caller does not discover that callee telephone 106 is busy until the entire conventional call processing method is completed. People generally find this process inefficient and wasteful of their time. To compound matters, due to the growth in the number of area codes, dialing a typical person's phone number generally requires additional time and effort to enter the three additional area code digits. Therefore, there is a need for an efficient system and method for providing a caller with information regarding the status of callee telephone 106. Conventional telephone systems have been developed that provide caller's status information, but do so in a costly manner that requires significant user time. For example, the office based PBX telephone system provides a caller with status information. PBX systems generally include display screens built directly within individual units. Typically these screens display the time, date, inter-office extension numbers for incoming phone calls, the user's telephone extension and an off-hook status. Bell Atlantic NYNEX Mobile of New York offers a screen-based PBX system entitled "Analog Display Services (ADSI)". ADSI provides a visual display menu of service options that are available during each call. For example, if an ADSI user calls a party and receives a busy signal, the screen displays "the line is busy" and offers the caller the option of pressing a button to activate the repeat dial feature. Those skilled in the art will recognize that for the ADSI system to determine whether the party's line is busy or available requires that the caller's telephone poll the central station and wait for a call back to receive status information. Therefore, while the caller waits, the caller's telephone line must remain unutilized, thereby preventing the caller from placing other calls. Since the caller's telephone does not readily posses information regarding whether the party's line is busy, the caller wastes time waiting for this information.

At present, the telephone industry is in the process of switching to digital technology (i.e., Integrated Services Digital Network (ISDN), and Asymmetric Digital Loop (ASDL)). ISDN is an international communications standard for sending voice and data over telephone lines. ISDN technology transmits data at a rate far faster than prior telephone connection technologies. ISDN lines generally include three channels, two bearer (B) channels and one data (D) channel. Each B channel carries voice and data at a bandwidth of 64 kbps (thousands of bits per second), and the D channel handles signal control information. ISDN's two B channels enable the caller to simultaneously receive and send information. Currently, digitally enabled telephones are being produced.

As a result of the shortcomings of conventional telephone systems and due to the availability of faster digital communication technologies, there exists a need for a system and method that utilizes digital technology to provide a telephone caller with immediate information regarding the status of the person or person's line that the caller plans to call. SUMMARY OF THE INVENTION

The present invention substantially improves on the prior art system and method used for monitoring the status of a telephone. The system and method of the present invention utilizes digital technology, such as ISDN or ADSL, for monitoring the status of a first client's telephone and for sending this status information via a remote central server to an authorized second client's telephone.

In particular, the remote central server of the present invention stores a database of a registered client telephones and corresponding client's telephones that the client has registered to monitor. A user of a registered client may monitor the status of other registered friends, family, or co-workers that have agreed to be monitored by the user in real time.

Example statuses that a client may monitor include (i) a status that is automatically detected by the system (e.g., on hook/off-hook status of the party being monitored and the party to whom the party is talking to), and (ii) a manually entered status of the monitored party (i.e., home/not home status of the monitored party, or working/not working). The manually entered statuses may be triggered, for example, by the monitored party entering a DTMF code into the party's telephone (e.g., *40). Once the party enters the code, the status displayed on the monitoring party's telephone is changed to reflect the updated status.

Once a client registers with the status monitoring system, the client selects the parties that the client wishes to monitor. The central server receives the requests and verifies that the monitored parties are registered and have agreed to be monitored by the client. If the monitored parties are registered and have agreed to be monitored, the telephones of monitored parties send status updates to the central server and the central server transmits the status updates to the appropriate client. A conventional encryption/decryption or digital certificate protocol and a digital signature may be included in the procedures of the system so that data passing between the central server and client telephones is secure. The present invention, in accordance with one embodiment, provides a method for tracking a status of a first telephone over a telephony network. The method comprises the steps of sending a request to monitor the first telephone; receiving authorization to monitor the first telephone; receiving the status of the first telephone; and storing the status of the first telephone.

The present invention, in accordance with another embodiment, provides a method for tracking a status of a first telephone over a telephony network. The method comprises the steps of receiving a request from a second telephone to monitor the first telephone; requesting authorization from the first telephone to send the status to the second telephone; receiving the authorization to send the status to the second telephone; receiving the status from the first telephone; and sending the status to the second telephone.

The present invention, in accordance with another embodiment, provides a system for tracking a status of a first telephone over a telephony network. The system comprising a monitor request service for sending a request to monitor the first telephone; a communication interface coupled to the monitor request service for receiving authorization to monitor the first telephone; and a database manager coupled to the communication interface for storing the status of the first telephone.

The present invention, in accordance with another embodiment, provides a system for tracking a status of a first telephone over a telephony network. The system comprising a communications interface for receiving a request from a second telephone to monitor the first telephone; a registration service coupled to the communications interface for requesting and receiving authorization from the first telephone to send the status to the second telephone; a notification service coupled to the registration service for receiving the status from the first telephone; and a queue manager coupled to the notification service for sending the status to the second telephone.

It will be appreciated that the present invention may be applied to alternative types of communication technologies. For example, this invention could apply to packet switched (Internet) calls.

The invention may be better appreciated from the following Figures, taken together with the accompanying Detailed Description of the Invention. BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described with reference to the accompanying drawings, wherein:

FIG.l shows a schematic diagram of a conventional telephone system. FIG. 2 shows a schematic diagram of the digital phone monitoring system of the present invention.

FIG. 3 shows a schematic diagram of a connection between a client telephone of the present invention and a telephony application programming Interface (TAPI).

FIG. 4. shows a schematic diagram of a client telephone of the present invention.

FIG. 5 shows a diagram of a central server in accordance with the digital phone monitoring system of FIG. 2.

FIG. 6 shows an exemplary table of a monitored party database stored on the client telephone 400 of FIG. 4. FIG. 7(A) shows an exemplary table of a client database stored on the central server of FIG. 5.

FIG. 7(B) shows an exemplary DTMF code database stored on the central server of FIG. 5.

FIG. 8 shows an exemplary TCP/IP information database stored on the central server of FIG. 5.

FIG. 9 shows a flowchart of the notification process performed by the central server of FIG. 5.

FIG. 10 shows a flowchart of the registration performed by the central server of FIG. 5. FIG. 11 shows a flowchart of the notification process performed by the central server of FIG. 5.

FIG. 12 shows a flowchart of the queue manager process performed by the central server of FIG. 5.

FIG. 13 shows a diagram of an embodiment of the client telephone of FIG. 4 of the present invention. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The following descπption is of the best presently contemplated mode of carrying out the invention The descπption is made for the purpose of illustrating the general pπnciples of the invention and is not to be taken in a limiting sense The telephone disclosed in the present invention may be configured in accordance with a "plug-and-play" protocol The user of the telephone simply plugs the telephone into a telephone jack The telephone automatically connects to the central server, receives TCP/IP information from the server for future communications and registers the client The client then selects the parties that the client wishes to monitor

The client may select parties to monitor by programming the parties' telephone numbers into the client's local telephone or by a directory lookup by name The client's telephone communicates these telephone numbers to the central server and the central server veπfies that the parties agree to be monitored Once the parties agree, the parties register with the system The client may also select parties to monitor by contacting the service associated with the central server off-line and submitting a request to monitor the specified parties The central service may veπfy the agreement of the parties to be monitored by contacting them off-line (e g , via telephone call, postal mail, e-mail) Alternatively, the process to select parties to monitor may be initiated by the monitored party The party to be monitored submits a request to the central server In return, the central server remotely programs the monitoπng party's telephone with the monitored party's status and identification information It will be appreciated that the monitoπng party may locally program its telephone If the monitored party requests a monitoπng party that is currently not a client to the status monitoπng service, the service contacts the momtonng party off-line to determine if this party wishes to become a client to the service to receive status updates from the monitored party

Referπng first to FIG 2, a schematic diagram of the digital phone momtonng system of the present invention may be generally appreciated It will be appreciated that a preferred embodiment of the present invention defines a first telephone as a monitored client telephone 202, and defines a second telephone as a monitoπng telephone 206 In particular, communication links between three momtonng client telephones 206, a central server 204 and three monitored client telephones 202 are shown Whenever a change in status of a monitored client telephone 202 occurs, monitored client telephone 202 communicates the status change via central server 204 to each monitoπng client telephone 206 registered to receive status updates of that monitored client telephone 202 It will be appreciated that the number of monitored client telephones 202 and monitoπng client telephone 206 shown in FIG 2 were arbitranly chosen, and that alternative embodiments of the present invention may include any number of monitored and any number of monitoπng client telephones One of ordinary skill in the art will understand the benefits of receiving the status of another telephone For example, teenagers may monitor their friends to determine which of their friends' phone lines are busy When a teenager wants to call a friend, pπor to even picking up and dialing the phone, the teenager automatically knows which friends are available to talk The teenager may be presented with a list of friends, so that the teenager can instantly see which ones are available In another example, a mother may want to monitor her home telephone while at work The mother may be interested m determining whether the phone is busy, or may wish to monitor the amount of time that her son, daughter or babysitter is on the phone per day It will also be appreciated that status information may be input at monitored client telephone 202 For example, when a child arπves home, the child may enter a DTMF code into monitored client telephone 202 (e g , *68) The code representing a status update is sent to central server 204 Central server 204 forwards the status information to the child's mother's monitoπng client telephone 206, thereby informing the mother that her child has arπved at home

In another example, a supervisor may monitor when a telecommuting employee or consultant is working For instance, the employee or consultant enters a predetermined code into monitored client telephone 202 when arriving at work Monitored client telephone 202 sends the code to central server 204 Central server 204 searches a DTMF code database 340, as shown in FIG 7(B), retπevmg the status corresponding to the code Once retπeved, central server 204 sends the status to monitoring client telephone 206. The status allows the supervisor to know when to contact the employee or consultant. Alternatively, this invention may provide the supervisor with additional information. For example, accounting and billing processes may calculate the total number of hours the employee worked. Those skilled in the art will recognize that these examples are provided purely for illustrative purposes and should not be understood to limit the breadth of this invention.

Referring now to FIG. 3, a diagram of a Telephony Application Programming Interface (TAPI) 332 connected to monitoring client telephone 206, monitored client telephone 202 and central server 204 may be generally appreciated. Central server 204 includes a plurality of communication applications 302 such as a call control application 304, an interactive voice application 306, a voice mail application 308, a call center application 310, and a TCP/IP conferencing application 312. Central server 204 also includes a registration service 314, a notification service 316, an encryption decryption service 318, a queue manager 320, a start-up/self test service 322, a monitoring service 324, a TCP/IP database 326, a client database 328, a digital signature 336, a call accounting service 338 and a DTMF code database 340. A TAPI interface 330 connects each of the above components to TAPI 332. A detailed description of the services, managers, and databases in conjunction with FIG. 5 will be provided below. As shown, TAPI 332 enables applications to access all the telephony options available on any machine. For example, the communication applications 302 including call control application 304, interactive voice application 306, voice mail application 308, call center application 310 and TCP/IP conferencing application 312 may access all telephony options available on monitoring telephone 206 and monitored client telephone 202. For instance, the applications may access monitored client database 334 stored on monitoring client telephone 206.

The data on a call is available to applications in a standard manner. TAPI 332 is an architecture that provides simple and generic methods for making connections between two or more machines and provides each machine access to any media stream involved in that connection. TAPI 332 abstracts call-control functionality to provide a common interface to applications that utilize different and seemingly incompatible communication protocols. This interface connects monitored client telephone 202 and monitoring client telephone 206 to central server 204.

Referring now to FIG. 4, a diagram of a client telephone 400 of the present invention may be better appreciated. One of ordinary skill in the art will recognize that client telephone 400 may be either a monitoring client telephone 206 or a monitored client telephone 202. Client telephone 400 operates under a multi-tasking, multithreaded operating system platform (e.g., UNIX, or WINDOWS NT by MICROSOFT of Redmond, Washington). As shown, client telephone 400 includes a display device 402, an input device 405, a processor 404 and a data storage device 407. Processor 404 is connected to a communication port 406 (e.g., network interface). Input device 405 may be a keyboard comprising a plurality of DTMF coded buttons. Display device 402 is an LCD or other type of display that shows the status of each party being monitored by client telephone 400, in accordance with the data stored in monitored client database 334. For example, the display shows a name and the cureent status of each party being monitored. It will be appreciated that monitored client telephone 202 might not include display device 402. Communications port 406 provides the network interface to central server 204 using TCP/IP over the D channel on an ISDN telephone line. One of ordinary skill in the art will recognize that the telecommunication specifications are provided purely for illustrative purposes and that alternative embodiments of this invention may include different telecommunication methods.

Data storage device 407 includes a monitoring service 324 that processor 404 executes to provide client digital phone 400 with the monitoring functionality of the present invention. Data storage device 407 also includes a startup/self-test service 410, display manager 412, digital signature 414, encryption/decryption service 416, monitored client database 334, call accounting service 418, a TAPI interface 420, a communications applications 422, a registration service 424, a queue manager 426, a DTMF code database 428, and a notification service 430. The communications applications 422, the registration service 424, the queue manager 426, the DTMF code database 428, and the notification service 430 are utilized by the client telephone 400 in ways similar to those of the conesponding elements of the central server 204, as described below.

Startup/self-test service 410, at startup, tests all hardware of client telephone 400 and loads the operating system and services. If connected via TAPI interface 420 to central server 204, startup occurs when client telephone 400 is powered on. A startup may also occur if a user presses a re-boot key (not shown) located on client telephone 400. Startup/self-test process 410 typically includes three types of tests. It performs a checksum on EPROM, checks the ISDN line to confirm that the link with central server 204 on D and both B channels is up and running, and confirms that a "service provider identification" (SPID) matches the SPID pre-programmed on client telephone 400. A SPID is typically composed of the telephone number of client telephone 400 followed by four additional digits. It will be appreciated that central server 204 assigns client telephone 400 TCP/IP information during the initial connection between client telephone 400 and central server 204, and client telephone 400 subsequently stores that information. It will also be appreciated that, at startup, client telephone 400 sends its TCP/IP information to central server 204, and central server 204 verifies that the TCP/Ip information matches the assigned TCP/IP information of client telephone 400. One of ordinary skill in the art will understand that in addition to ISDN, startup/self-test service 410 may be applied to other types of communication technology.

If client telephone 400 is a monitoring client telephone 206, after startup/self- test service 410 is executed by processor 404, monitoring client telephone 206 requests that central server 204 send status updates of the monitored client telephones 202 that it is authorized to receive. Monitoring client telephone 206 seizes the D channel of the ISDN line and sends its DTMF codes. Central server 204 reads the registration information and routes the call to registration service 314 via a communications (e.g., a DS-1 or DS-3) line. One of ordinary skill in the art will recognize that the demand for communication lines at the time central server 204 transmits the code information determines which line is chosen. Registration service 314 senses the incoming call and causes central server 204 to go off-hook on that line. Once off-hook, registration service 314 opens a communication link between central server 204 and momtonng client telephone 206

Once momtonng client telephone 206 senses that the D channel communication link with central server 204 is established, it builds and encrypts an acknowledgment message with its SPID and a digital signature

Encryption/decryption service 416 of monitoπng client telephone 206 uses the public key of central server 204 to encrypt a message and generate a digital signature bundled with the message Encryption/decryption service 318 of central server 204 uses the pnvate key of central server 204 to decrypt the message and validate the signature The digital signature provides the secunty clearance of monitoring client telephone's 206 identity

If encryption/decryption service 318 of central server 204 successfully decrypts the message and venfies the digital signature of monitoπng client telephone 206, central server 204 sends an acknowledgment (ACK) message and its digital signature back to momtonng client telephone 206 If the venfication fails, server 204 instead sends a no-acknowledgment (NAK) and its digital signature back to momtonng client telephone 206 and drops the line If monitoπng client telephone 206 receives an ACK, it venfies the digital signature of central server 204 If the venfication is a success, momtonng client telephone 206 returns an ACK message to server 204 If the venfication fails, momtonng client telephone 206 returns a NAK message to server 204 and drops the line If the communications between central server 204 and momtonng client telephone 206 resulted in ACKs, a session is established between momtonng client telephone 206 and registration service 314 of central server 204 Registration service 314 quenes client database 328 to confirm that the account of momtonng client telephone 206 is in good standing Although not shown, a preferred embodiment of chent database 328 may include client billing and account information It will be appreciated that the telephone company will typically provide the status momtonng service only to clients that have paid their telephone bills Registration service 314 then sends a clear to send (CTS) message to momtonng client telephone 206 that it is ready and waiting Momtonng client telephone 206 receives the message and creates and sends a monitor message (MM) to registration service 314 Registration service 314 receives the message and quenes client database 328 to obtain the current status of the monitored client telephones 202 that momtonng chent telephone 206 is authonzed to receive Alternatively, the message from monitoπng client telephone 206 may include a request for a status update of specific monitored client telephones 206

After entering the appropπate status information into a message, registration service 314 uses the public key of momtonng client telephone 206 to encrypt the message, and return the message Monitoπng client telephone 206 receives the message and decrypts it with its pnvate key

Monitoring chent telephone 206 then updates monitored client database 334 and displays the status of each party Monitoπng client telephone 206 then sends a message to registration service 314 of central server 204 acknowledging successful receipt of the status updates Call accounting service 338 updates client database 328 to bill for the successful inquiry and drops the session by cleaπng the channel

Momtonng chent telephone 206 recognizes that the channel is down and enters into a wait state until notification service 316 sends it updated status information One of ordinary skill in the art will recognize that once momtonng client telephone 206 restarts and resets with status updates of monitored client telephones 202, momtonng client telephone 206 begins to automatically receive status updates without the need to poll central server 204

Monitored chent database 334 includes monitoπng information stored on storage device 407 of client telephone 400 See FIG 6 for an exemplary view of monitored client database 334 As shown, the momtonng information includes monitored client SPID 602, monitored chent name 604 and status 606 of the monitored client It will be appreciated that alternative embodiments of this invention may include other vaned types of monitoπng information For example, monitored client database 334 may also include information such as total number of hours a monitored phone is busy, or total number of hours that a monitored telephone of an employee had an associated status of "working" Display manager 412 accesses monitored client database 334, and displays this information on display device 402 of client telephone 400. Display manager 412 may also display messages originating from central server 204. For example, display manager 412 may receive and display messages from central server 204 during registration of client telephone 400.

Digital signature 414 provides client digital telephone 400 with the ability to verify the identity of a sender of TCP/IP message packets by creating and utilizing private and public keys. Digital signature 414 is included with encrypted messages sent between client telephone 400 and central server 204. At client telephone 400, the recipient's public key is used to encrypt a message and generate a digital signature string that is bundled therein. Upon receipt of the message, the recipient, such as central server 204 or another client telephone 400, uses its private key to decrypt the message and validate the signature. Validating the signature verifies the message sender's identity. Call accounting service 418 on client telephone 400 maintains up-to-date billing information. For example, call accounting service 338 of central server 204 sends telephone usage and billing updates to client's telephone 400 and stores the updates on storage device 407. In response to a subscriber's request, display manager 412 accesses and displays the information on display device 402. It will be appreciated that central server 204, in an embodiment of this invention, routinely initiates the transmission of accounting information to call accounting service 418. In still another embodiment, call accounting central service 418 retrieves telephone usage and billing updates from central server 204 in response to a request from the subscriber of client telephone 400. Referring now to FIG. 5, a diagram of central server 204 of the present invention may be better appreciated. Central server 204 operates under a multitasking, multithreaded operating system platform (e.g., UNIX, or WINDOWS NT by MICROSOFT of Redmond, Washington). As shown, central server 204 includes an input device 502 (e.g., CD ROM or floppy disk drive, keyboard), processor 504 connected to a communications port 506, and a storage device 507. Communications port 506 provides a network interface, using TCP/IP over the D channel on an ISDN telephone line to connect central server 204 to monitored client telephone 202 and to momtonng client telephone 206 One of ordinary skill in the art will recognize that the telecommunication specifications are provided purely for illustrative purposes, and that alternative embodiments of this invention may include different types of telecommunication methods

Storage device 507 includes momtonng service 324, TAPI interface 330, encryption/decryption service 318, start-up/self-test service 322, queue manager 320, notification service 316, registration service 314, chent database 328, TCP/IP information database 326, communication applications 302, call accounting service 338, digital signature 336 and DTMF code database 340 Momtonng service 324 provides central server 204 the momtonng process in accordance with the present invention TAPI interface 330, as discussed above, enables applications, such as momtonng service 324, to access all the telephony options available on any client telephone. For example, it provides monitoring service 324 with access to updated monitored client database 324 stored on client telephone 400

Encryption/decryption service 318 employs pnvate and public keys to respectively decrypt and encrypt messages that are sent to client telephone 400 This process also employs a digital signature 336 to venfy the message sender's identity Central server 204 receives a digital stπng encrypted with a message from client telephone 400 Upon receipt of the message, central server 204 uses its pnvate key to decrypt the message and validate digital signature 336 Similarly, when central server 204 sends a message to client telephone 400, central server 204 utilizes the public key of client telephone 400 to encrypt the message and generate a digital signature stnng that is bundled therein Client telephone 400 uses its pnvate key to decrypt the message and validate the server's identity

Startup/self-test service 322 initializes all components at startup and checks predetermined parameters when booting up Tests include confirming that the ISDN line over D and both B channels that connect central server 204 and client telephones 400 is operating within predetermined parameters, and verifying that incoming messages to central server 204 are ongmated from authonzed SPIDs For example, at startup, startup/self-test service 410 of client telephone 400 sends a SPED venfication message to central server 204 Startup/self-test service 322 of central server 204 verifies that the SPID is authonzed to receive momtonng information

Registration service 314 registers monitored client telephones 202 and momtonng client telephones 206, and maintains a list of current accounts and a list of the active connections between subscnbers Registration service 314 stores the list of current accounts on client database 328 and stores the list of active connections on TCP/IP information database 326 FIG 7 shows an example of client database 328, and FIG 8 shows an example of TCP/IP information database 326

If the status of monitored client telephone 202 changes, notification service 316 receives a status information update Notification service 316 notifies queue manager 320 to transmit the status update to the appropπate momtonng client telephones 206 Queue manager 320 receives notification of the status change from notification service 316, quenes client database 328 for the appropπate SPID(s) to contact, and transmits an indication of the change in status to the authorized clients designated by the appropπate SPID(s)

Call accounting service 338 maintains and sends billing information m real time to each client More particularly, call accounting service 338 sends accounting and billing information in update packets to the client's telephone either (l) peπodically (e g , daily), or (2) m response to a client request Accordingly, a client can always view m real time the specific charges associated with a call or view the running total for monthly bill It will be appreciated that call accounting service 418 employed by client telephone 400 provides a subscnber with numerous functions for viewing and processing specific charges

Referring now to FIG 6, a diagram of an exemplary monitored client database 334 stored withm momtonng client telephone 206 may be better appreciated As shown, each entry of monitored client database 334 specifies a monitored client telephone 202 that is assigned to send status information to a momtonng client telephone 206 In an exemplary embodiment of the present invention, monitored client database 334 includes, for each party being monitored, a monitored client SPID 602, a monitored client name 604, and the current status 606 of monitored client telephone 202 It will be appreciated that for a given monitored client SPED 602, monitoring client telephone 206 may monitor more than one status For example, the last entry 607 of monitored client database 334 includes more than one status

A number of methods are available to enter data into monitored client database 334 For example, m one method, a client using input device 405 locally inputs monitored client SPIDs 602, and corresponding monitored client names 604 into monitored chent database 334 In an alternative method, central server 204, in response to a request from momtonng chent telephone 206, remotely updates the SPIDs of monitored client database 334

A chent requests status momtonng by either calling a telephone company's toll-free number to verbally request momtonng, or by electronically submitting a request via an Interactive Voice Response (IVR) unit It will be appreciated that a Voice Response Unit (VRU) may also be used However, before momtonng of a particular SPID occurs, central server 204 must receive permission from the party at monitored chent telephone 202 The central telephone office requests permission by electronically sending a request via central server 204 to monitored client telephone 202, or by contacting the party using another method Other methods may include, for example, a telephone call, an e-mail, or a letter If central server 204 receives permission, it sends an authonzmg signal to momtonng chent telephone 206 Once authonzed, momtonng client telephone 206 receives status updates from central server 204, and enters the updates into monitored party database 334 Display device 402 of the monitoring client telephone 206 displays each status update 606

Alternatively, monitored client telephone 202 may initiate the request to be monitored by momtonng client telephone 206 When central server 204 electronically receives the request, or the central telephone service receives the request using another manner, the service requests permission to send momtonng client telephone 206 status updates of monitored client telephone 202 As discussed above, the request for permission may be electronically submitted by central server 204 or provided using another manner

It will be appreciated that a subscnber at momtonng client telephone 206 may monitor a status change of a particular predetermined condition For example, a subscnber may choose to monitor the "busy" status of monitored client telephone 202 Alternatively, a subscriber may choose to monitor when the person at monitored client telephone 202 enters a DTMF code indicative of a working status. One of ordinary- skill in the art will recognize that these examples are purely illustrative of different status changes, and that alternative embodiments of the present invention may include status changes of other predetermined conditions.

Referring now to FIG. 7(A), a diagram of an exemplary client database 328 stored on central server 204 may be better appreciated. As shown, this database includes entries for each monitored client telephone 202 that is registered with central server 204. Each entry includes the party being monitored, identifiable by monitored client SPED 702, the party receiving the status updates, identifiable by monitoring client SPID 704, and the particular status changes monitoring client telephone 206 will receive, shown as monitored status 706 and a cunent status 708. It will be appreciated that the current status 708 of an entry of client database 328 may include more than one status. The process of updating and maintaining client database 328 will be discussed in conjunction with the description of the registration process shown in FIG. 9.

Referring now to FIG. 7(B), a diagram of exemplary DTMF code database 340 stored at central server 204 may be better appreciated. As shown, this database includes a status 714 assigned to each DTMF code 712. Notification service 316 of central server 204 uses DTMF code database 710 to translate incoming DTMF codes to an appropriate status. It will be appreciated that a DTMF code may represent information other than a status. For example, a DTMF code may represent a request for billing information.

Referring now to FIG. 8, a diagram of exemplary TCP/IP information database 326 stored at central server 204 may be better appreciated. As shown, this database includes entries for each client telephone 400 registered with central server 204. Each entry includes a SPID address 802 and a corresponding TCP/IP address 804. A TCP/IP address information 804 is issued to each client telephone 400 registered with central server 204. It will be appreciated that central server 204 communicates with other nodes and clients based on their assigned TCP/IP address 804. One of ordinary skill in the art will recognize that the header portion of messages sent between monitored and monitoring client telephones 400 and central server 204 typically include a TCP/IP address 804. When receiving or sending a message, central server 204 uses the SPID address 802 listed in the TCP/IP database 326 to verify that the TCP/IP address included within the message's header portion is correct. Referring now to FIG. 9., a flowchart of a status monitoring process 900 of the present invention may be generally appreciated. As shown, in step 902, central server 204 registers the subscriber of monitoring client telephone 206. In step 904, the subscriber of monitoring client telephone 206 selects the parties the subscriber wishes to monitor. In step 906, central server 204 registers the parties to be monitored. It will be appreciated that prior to registering these parties, central server 204 requests each party's permission to be monitored by the subscriber of monitoring client telephone 206. In step 908, central server 204 receives TCP/IP packets from monitored client telephone 202. In step 910, central server 204 transmits the TCP/IP packets to the monitoring client telephone 202 configured to receive the status updates. Once received, monitoring client telephone 206 displays the status to the subscriber. One of ordinary skill in the art will recognize that FIG. 9 shows the general steps of the present invention, and that Figs. 10-12 described below will explain each step in greater detail.

It will be appreciated that in alternative embodiments of the present invention, monitored client telephone 202 may register prior to monitoring client telephone 206. Furthermore, monitored client telephone 202 may select the parties that it wishes to provide status updates. Prior to sending the status updates, monitoring client telephone 206 must register and provide central server 204 of the central telephone permission to receive the status information. When a party at a client telephone 400 wishes to register as a subscriber of a monitored client telephone 202 in step 906, or as a monitoring client telephone 306 in step 902, client telephone 400 seizes the D channel of the ISDN line and sends the registration information to central server 204 of a telephone station's central office. Central server 204 reads the registration information and routes the call to registration service 314 via a DS-1 or DS-3 line. One of ordinary skill in the art will recognize that the demand for communication lines at the time central server 204 transmits the code information determines which line is chosen. Registration service 314 senses the incoming call and central server 204 goes off-hook on that line. Once off-hook, registration service 314 opens a communication link between central server 204 and the party wishing to register. Referring now to FIG. 10, the registration process performed by registration service 314 of central server 204 may be better appreciated. In step 1002, registration service 314 receives a request from a registering client telephone 400 for a TCP/IP address and a security clearance. The security clearance process utilizes a digital signature and encryption to secure the messages sent between client telephone 400 and central server 204. More particularly, once client telephone 400 senses that the D channel communication link with central server 204 is established, it builds and encrypts an acknowledgment message with its SPID and a digital signature.

Client Telephone 400 uses a public key of central server 204 to encrypt a message and generate a digital signature bundled with the message. The recipient of the message uses its private key to decrypt the message and validate the signature. The digital signature provides the security clearance of the message sender's identity. It will be appreciated that all communications between central server 204 and client telephone are encrypted and include a digital signature.

At registration, if encryption/decryption service 318 decrypts the message and verifies the digital signature of client telephone 400, central server 204 sends an acknowledgment (ACK) message and its digital signature back to client telephone 400. If the verification fails, central server 204 instead sends a no-acknowledgment (NAK) and its digital signature back to client telephone 400 and drops the line. If client telephone 400 receives an ACK, it verifies the digital signature of central server 204. If the verification is a success, client telephone 400 returns an ACK message to central server 204. If the verification fails, client telephone 400 returns a NAK message to central server 204 and drops the line. If these communications resulted in ACKs, a session is established between client telephone 400 and registration service 314 of central server 204. In step 1004, registration service 314 receives a SPID/MAC (Media Access

Control Layer) address from registering client telephone 400. It will be appreciated that the SPID/MAC was either pre-programmed into registenng chent telephone 400 or was previously assigned by central server 204 In step 1006, registration service 314 checks the SPED/MAC format In step 1008, if the format is mconect, registration service 314 sends an "unable to process request" message to client telephone 400 If the format is conect, in step 1010, registration service 314 issues client telephone 400 a TCP/IP address

In step 1012, registration service 314 stores the SPID of client telephone 400 into the appropπate field of client database 522 If client telephone 400 is a monitored client telephone 202, registration service 314 stores the SPLD as a monitored client SPID 702 If client telephone 400 is a monitoring client telephone 206, registration service 314 stores the SPID as a monitoπng client SPID 704 In step 1014, registration service 314 stores the SPID address and the conespondmg TCP/IP address in TCP/IP address database 326 Once client database 328 and TCP/IP address database 326 are updated, registration service 314 sends a registration acknowledgment message back to client telephone 400 indicating that it is now registered

After client telephone 400 registers as a monitoπng client telephone 206, in step 904, the subscnber of client telephone 400 selects one or more parties that the subscnber wishes to monitor. At monitonng client telephone 206, the subscnber may enter each parties' phone number into monitored client database 334, where each parties phone number is mapped to a SPID Once entered, monitonng client telephone 206 sends these telephone numbers to registration service 314 Alternatively, the subscnber may also select parties to monitor by contacting the service associated with registration service 314 off-line, and submitting a request to monitor the specified parties

Once registration service 314 receives the request to monitor one or more parties, registration service 314 venfies that the parties agree to be monitored If a party is a cunent subscnber of the status monitonng service, registration service 314 of central server 204 may electronically send the permission request directly to that party's client telephone 400 Alternatively, if a party is not a cunent subscnber, the central service may venfy that the party agrees to be monitored by contacting that person off-line (e g , via telephone call, postal mail, e-mail)

If the party agrees to be monitored by the subscnber of monitonng client telephone 206, in step 906, registration service 314 registers the monitored party which the subscnber selected It will be appreciated that if the party agrees to be monitored and does not cunently included as an entry withm the TCP/IP information database 326 of central server 204, registration service 314 registers this party by performing the steps of the registration process descnbed above and shown m FIG 10 For all monitored parties, registration service 314 updates client database 328 with each party's monitored client SPID 702 , the status 706 being monitored, and the monitonng client SPID 704 of the subscnber who will receive the status updates of the monitored client

Once client database 328 and TCP/IP information database 326 includes the appropnate identifiers assigned to each new party to be monitored, registration service 314 sends an indication to monitoπng client telephone 206 that the parties agreed to be monitored and are registered at central server 204 It will be appreciated that a number of methods exist to update monitonng client telephone 206 with the SPEDs of the parties that will be monitored For example, in one method, central server 204, in response to a request from monitonng client telephone 206, remotely updates monitored client database 334 with the SPIDs 602 and the conespondmg monitored client names 604 In an alternative method, the subscnber locally inputs monitored client SPIDs 602, and conespondmg monitored client names 604 into monitored client database 334

Referπng now to FIG 11 , a notification process 1100 performed by notification servrce 316 of central server 204 may be better appreciated Once registration service 314 registers the momtonng and monitored parties, monitored client telephone 202 automatically sends status updates via central server 204 to the subscnber of monitoπng client telephone 206 Monitored client telephone 202 sends each status update in a TCP/IP packet when its status changes It will be appreciated that the status change may be a DTMF code entered by the monitored party into monitored client telephone 202 For example, a party when working may enter a DTMF code It will also be appreciated that when a first monitored party initiates a call to a second monitored party, monitored client telephone 202 of the first monitored party will submit status updates of both parties to central server 204 Furthermore, the status update may show that the first monitored party is electronically connected to the second monitored party

Pnor to sending a packet of status updates, monitored client telephone 202 uses a public key of central server 204 to encrypt and provide a digital signature within the TCP/IP packet In step 1102, notification service 316 of central server 204 receives the encrypted TCP/IP packet from monitored chent telephone 202 Notification 316 service uses the pnvate key to decrypt and venfy the packet's digital signature Notification service 316 also compares the SPID and TCP/IP address information provider in the header portion of the TCP/IP packet to the appropnate entry in the TCP/IP database 326 to venfy the source of the status update Once the source of the update is venfied, notification service 316 stores the status to cunent status 708 of the appropπate record(s)

In step 1104, notification service 316 quenes client database 328 to retneve a record that includes monitored client telephone 202 In step 1106, notification service 316 determines if this record applies to the status update it received More specifically, it determines if this status update conesponds to the status information that monitonng client telephone 206 is configured to receive If the status conesponds, m step 1110, notification servrce 316 transmits the TCP/IP packet to queue manager 320 If the status does not conespond, in step 1108, notification service 316 determines if there is another record conespondmg to monitored chent telephone 202 If there is another record, notification service 316 determines if this record applies to the status update it received from monitored client telephone 202 It will be appreciated that this process continues until notification servrce 316 reviews all records of client database 328 that apply to monitored client telephone 202 Once the review of client database 328 records is completed, in step 1112, notification process 1100 ends Referring now to FIG 12, a queuing process 1200 performed by queue manager 320 of central server 204 may be better apprecrated The process begms m step 1202 when queue manager 320 receives a TCP/IP packet from notification service 316. This packet includes a status update, and an origin and a destination SPID of respective monitored client telephone 202 and monitoring client telephone 206. In step 1204, queue manager 320 retrieves from TCP/IP address database 326 the TCP/IP address of monitoring client telephone 206 that conesponds to the destination SPED. In step 1206, queue manager 320 transmits the TCP/IP packet to the TCP/IP address of the appropriate monitoring client telephone 206. In step 1208, if monitoring client telephone 206 successfully received the TCP/IP packet, queue manager 320 receives an acknowledgment of the successful transmission. Queue manager 320 updates client database 328 for billing purposes and drops the session with monitoring client telephone 206.

It will be appreciated that all communications between central server 204 and each client may be encrypted. For example, the TCP/IP information that monitoring client telephone 206 receives is encrypted. Monitoring client telephone 206 uses its private key to decrypt and access the status update provided in the TCP/IP packet. Of course, one of ordinary skill in the art will understand that the communications do not necessarily have to be encrypted. Monitoring client telephone 206 updates monitored client database 334 with the status update. Display manager 412 of monitoring client telephone 206 displays the status update on display device 402. Accordingly, the subscriber of monitoring client telephone 206 is capable of monitoring the status of the parties of monitored client telephones 202 without even picking up the telephone. Referring now to FIG. 13, an embodiment of client digital phone 400 of FIG. 4 may be better appreciated. As shown, client digital phone 400 includes a handset 1302, an LCD display 1304, DTMF buttons 1306, extension status indicators 1308 and a volume control 1310. The screen of sample LCD display 1304 shows the cunent status of the parties of monitored client telephones 202. One of ordinary skill in the art will recognize that the four parties shown on LCD display 1304 are purely illustrative of the status information provided to subscribers, and that any number of parties of monitored client telephones 202 may be displayed. If the number of monitored parties requires more display space than is available on LCD display 1304, the status entries may continuously scroll. Alternatively, client telephone 400 may include scrolling buttons, that allow a subscriber to scroll though pages of client digital phones 400 that are being monitored

It will be appreciated that an alternative embodiment of the present invention may utilize the Internet to transfer status information of a pre-selected list of frequently called telephone numbers from central server 204 of the central service to the party of monitonng client telephone 206 In this embodiment, central server 204 receives status mformatron as descnbed above, but instead of sending the information to monitonng client telephone 206, central server 204 posts the status information to the monitoπng party's web page account One of ordinary skill in the art will recognize that central server 204 may compnse a plurahty of devices that are located m numerous geographical regions Such devices would communicate with each other for the purpose of transmitting status update packets between different geographic regions Accordingly, each device includes in its client database, records of all monitored and monitonng clients from all regions When a device is notified of a status change of a monitored party, it transmits the status update packet to the device servicing the region where the monitonng party is located In one embodiment for the present invention, each local region may include one device

It will be appreciated that unique separate servers may support each region by communicating with each other. It will be further apprecrated that a srngle server may support multiple regions or may be distnbuted across multiple regions

It can therefore be apprecrated that a new and novel drgrtal phone status monrtor has been descnbed It wrll be appreciated by those skilled m the art that, given the teaching herein, numerous alternatives and equivalents will be seen to exist which incorporate the mventron drsclosed hereby As a result, the invention is not to be limited by the foregoing exemplary embodiments, but only by the following claims

Claims

We claim:

1. A method for tracking a status of a first telephone over a telephony network, the method comprising the steps of: sending a request to monitor the first telephone; receiving authorization to monitor the first telephone; receiving the status of the first telephone; and storing the status of the first telephone.

2. The method of claim 1, further including the step of: receiving an identifier of the first telephone that identifies a party to be monitored.

3. The method of claim 2, further including the step of: storing the identifier of the first telephone.

4. The method of claim 1, further including the step of: sending a request to register a second telephone, wherein the request includes a digital signature and an identifier that identifies the second telephone.

5. The method of claim 4, further including the step of: receiving an indication of successful registration of the second telephone.

6. The method of claim 1, further including the step of: decrypting the received status with a private key.

7. The method of claim 1 , further including the step of: sending an indication acknowledging successful receipt of the status.

8. The method of claim 1, further including the step of: displaying the status of the first telephone.

9. A method for tracking a status of a first telephone over a telephony network, the method comprising the steps of: receiving a request from a second telephone to monitor the first telephone; requesting authorization from the first telephone to send the status to the second telephone; receiving the authorization to send the status to the second telephone; receiving the status from the first telephone; and sending the status to the second telephone.

10. The method of claim 9, further including the steps of: storing a first identifier that identifies the first telephone and a second identifier that identifies the second telephone; and sending the first identifier to the second telephone.

11. The method of claim 9, further including the step of: verifying good standing of a customer account of the second telephone.

12. The method of claim 9, further including the steps of : receiving a request to register the second telephone, wherein the request includes a digital signature and a second identifier that identifies the second telephone; registering the second telephone; and registering the first telephone.

13. The method of claim 12, wherein the receiving step further includes the steps of: receiving a request for a second network address and a security clearance from the second telephone;

14. The method of claim 12, wherein the step of registering the first telephone further includes the steps of: issuing the first telephone a first network address; and stonng the second network address and the conespondmg first identifier

15. The method of claim 12, wherein the step of registenng the second telephone further includes the steps of veπfying the digital signature; issuing the second telephone a second network address; and stonng the second network address and the conespondmg second identifier

16. The method of claim 9, further including the step of: sending the first identifier to the second telephone for storage and display

17. The method of claim 9, wherein the step of receiving a request includes receiving a request to notify the second telephone when a status change of a predetermined condition of the first telephone occurs.

18. The method of claim 17, further including the step of: stonng the status change of the predetermined condition with the conesponding first identifier and the conespondmg second identifier.

19. The method of claim 9, further including the step of determining if the second telephone rs authonzed to receive the status of the first telephone.

20 The method of clarm 9, further including the step of: encrypting the status wrth a public key before sending the status to the second telephone.

21 The method of claim 9, further including the step of: recording transmission of the status to the second telephone's customer account.

22. The method of claim 9, wherein the status indicates whether the first telephone is off-hook.

23. The method of claim 9, wherein the status indicates whether a user of the first telephone has entered at least one predetermined DTMF code into the telephone.

24. The method of claim 9 further including the step of: receiving an acknowledgment from the second telephone of a successful transmission of the status.

25. A method for tracking a status of a first telephone over a telephony network, the method comprising the steps of: receiving a request to be monitored by a second telephone; sending authorization to monitor the first telephone; and sending the status to a server.

26. The method of claim 25, further including the step of: sending a request to register the first telephone, wherein the request includes a digital signature and a first identifier that identifies the first telephone.

27. The method of claim 26, further including the step of: receiving an indication of successful registration of the first telephone.

28. The method of claim 25, further including the step of: encrypting the sent status with a public key.

29. The method of claim 25, further including the step of: receiving an indication acknowledging successful receipt of the status.

30. A method for tracking a status of a first telephone over a telephony network, the method comprising the steps of: receiving a status change signal from a first telephone; determining a second telephone associated with the first telephone; and transmitting the status change signal to the second telephone.

31. The method of claim 30, wherein the status change signal is triggered by an off-hook signal of the first telephone.

32. The method of claim 30, wherein the status change signal is triggered by at least one DTMF code being entered into the first telephone by a user.

33. The method of claim 32, wherein the at least one DTMF signal is intermittent.

34. A system for tracking a status of a first telephone over a telephony network, the system comprising: a monitor request service for sending a request to monitor the first telephone; a communication interface coupled to the monitor request service for receiving authorization to monitor the first telephone; and a database manager coupled to the communication interface for storing the status of the first telephone.

35. The system of claim 34, wherein the monitor request service receives an identifier of the first telephone that identifies a party to be monitored.

36. The system of claim 34, wherein the monitor request service stores the identifier of the first telephone.

37. The system of claim 34, wherein the monitor request service sends a request to register a second telephone, wherein the request includes a digital signature and an identifier that identifies the second telephone.

38 The system of claim 34, wherein the monitor request service receives an indication of successful registration of the second telephone

39 The system of claim 34, further compπsmg a decryption service for decrypting the received status with a pnvate key

40 The system of claim 34, further compnsmg a display manager for drsplaymg the status of the first telephone

41 A system for tracking a status of a first telephone over a telephony network, the system compnsmg a communications interface for receiving a request from a second telephone to monitor the first telephone, a registration service coupled to the communications interface for requesting and receiving authonzation from the first telephone to send the status to the second telephone, a notification service coupled to the registration service for recervmg the status from the first telephone; and a queue manager coupled to the notrficatron servrce for sending the status to the second telephone

42 The system of claim 41, wherein the registration service stores a first identifier that identifies the first telephone and a second identifier that identifies the second telephone, wherein the registration service sends the first identifier to the second telephone

43 The system of claim 41, further compnsmg an accounting engine for recording and billing for the status sent to the first telephone

44 A system for tracking a status of a first telephone over a telephony network, the system compnsmg a communication interface for receiving a request to be monitored by a second telephone, a monitor request service coupled to the commumcatron interface for sendmg authonzation to monitor the first telephone, and a status communrcator coupled to the communrcatron interface and monitor request engine for sendmg the status to a server

45 A system for trackmg a status of a monitored telephone over a telephony network, the system compnsmg a notification service for receiving a status change signal from a first telephone and for determining a second telephone associated with the first telephone, and a queue manager coupled to the notification servrce for transmrttmg the status change signal to the second telephone

46 The system of claim 45, wherein the notification engine receives the status change signal when the signal is tnggered by an off-hook signal of the first telephone

47 The system of claim 45, wherein the notification service receives the status change signal when the signal is tnggered by at least one DTMF digit being entered into the first telephone by a user

48 The system of claim 45, wherein the notification engine intermittently receives the at least one DTMF signal

49 A computer-readable medium encoded with instructions for directing a processor to receive a request from a second telephone to monitor the first telephone, request authonzation from the first telephone to send the status to the second telephone, receive the authonzation to send the status to the second telephone, receive the status from the first telephone, and send the status to the second telephone.

50. A computer-readable storage medium encoded with instructions for directing a processor to: receive a status change signal from a first telephone; determine a second telephone associated with the first telephone; and transmit the status change signal to the second telephone.