Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/54—Interprogram communication
  • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

• the invention relates to distributed processing systems. More particularly, the invention relates to distributed processing systems which incorporate a plurality of processing zones (referred to herein as "cells"), each cell processing information in response to a type of event, and each cell communicating with other cells according to an event-reaction protocol as well as according to other protocols such as streaming, broadcast, etc..
• Cells exhibit a symmetrical and reciprocal relationship, with cells sometimes being a controller of other cells and sometimes being controlled by other cells.
• the system is self-configuring, self-repairing, and operates in real time.
• So-called “distributed processing” or “parallel processing” systems generally employ multiple processors in order to speed the execution of a single program or to enable the simultaneous execution of several programs.
• Distributed processing embraces almost any computing system where processing of data occurs in more than one CPU.
• a simple example of distributed computing is printing from a PC to an image processing printer which has its own processor. The task of printing is distributed between the processor in the PC and the processor in the printer.
• the distribution of tasks is controlled by a central controller processor.
• intelligence is not distributed. The "intelligence" to decide how processes will be distributed remains centralized and limited.
• U.S. Patent Number 5,095,522 to Fujita et al. discloses an object-oriented parallel processing system which utilizes "concept objects" and "instance objects".
• the system utilizes a host processor and a plurality of general purpose processors which are programmed by the host processor.
• the host user must program (generate concept and instance objects) for each processor before parallel processing can begin.
• Fujita et al. considers this aspect of their system to be a feature which allows dynamic changes in the functionality of each of the processors However, this aspect of their system greatly complicates the host processor software
• U S Patent Number 5,165,018 to Simor desc ⁇ bes a system in which ' nodes" are provided with gene ⁇ c configuration rules and are configured at runtime via resource definition messages from the control node Simor considers this aspect of his system to be an advantage which, among other things, "isolates the hardware from the software' and “allows programs to be w ⁇ tten as if they were going to be executed on a single processor " In addition, Simor's system permits programs to be "distributed across multiple processors without having been explicitly designed for that purpose "
• Fujita et al and Simor utilize general purpose processors and attempt to isolate the hardware from the software, freeing the programmer to write code as if it were being executed on a single processor
• w ⁇ ting multithreaded software for a single processor is very complex Neither Fujita et al nor Simor offer any solution for this complexity
• each node (each object oriented processor array) is aware of network traffic; and data events related to a particular target (host) receiver are registered with all nodes which have that receiver as a target as well as with the target.
• the number of data events which may be simultaneously pending at any time is determined by the target and known to each of the nodes.
• the target arbitrates the flow of messages based on the registration of data events.
• the distributed processing system of the present invention includes a plurality of cells where each cell processes information in response to a type of event, and cells communicate with each other according to a variety of protocols including an (asynchronous) event-reaction protocol. Processing is truly distributed in that no cell is considered the system host or system controller. The cells exhibit a symmetrical and reciprocal relationship with cells sometimes being a controller of other cells and sometimes being controlled by other cells.
• each cell is responsive to a single event and includes one or more scripts which are executed upon the occurrence of the event. At least some scripts include directions to send information to one or more scripts in another cell.
• information exchanged between cells is categorized into the following types which are listed in descending order of priority: streams, data events, data event acks, spawn process, spawn process begun, spawn process ended, exception, and broadcast.
• the cells of the invention may communicate with each other via a shared memory or via a communications bus.
• a scalable bandwidth bus such as that described in co-owned previous application Serial Number 08/645,262, filed May 13, 1996. now U.S. Patent Number 5.922.061. is an ideal communications path for the cells of the invention.
• the communications protocol utilized by the cells enables the use of virtually any networking medium.
• cells may reside in the same chip or may be separated from each other by thousands of miles.
• a collection of interacting cells is referred to as a colony, regardless of where the cells are located, and a collection of cells which are closely located, e.g. on the same board, are referred to as a node.
• each cell may be embodied in hardware, software, or a combination of hardware and software. No cell or colony need be considered a "host".
• each cell is provided with a collection of synchronous (non-colliding) scripts which respond to a single type of event. All scripts have addresses and the addresses of all of the scripts in the processing system are kept in a database by a resource manager script in each cell. Applications are created by linking available scripts via their respective addresses. As all scripts are driven by particular events, the code written for the distributed processing system of the invention does not require My explicit scheduling.
• the processing system is essentially self-scheduling and real time applications can run concurrently without mterfe ⁇ ng with each other
• sc ⁇ pts communicate with each other by dynamically compiling and tea ⁇ ng down mailing lists which are based on the occurrence of specific events
• a responding sc ⁇ pt will communicate with one set of other sc ⁇ pts
• the responding script will communicate with a different set of other sc ⁇ pts Scripts subscribe to and unsubscribe from the mailing lists of other scripts based on the occurrence of different events
• cells advertise their presence in the network when connected, and pe ⁇ odically thereafter, in order that other cells be able to take advantage of their resources
• each cell periodically (e g every second) updates its database of sc ⁇ pt addresses which represent the functionality of the system to accommodate the addition of new cells to the system and to accommodate for cells which have become disconnected from the system or which have stopped functioning for some reason
• a processing system according to the invention is readily expanded to include new and additional processing resources which are substantially automatically assimilated into the system
• the processing system is, in this sense, self-configu ⁇ ng and self-repairing
• communication among cells is effected with the aid of maihng lists such that data may be multicast from one cell to many cells
• the mailing lists are preferably dynamically set up and torn down depending on the execution of sc ⁇ pts which direct the flow of data throughout the system
• the mailing lists are updated as new cells are added to and old cells are removed from the system as part o ⁇ the self-configu ⁇ ng and self-repai ⁇ ng functionality of the system
• PBX telephone p ⁇ vate branch exchange
• the cells communicate with each other via the same physical medium through which the telephones are coupled to subsc ⁇ ber lines
• Each line card and phone card is considered a node, each having a number of cells
• Cells in the phone cards include, for example, cells responding to the following events phone off hook, DTMF tone dialed, ring detected, etc
• Examples of sc ⁇ pts executed in response to events include, generate dial tone, send ⁇ nging signal, seize subsc ⁇ ber line, etc
• each of the cards advertises its presence to the other cards on a regular basis
• the knowledge of the presence of cards (nodes) in the system is used to build mailing lists when, for example, a conference call is made, or when the system is programmed so
• Figure 1 is a high level schematic diagram of a local node of cells coupled to two remote nodes via an external bus;
• Figure 2 is a high level schematic diagram illustrating the lines of communication among scripts in a processing system according to the invention
• Figure 3 is a high level schematic diagram of the buffering of messages between scripts and the network interface cells
• Figure 4 is a flow chart illustrating the processing of messages by a network interface receiver cell
• Figure 5 is a flow chart illustrating the processing of messages by a network interface transmitter cell
• Figure 6 is a high level schematic diagram illustrating the flow of messages from cells across the network to other cells
• FIG. 7 is a high level schematic diagram of a distributed processing system according to the invention illustrated with reference to a telephone private branch exchange (PBX); and
• PBX telephone private branch exchange
• Figure 8 is a simplified flow chart illustrating a simple operation of the PBX of Figure 7.
• the Appendix is a collection of program listings in C language source code for implementing the PBX described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• a distributed processing system 10 includes a plurality of cells (or processing zones), e.g. 12, 14, 16, 18, 20. Each cell is responsive to a particular event and responds to the event by executing one or more scripts.
• the cells 14, 16, 18, 20 shown in Figure 1 are each depicted as having four executable scripts 14a-d, 16a-d, 18a-d, 20a-d.
• the cell 12 has only one script 12a.
• each cell is shown to have a "dispatcher" 12e, 14e, 16e, 18e, 20e which interprets the event and causes scripts to be executed in response to the event.
• the cells 12, 14, 16, 18, 20 shown in Figure 1 are related to each other spatially and are conveniently referred to as a "node" which is delineated by the box 22.
• the cells 12, 14, 16, 18, 20 in the node 22 are coupled to each other by either a bus or a shared memory or other communications means which is described in more detail below with reference to Figure 2.
• data enter and leave cells via buffers 12aB, 12eB, 14aB, 14cB, 16eB, 18bB, 18eB, 20aB, 20eB.
• the spatially related cells in node 22 may be coupled to cells in other remote nodes 24, 26 by way of an external bus 28.
• a collection of cells which interact with each other is referred to as a colony, regardless of the physical location of the cells.
• cells 16, 18, and 20 are respectively responsive to a particular. locally perceived, external event 30, 32, 34.
• external event 30, 32, 34 examples include keypad inputs, switch positions, ADC signals, etc.
• a keypad event 30 is interpreted by the dispatcher 16e which triggers one or more scripts 16a-16d depending, for example, on which keys are pressed.
• the cell 14 is a "network interface receiver" and is responsive to message events received via the external bus 28.
• a cell in a remote node e.g. 24, 26, executes a script which sends a message to a script in one of the cells in the node 22 it is received by the dispatcher 14e in the cell 14 and is forwarded to the appropriate script(s).
• An exemplary embodiment of a network interface receiver can be found in the Appendix at pages 45-57 (nicrx.c).
• the dispatcher 14e executes scripts such as 14c which sends a message to a local external output device 36 and script 14d which sends messages to scripts 18b and 20a.
• the type of message which might be sent by script 14d includes messages which alert scripts 18b and 20a that a recipient of their respective messages is ready to receive messages.
• the cell 12 shown in the illustrated example is a "network interface transmitter" and is responsive to a single script 12a which transfers messages from the node 22 to other nodes.
• An exemplary embodiment of a network interface transmitter can be found in the Appendix at pages 26-33 (nictx.c).
• the cell 12 is also responsive to clock signal events from a clock 38.
• the clock signal events cause the execution of script 12a which transmits messages according to priority to remote nodes via the bus 28.
• messages may be transmitted according to an event-reaction protocol or according to a streaming protocol.
• scripts executed in cell 20 in response to input from an ADC 34 may generate streaming data which is communicated to a cell 12 for transmission to a remote node via the external bus 28.
• Communications among scripts is preferably effected via structured communications packets of variable length which includes address information, an indication of the message type, an indication of the message length, and the message.
• a presently preferred packet structure is illustrated in Table 1 below.
• the packet structure in addition to having a variable payload length, the packet structure includes a variable field length for recipient addresses.
• each script has the capability of multicasting a message to up to eight other scripts, each having a two byte address. Indeed, as will be described in more detail below with reference to Figure 5, according to preferred embodiments of the invention, sc ⁇ pts build mailing lists based on events such that the recipients of the messages generated by a particular sc ⁇ pt will change over time
• messages are broadcast to all sc ⁇ pts by indicating that the length of the recipient address listing is 0, by not listing any recipient addresses, and by indicating the message type as being "broadcast"
• the presently preferred address format is two bytes where the first byte indicates the node where the sc ⁇ pt resides, three bits identify a "subnet", and five bits identify the sc ⁇ pt
• "subnet” refers to a single transport medium through which multiple nodes communicate
• This addressing system provides the foundation for allowing groups of nodes in different networks to communicate with each other provided that there is some way to b ⁇ dge the different networks
• the payload is limited to sixty-four bytes Those skilled in the art will appreciate, however, that the maximum size of the payload depends in part on the type of application being implemented, the bandwidth of the network, as well as the latency which can be
• eight message types are defined These include “broadcast”, “exception”, “remote process spawn”, “remote process begun”, “remote process ended”, “data event”, “data event acknowledge”, and “stream”
• the payload types presently defined include “unsigned character”, “signed character”, ' unsigned integer”, “signed integer”, “ ⁇ -law encoded”, “wave encoded”, and “MPEG encoded'
• the message type field is used by queue managers to dispense rank tokens in order to p ⁇ o ⁇ tize packets Further, the message type field may be used by scripts to determine whether the receiving sc ⁇ pt is intended to operate in either a ' master mode' or a "slave mode
• each script in a node is coupled to a "local bus" 40
• the "local bus” 40 is referred to as the Imf (internal message format) bus and in a presently preferred embodiment it is embodied as a multiported shared memory If a shared memory is not used, it is preferred that the Imf be provided with buffers foi mter-cell communications within a node and mter-node communications Regardless, each script which has a need to output a message through the network interface transmitter 12 or receive a message from the network interface receiver 14 is provided with a buffer for mter-node communications Each buffer is presently embodied as an instance of a data structure (e.g 16aB, 14aB, 18aB, 14nB, etc.
• a data structure e.g 16aB, 14aB, 18aB, 14nB, etc.
• the buffer includes all information needed for the network interface transmitter dispatcher 12e to packetize the outgoing message and for the network interface receiver dispatcher 14e to route the incoming message.
• messages entering a node through the network interface receiver dispatcher 14e are automatically routed by the network interface receiver via a function call to a pointer which points to a script in an "IMF STRUCT" array associated with the network interface receiver. These arrays are defined throughout the Appendix and called “Scriptstinct".
• automatic responses to messages such as spawn process requests are similarly created.
• a high level description of how the network interface receiver and transmitter utilize these buffers is illustrated in the flow charts of Figures 4 and 5.
• the node and subnet address information is extracted at 100.
• the script address is read at 102.
• the script address points to a pointer in the IMF struct.
• the IMF struct is read at 104 and the pointer to the script is obtained. Using this pointer the actual script is found at 106.
• the remaining information in the message is passed to the script at 108. If the message is the type which requires a reply, the reply info is obtained from the script at 110 and the previously extracted address info is used at 112 to return the reply to the sending script.
• Other details of a network interface receiver according to the invention can be gleaned from the source code listing "nicrx.c" in the Appendix at pages 45-57.
• the queue contains pointers to the buffers (e.g. the IMF STRUCTs in Figure 3) containing outgoing messages.
• the pointer to the next message is read from the queue at 200 and the message type is read from the buffer at 202.
• the address length and address fields are adjusted according to the message type at 204. For example, if the message type is broadcast, the address length field is set to zero and no addresses are listed. Similarly, if the message type is a data event ack, the address length will be two bytes since these messages always have one receiver. However, if the message type is a data event or a stream, there may be many addresses.
• data events require acks and the acks are used to update mailing lists, but streams do not require acks.
• ack flags are set at 206 so that when acks are received they will be registered as described above.
• the packet with the checksum is constructed and at 210 the transmitter is informed that a new message is ready to be sent.
• the constructed packet is held in a buffer and a pointer to the buffer is held in the output message queue. This constitutes the basic handling of messages by the network interface transmitter.
• Other details of a network interface transmitter according to the invention can be gleaned from the source code listing "nictx.c" in the Appendix at pages 26- 33.
• the output message queue is presently limited to eight IMFstruct pointers.
• scripts may communicate with each other by dynamically compiling and tearing down mailing lists which are based on the occurrence of specific events.
• one of the byproducts of a remote process spawn message may be the updating of a "mailing list" which is referenced by data event messages and stream messages.
• cells periodically advertise their presence in the network so that other cells can take advantage of their resources.
• cells or nodes may be programmed to periodically send broadcast type messages to announce their presence in the network and their capabilities. The cells or nodes would also then be programmed to interpret such broadcast messages and update mailing lists and databases based on these messages.
• FIG. 6 An example of messages exchanged in response to an advertisement from a cell is illustrated with reference to Figure 6.
• the cell 42 in node 24 learns from an advertisement that the cell 44 in node 26 is now connected to the network and is functioning. From its own programming and the advertised information, the cell 42 knows that the cell 44 is responsive to input which is useful to the activity of cell 42.
• the script 42a in cell 42 creates a "remote process spawn" message which is directed to the script which manages the mailing list of cell 44.
• the spawn process message is a directive to add addresses to the mailing list of scripts in the cell 44.
• the message flows via the local bus (not shown) to the network interface transmitter cell which transmits the message via script 46a onto the network 28.
• the "to address" in the message is read by all receivers including the network receiver 48 in node 26. Based on the address and the message and the message type, the dispatcher 48e in cell 48 executes script 48a which is responsible for managing the mailing list 52 of the cell 44.
• the mailing list 52 resides in shared memory or in a buffer dedicated to that purpose. Preferably the mailing list resides in a buffer which is only visible to the cells involved.
• the script 48a reads the message from script 42a, determines that the message is intact, checks the mailing list 52 to determine whether the "new subscriber(s)" is already on the list and updates the mailing list 52 if needed.
• the script Based on a recognition of the message type, the script returns a message to script 42a that the remote process is ended.
• the "remote process ended” message includes error indications if any errors were encountered during execution of the process.
• the update mailing list is a fast process and, as such, does not require the "remote process begun” response.
• the script performing the remote process preferably will respond that the process has begun and will respond again that the process is ended.
• the dispatcher 44e calls script 44a which sends a message to the network interface transmitter 50.
• the cell 44 may process the event first or may simply call the script 44a to notify the transmitter. For example, if the cell 44 is a keypad controller, it will "process” the event "X” to determine which key has been pressed prior to calling the script 44a.
• the message sent by 44a will include the results of the processing, i.e. an indication of which key was pressed.
• the external input to the cell 44 is one bit binary such as an on/off switch, the script 44a may always send the same message, i.e.
• the dispatcher 50e in the transmitter 50 recognizes that the type of message is a data event and calls the script 50a which gets the mailing list from the data structure 52 (based in part on the from address) in order to format the message for a multicast transmission onto the network 28.
• the script also enters information in the buffer (not shown here, but see Figure 3) associated with the cell 44.
• the information includes an indication that data was sent to the members of the mailing list. This information will later be used to be sure that the data was received intact within the allocated time frame, i.e. to determine whether the data needs to be resent to one or more recipients.
• the message from the transmitter 50 is found on the network 28 by all of the receivers coupled to the network. All of the receivers read the node information in the address list to determine whether any cells in their respective nodes contain affected scripts. For example, if the address contains the node, the dispatcher 54e in the network interface receiver 54 routes on the script address to call the appropriate script 54a to process the message.
• the script 54a may be designed to take the data payload of the message and store it at a location in the shared memory 56 of the node 24. Alternatively, the script 54a may be designed to take the data payload of the message and store it at a location in the shared memory 56 and also call another script which will read the data from shared memory and make use of it.
• FIG. 6 illustrates the symmetrical/reciprocal nature in which the cells function.
• a cell in node 24 began by spawning a process in node 26 to add its address to the distribution list of a cell in node 26.
• the cell in node 24 was acting as a "master” and the cell in node 26 was acting as a "slave”.
• the event X cell in node 26 acts as a master and the cell(s) in node 24 act as slave(s).
• a dist ⁇ aded processing system 300 is embodied as a telephone private branch exchange (PBX)
• PBX telephone private branch exchange
• the system 300 includes a plurality of line cards 302, 304, 306, each of which is coupled to a separate subsc ⁇ ber line 308, 310.
• the line cards and the phone cards are each powered by their own power supply which is an AC adaptor coupled to the AC mains of a home or office
• the line cards 302 and 306 are coupled to their respective subsc ⁇ ber lines 308 and 312, but are not coupled to anything else
• the line card 304 is a hybrid line card/phone card and is coupled to subscriber line 310 as well as to telephone set 336
• the phone cards 314, 316, 318 are each coupled to the subsc ⁇ ber line 308 and, as explained in more detail below, are able to communicate with each other and with the line card 302 by sending signals over the subsc ⁇ ber line 308 wires
• the phone cards 320 and 322 are coupled to the subscriber line 310 and, as explained in more detail below, are able to communicate with each
• b ⁇ dging of like media is done with a capacitive or inductive bndge and b ⁇ dging of dissimilar media is done with a "smart b ⁇ dge". It will be appreciated, however, that a smart b ⁇ dge could be used to b ⁇ dge like media as well.
• each of the line cards and phone cards may be thought of as a separate node and the bridged subscriber lines and AC mams may be thought of as the network bus 28 shown in Figures 1 and 6
• the cells in each line card include a cell which responds to events occurring on its associated subsc ⁇ ber line, i.e., an incoming phone call Sc ⁇ pts responding to an incoming phone call include ⁇ ng detection, ring mailing list, and caller LD mailing list
• Other sc ⁇ pts which respond to sc ⁇ pts from the phone cards include line seize, dial, and speech mailing list
• the ring mailing list and the caller ID mailing list indicate which phone cards will receive a ⁇ ng signal and caller ID information when a ring is detected on the subscriber line by the line card
• the line seize and dial sc ⁇ pts respond to messages from a phone card when certain scripts in the phone card are executed
• the speech mailing list scripts which exist on both the phone cards
• the phone cards each include scripts which respond to events generated by the attached telephone set and to messages received from the other cards in the network
• the phone cards include scripts for generating a dial tone when the attached telephone set goes off hook, for registering DTMF tones, for sending messages to other cards in the system, etc
• the attached Appendix includes code for implementing line cards and phone cards
• the code which is particular to the line cards is identified by file names which begin psn/lc' and can be found in the Appendix at pages 60 through 87
• the code which is particular to the phone cards is identified by file names which begin "phone/" and can be found at pages 87 through 173 of the Appendix Code which is used by the system generally and by both the phone cards and the line cards is found in the Appendix at pages 3 through 60
• FIG. 8 illustrates some of the functions of the PBX system 300
• a telephone set attached to one of the phone cards in the system goes off hook, an "off hook event" is detected by a cell in the phone card and this is indicated at 400 in Figure 8. This event is also illustrated in the Appendix at pages 82 et seq.
• the phone card will generate a dial tone as indicated at 402 in Figure 8 and as also shown in the Appendix at pages 159 et seq. It will be appreciated from the Appendix that the dial tone heard in the telephone set is not the dial tone generated by the public telephone network but is a tone generated by a cell in the phone card. See Appendix pages 41-42. However, it will be appreciated that the telephone network dial tone could be used.
• the telephone set will next generally generate a DTMF tone in response to a user pressing a key on the keypad.
• a "dial digit event" is detected by a cell in the phone card as indicated at 404 in Figure 8 and in the Appendix at pages 64 et seq
• the cell which detects DTMF tones coming from the telephone set includes scripts for time out limits between digits, a script for stopping the generation of dial tone (406 in Figure 8) and scripts for recognizing which DTMF digits were dialed.
• the PBX system allows calls to be made between phones in the local network without using the public telephone network.
• the DTMF cell in the phone card will contain sc ⁇ pts to interpret whether the digits dialed represent an outside call which requires the use of a subscriber line. This determination is illustrated at 408 in Figure 8 and in the Appendix at pages 141 et seq. If the call needs an "outside line", messages are sent from the phone card to the line card(s) as illustrated at 410 in Figure 8 These messages include a request to seize a line and a request to dial the number corresponding to the digits dialed by the telephone set.
• a script is executed (412 in Figure 8) to look to the network database to determine if there is a phone card responding to that extension number connected to the network. See Appendix pages 141 et seq. If no such number exists as determined at 414 in Figure 8, a speech generating script is called to generate an audio message at 416 in Figure 8 which is heard in the hand set of the telephone. According to the presently preferred embodiment, speech generation tools are used throughout the system to generate "recorded" messages. See, e.g., Appendix pages 137 et seq. which shows how messages are constructed by concatenating pre-recorded words and phrases.
• a message is sent at 418 in Figure 8 to the phone card having the extension number dialed. This is also illustrated in the Appendix at pages 142 et seq. If the phone connected to the dialed phone card is not off hook, a script in the dialing phone card will generate a ringing tone in the handset of the dialing telephone. This is illustrated at 420 in Figure 8 and in the Appendix at page 143. Meanwhile, a script will send a message to the dialed phone card instructing it to make the phone attached to it ring. The dialed phone card will return information indicating whether the dialed phone has picked up.
• the PBX system described above may also be adapted to network other types of data in addition to or in lieu of telephone calls.
• the PBX network described above may also carry serial data streams from a personal computer to a printer, for example. This is also suggested in the Appendix at pages 35, 138, and 156.
• the invention may also be adapted to carry various types of home automation, home security, and home entertainment data.
• other processing colonies according to the invention can be coupled to the home network (either telephone wires or AC mains, or even cable tv wires) with or without the PBX system.
• These other processing colonies can include video transmitters and receivers for both security .and entertainment, multiple digital sound channels for security and entertainment, simple signal controls to turn appliances on and off in response to events for both home automation and home security, etc.
• the invention can achieve remarkable efficiency through the application of "space-time" programming where time is included in the declaration of variables and functions.
• T5 LVL 4 «2 15 #def ⁇ ne T5-.GLVL 1 16 uint strCat(uchar* strl, uchar* str2) ⁇
• TxDir-OUTPUT 90 //Leave behind the zero Move to start of buffer.
• Breakout of max pkt size is thus: 19 ⁇ include ' psn ⁇ lc_t ⁇ mer h" ⁇ msg LenxmsgTypextoAddrLenxtoSOxtoSc ⁇ pt> ⁇ fmS0xfm scr ⁇ txpayLoad> 20 //"iDebug 1 1 1 12 1 1 64 21 ⁇ include psn ⁇ lc_p ⁇ ns h 22 ⁇ endif ie above li st accomodates 6 ⁇ toAddr>, overall length is 81 23
• ⁇ 125 //is one advanced from the data buffer of interest else ⁇ 126 sw ⁇ tch(S ⁇ nkBuffIndex) ⁇
• This byte is used to steer arriving packets into 501 ⁇
• the buffers (A,B,C) are filled in a strict rotation 505 ⁇
• PECC0 INC-SRCIBYTE_XFRI COUNT_0; / Tx Channel
• PECC0 1 SPCH_PKT_SIZE ; 18 extern uint CidTimer;
• ModeReg 0x02, 195 //the line if no spch pkts are received for a 196 //period of C0DEC_WATCh_D0G_TIME0UT
• RingMailStruct eol 2, 10 extern mailAddr c ⁇ dMa ⁇ lL ⁇ st[]
• T5IC 8. ⁇ INT_ENABLE , 26 #define BING 4
• PAY_LEN *msg++; 1 57 ⁇
• PAY_LEN temp return temp 230
• the 254 message can come from anywhere - this is a generic 255 default information service 256 / ⁇ */

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Computer Security & Cryptography (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Communication Control (AREA)
• Multi Processors (AREA)
• Telephonic Communication Services (AREA)

Applications Claiming Priority (13)

Publications (1)

Family

ID=27559186

Family Applications (1)

Country Status (5)

Families Citing this family (3)

Family Cites Families (4)

• 2000
  • 2000-01-05 EP EP00903105A patent/EP1336137A2/de not_active Withdrawn
  • 2000-01-05 CA CA002358252A patent/CA2358252A1/en not_active Abandoned
  • 2000-01-05 WO PCT/US2000/000160 patent/WO2000041053A2/en active Application Filing
  • 2000-01-05 AU AU24901/00A patent/AU2490100A/en not_active Abandoned
  • 2000-01-05 JP JP2000592712A patent/JP2003530609A/ja active Pending

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events