WO2003101072A1

WO2003101072A1 - System and method for object oriented digital streaming

Info

Publication number: WO2003101072A1
Application number: PCT/US2003/017612
Authority: WO
Inventors: Reuben Bruce Murphy; Billy Dennis Williams
Original assignee: Ryger Technologies Inc.
Priority date: 2002-05-23
Filing date: 2003-05-23
Publication date: 2003-12-04
Also published as: AU2003240530A1

Abstract

A system and method for object oriented digital streaming, comprising the following steps: Instantiating an object on a host digital device (1032), converting the object into a self-describing form of the object (1034), capturing the underlying representation of the self-describing form of the object (1036), and then, converting the underlying representation of the self-describing form of the object into a stream (1038). Next, sending the stream to at least one second digital device (1044) such that the object is instantiated on the at least one second digital device (1052). Then, while the digital devices are connected by the link, at predetermined intervals (1054), the at least one second digital device sends the current state of the object to the host digital device using the steps described above. While the object remains in the form of a stream, the host performing the following: determining whether to send the stream to another of the at least one second digital device; and sending the stream to the at least one second digital device. In some embodiments, the method includes performing a conversion utility on the stream prior to sending the stream (1045).

Description

SYSTEM AND METHOD FOR OBJECT ORIENTED DIGITAL STREAMING

Technical Field

This invention relates to the field of digital device data transfer, more particularly, to a system and method for object oriented digital streaming. Background Art

The conventional method of networking digital devices depends on a client/server networking model. In this method, information is stored on one digital device; the server, while a user is at a second digital device; the client. The client digital device uses a utility program that communicates with the server digital device in order to access information located on the server digital device. When a request for information is passed to the server digital device, the server digital device interprets this, and presents the information to the client digital device.

This connection between the client digital device and the server digital device is governed by a set of standards called the Transmission Control Protocol (TCP). The format of the data packets and the addressing system are set by another set of specifications called an "Internet Protocol" (IP). The TCP/IP therefore supervises this kind of networking link. The two digital devices communicate across Open Systems Interconnect layers (OSI), particularly, through the data link and network layers. This type of networking connection could be made over a wide-area network such as the Internet, or over a local-area network such as a company- wide Intranet.

A conventional client/server connection is exemplified through the web page browser and client digital device example. A typical web page can include several different kinds of information or objects. A block of text forms a text object, while a picture is handled as a graphic object. These are referred to as high-level objects, meaning that they are recognized and processed as fixed data sets by the operating system that is running on the digital device that require extraneous data to be interpreted by another digital device.

The different kinds of objects coming from the server are sent to one or more input ports on the client digital device. These are not physical connectors on the client digital device- rather, they are logical locations used by the software supervising the TCP/IP connection. Depending on the type of data coming in over the network, this may mean that the software must monitor several different ports, and then integrate the resulting information.

The data packet structure used by the conventional network connection includes an IP address in the first section of the data packet. This is the destination or target of the packet. The next section lists the port used to receive the packet, then the data that is specific to the application being used-the text, graphics, etc. The web server or the web browser sets the size of the packet. The web browser interprets the content of the packet using

XML or HTML function calls or object code. Each time a screen image is changed or refreshed, the server sends a complete image of the screen to the client.

This system works well for relatively simple functions, such as the transmission of a web page as described here. However, there are some built-in limitations, which become limiting if the network is asked to deal with more complicated kinds of information transfer.

Network users have long been interested in the potential benefits of collaboration- two or more users working together on the same application or file at the same time. Developers have tried several ways of adapting the conventional network design to allow for collaboration. Each method has some advantages, but none of them have provided the true utility and convenience in which users desire. One example of a collaboration scheme currently known in the art is a web-based collaboration network.

In this arrangement, the collaborative environment is maintained on the server. Each of the client digital devices can link to the server, and see the information presented by the server itself.

For the client digital devices to share an application using this kind of networking, the application must be running on the server. The screen information is created by the application, and then converted or translated into an XML or HTML format that can be understood by the web browser running on each client. In effect, the programmers trick each client digital device into thinking that it is still dealing with a server providing web pages.

Using the conventional technology, to allow a number of client digital devices to see the same image of a document, and make changes to that document for the other client digital devices to see, this is done using a web- based collaborative network. When one client digital device makes a change to the text that appears on all client digital devices, to process this change, the server must collect the new information from the client digital device, and pass it along to the application. The application then processes the change, creating a new or modified screen image. Next, the application sends this revised screen image back to the server. At this point the server can present the updated image to all the client digital devices. To transmit multiple copies of the same screen image, the server uses a strategy called packet splicing.

The packet sent out to client digital device 1 includes the IP address for client digital device 1, plus the port address, and then the data representing the screen image. The packet sent to client digital device 2 is almost identical, except that it includes the IP address for client digital device 2. The packet for client digital device 3 is spliced in the same way. There are some serious limitations to this kind of arrangement. First, in effect, each of the client digital devices becomes a dumb terminal. Each client simply reproduces screen information generated on the server. The client digital devices do not help to carry the load of network processing. Second, the information transferred over the network consists of high-level data, which refers to the transmission of data in the entire data set without the ability to access and transmit any portion of data within the data set. User friendly digital device languages such as JAVA and HTML may require the programmer to access high level data for the purpose of network transmission. All of the data objects being moved are created by the application and the server digital device's operating system. This means that each data packet must include a large amount of extraneous overhead information- information that is not created directly by application. This extraneous information imposes an unnecessary load on the network, slowing the network throughout. In many cases, the network cannot approach a real time response to client digital device's activities. Third, the application used for collaboration must be running on the server digital device. The application must be extensively customized to make the collaboration possible. Using this network architecture, one client digital device cannot use an application running on another client digital device. Fourth, the application software must be modified to change the way it handles different kinds of data objects. For example, it might be necessary to handle text in one way, while a graphic image might be processed differently. While this can be made to work, it can require extensive custom programming. This in turn requires a large investment of time and resources. Additionally, the final result is pre-configured or locked into the design parameters set up when the customization was begun. If the application suddenly needs to process a different kind of object, another round of customization is required.

A fifth limitation of the conventional collaboration network is found when a network attempts to collaborate digital devices running on different operating systems. Some networks can handle client digital devices that are using different operating systems. Although the browser application running on different platforms can be used to process the same data, that data cannot be processed directly by the different operating system outside of the browser application. For example, an Internet browser is cross-platform, and therefore data inside the browser can be transferred from one operating system to another. However, any data outside the browser cannot be utilized by a different operating system without a secondary conversion. Therefore, in order for the receiving digital device to work with the information, the data must first go through a translation or conversion process. However, these translation or conversion processes often present problems, and do not allow an entirely successful conversion of data.

A final limitation is seen when the screen image on the server is modified. Each time the screen image on the server is modified, even if the change involves only a few pixels, the server is forced to send completely new screen images to each client digital device. If this screen contains graphic images or other large data objects, this can place a significant load on the system. For data-intensive applications, it is difficult for the system to respond quickly enough to simulate a real-time response.

Another variation of collaborative networking presently found in the art is networking using a collaborative platform. The system architecture is similar to the conventional collaborative network described above in the way the client digital devices are connected by the server. In the collaborative platform network, however, the application program is running on one of the client digital devices, rather than the server digital device. Each of the client digital devices uses a communication and display program called a platform. This platform utility performs some of the functions of a web browser program.

However, the collaborative platform-networking scheme has many disadvantages. As with the conventional collaborative network scheme, all the information handled by the network consists of high-level data. This arrangement places a heavy load on the server, which is referred to as a relay server in this application. Often the client digital device must connect to the centralized relay service- a server operated by the company that provides the application software. Additionally, the application must be extensively customized to make this possible. Also, all the client digital devices on the network must operate at the same level of security. If one client has permission to modify files or control access to the network, this permission must be extended to all clients. This is dictated by the network architecture.

Another collaborative network system is networking using browser applets, which are small programs. Some common browser applets use JAVA®. In this arrangement, each client digital device has a browser, and each of these is running an applet devoted to the network. The application program is running on one of the client digital devices, not on the server. The browser applet for each client digital device interacts with the operating system running that digital device. Specifically, the applet works with the commands or calls provided by the operating system. This arrangement provides some collaborative functions, and can work well in some applications. Users on different client digital devices can usually share text or audio-video data.

There are many limitations inherent in this arrangement, and the limitations are as follows: because applets work with operating system function calls, the collaboration is limited to the functions provided by the operating system and thus can only be shared with users with compatible operating systems. As with the other collaborative systems described above, this kind of network is still handling high-level data. Also, since most operating systems are designed for a single user, the operating system is unable to distinguish between multiple users. This creates a critical permissions flaw in existing desktop collaborative software. When one client digital device shares a portion of its desktop (such as an application window) with other client digital devices, those other client digital devices may gain access to the operating system through backdoors in the shared portion. For example, a user who shares a MICROSOFT EXCEL® spreadsheet is also granting access to their VISUAL

BASIC® editor. By running macros, the other users have full command of the shared operating system. Other such backdoor access points are also presented.

Yet another type of collaborative network known in the art is a network using browser plug-ins. A plug- in is another type of small utility program that can be added to a web browser program. In this network variation, each of the browsers includes a plug-in program that allows for some collaboration. In a typical application, a client digital device will download an application specific file such as an M-PEG video file. The browser creates a temporary or permanent file on the digital device. Once the file transfer is completed, the plug-in then processes the data, and may use the browser as a viewer. Files may be run while they are downloading, providing the data in the download buffer are not used more quickly than they can be replaced. Although this arrangement allows the browser to carry out some application-specific collaborative functions, this system has several drawbacks. First, the network is still handling high-level data objects, which has many drawbacks, as described above. Second, this type of collaborative network usually cannot respond in a real time manner, which creates significant drawbacks in the field of collaborative networking. Another collaborative network arrangement present in the art is the remote desktop arrangement. In this arrangement, as each client digital device operates, it registers information used to generate the display to a memory space set aside as video RAM (VRAM). Each time the display needs new screen information, it refers to this VRAM. Each client digital device is also running a utility program which handles the network collaboration. This utility uses a splicing strategy to capture the information moving into and out of the VRAM, along with inputs from the keyboard and mouse. This information is then shared with one or more other digital devices. This network can be arranged peer to peer, meaning the data travels directly from one digital device to another, without a server. The digital devices participating in this kind of network can also be connected using a separate server, and networked via the Internet. The remote desktop arrangement has many disadvantages. Because this arrangement transfer the whole desktop, including the window presented by the application, from one digital device to another, essentially the second digital device becomes a dumb terminal, simply presenting information developed on the first digital device. Thus, although this kind of network can be fast and effective if users want to duplicate the whole desktop, this arrangement is altogether ineffective if users wish to only share certain applications, and not the entire desktop. The process of transferring data in VRAM is not selective, meaning, the software cannot work with just one particular window, for example. All of the information on the desktop must be made available to all of client digital devices in the session. This has significant disadvantages. First, this poses privacy issues. Once a client digital device is placed in a session, everything on the shared desktop is open to every client digital device. Second, the networked information really consists of a series of bit-maps or images. Although the receiving client digital device can display these bit-maps, the receiving digital device cannot analyze or interpret the information that was used to generate the displays. Thus, this system is not a truly collaborative network.

In addition to the disadvantages discussed with respect to each of the networking systems described above, all of the technologies described above have additional limitations. First, not one of the networks exemplifies a true peer-to-peer architecture. All of the networks depend on the relay server to do extensive processing of the data passing between client digital devices. Therefore, this puts most of the network-processing load on the server, which in turn, leads to a slow server. Second, all these networks work with high-level data, a potentially inefficient data set for networking purposes. Each object the network processes uses the data structure set up by the operating system from the digital device from which the data originated. Consequently, to convey a certain amount of important application-specific data from one client digital device to another, the network operating system must also transfer some extraneous information included by the originating operating system in order for the second digital device to interpret the data. Another drawback is none of these networking systems described above can abstract the data being transferred. Thus, even after the data arrives at the receiving client digital device, the data must be used as originally intended by the application and the originating digital device's operating system. Finally, although some of these systems provide multi-user access to a client digital device's operating system, the operating system is unable to distinguish between different client digital devices. Thus, this creates a critical user-management problem with respect to user permissions. Virtually all computer architectures are byte addressable. If an int is four bytes, there are two different ways to store this. Suppose the address of the int is A. In a so-called big endian computer, the highest order byte is stored at A, and the lowest order byte is stored at address A+3. In a so-called little endian computer, address A stores the least significant byte and the most significant byte is at address A+3.

Big endian computer architectures include the IBM® 370, the Motorola® 68000 and Sun® Sparc. Little endian computers include the Intel® series (80486, pentiu etc) and VAX.

Consider the decimal integer 91,329. This is 0001 64 CI in hexidecimal. If this were to be stored at address A in a big endian computer, 00 would be at address A, 01 at address A+l 64 at address A+2, and CI at address A+3. On a little endian computer, CI would be the value at address A, 64 at address A+l, 01 at address

A+2, and 00 at address A+3. Computer networks are big endian. This means that when little endian computers are going to pass integers over the network (IP addresses for example), they need to convert them to network byte order. Likewise, when the receive integer values over the network, they need to convert them back to their own native representation.

There are four functions that do this: unsigned long htonl(unsigned long) host to network conversion for long ints (4 bytes) unsigned short htons(unsigned short) host to network conversion for short ints (2 bytes) unsigned long ntohl(unsigned long) network to host conversion for long ints unsigned short ntohs(short) network to host conversion for short ints

On big endian computers these functions simply return their arguments.

The shortcoming of this technology is that these functions only work with 32-bit integers. Thus, all integer data that is converted must be converted in 32-bit quantities. Thus, characters, strings and other data structures cannot be converted as an entire unit within the buffer. Furthermore, these functions offer no indexing information for packaging data in a buffer. Thus, once data is registered in a buffer, there is no information to specify where the next converted data should begin to be registered in the buffer. Accordingly, data that is buffered by conversion utilities known in the art must be of the same conversion type. This results in data packaging inefficiencies and, consequently, substantially reduced networking performance. Given that each type of data must be converted separately, the conversion utilities currently known in the art necessitate complex and redundant function, code implementations, and data flow operations.

Therefore, there is still a need in the art for a method of sharing objects between digital device irrespective of application, processor type or operating system, for a networking system that exemplifies a true peer-to-peer network architecture, that does not depend on a relay server to perform extensive processing of the data passing between client digital devices, that does not work with high level data, that is capable of abstracting the data being transferred over the network, that allows for multi-user access to a client digital device operating system where the operating system is able to distinguish between different client digital devices, thereby allowing for management with respect to user permissions, and that is capable of direct streaming of digital data. There is still a need in the art for a system and method for buffering and byte order conversion of digital networks that is independent from machine-specific representation of large numbers (i.e. big-endian vs. little-endian), where variable length strings can be represented, and different types (ie. Strings, integers, chars, etc.) can be combined in any order and amount. Disclosure of Invention In accordance with the present invention, as embodied and broadly described herein, a method for streaming at least one object between a host digital device and at least one second digital device. The host digital device and the at least one second digital device are connected by a link, and the object is instantiated within a first application framework, where the at least one second digital device has the first application framework, no framework or a second application framework. The second application framework is disparate from the first application framework. The method comprises the following steps. First, converting the object into a self- describing form of the object. Next, capturing the underlying representation of the self-describing form of the object, and then, converting the underlying representation of the self-describing form of the object into a stream. Next, sending the stream to the at least one second digital device such that the object is instantiated on the at least one second digital device. Then, while the digital devices are connected by the link, at predetermined intervals, the at least one second digital device performs the following: converting current state of the object into a self- describing form of the current state of the object; capturing the underlying representation of the self-describing form of the current state of the object; converting the underlying representation of the self -describing form current state of the object into a stream; and sending the stream to the host digital device. Sixth, while the object remains in the form of a stream, performing the following: determining whether to send the stream to another of the at least one second digital device; and sending the stream to the at least one second digital device.

Another method consistent with the present invention streams at least one object between a host digital device and at least one second digital device, the host digital device and the at least one second digital device are connected by a link. The object is instantiated within a first application framework. The at least one second digital device has the first application framework, no framework or a second application framework. The second application framework is disparate from the first application framework. The method comprises the following steps. First, initializing a host buffer on the host digital device. Next, initializing a receiving buffer on the at least one second digital device, and then, initiating a first object class for the object on the host digital device. Next, instantiating a code representation of the object and the object class on the host digital device. Capturing a representation of the underlying data of the object and the object class on the host digital device. Then, attaching an object ID to the representation on the host digital device. Next, attaching a streaming object ID to the representation on the host digital device, and next, sending the object ID and the representation to the receiving buffer on the at least one second digital device. Then, receiving the object ID and the representation in the receiving buffer on the at least one second digital device. Next, initiating a second object class on the at least one second digital device, the second object class being respective to the at least one second digital device and corresponding to the first object class. Then, instantiating the object on the at least one second digital device, and while the digital devices are connected, at predetermined intervals, the at least one second digital device sending the current state of the object to the host digital device, comprising the following steps: capturing a representation of the underlying data of the current state of the object and the object class on the at least one second digital device, next, attaching an object ID to the representation on the at least one second digital device, next, attaching a streaming object ID to the representation on the at least one second digital device, and, sending the object ID and the representation to the host buffer on the host digital device. The host digital device next receives the object ID and the representation in the host buffer on the host digital device. The host digital device next determines whether to send the object ID and the representation to the remaining of the at least one second digital device. Finally, sending the object ID and said representation to the remaining of the at least one second digital devices. Another method consistent with the present invention streams at least one object between a host digital device and at least one second digital device. The host digital device and the at least one second digital device are connected by a link, and the object is instantiated within a first application framework, where the at least one second digital device has the first application framework, no framework or a second application framework. The second application framework is disparate from the first application framework. The method comprises the following steps. First, converting the object into a self-describing form of the object. Next, capturing the underlying representation of the self -describing form of the object, and then, converting the underlying representation of the self-describing form of the object into a stream. Then, performing a conversion utility on the stream. Next, sending the stream to the at least one second digital device such that the object is instantiated on the at least one second digital device. Then, while the digital devices are connected by the link, at predetermined intervals, the at least one second digital device performs the following: converting current state of the object into a self-describing form of the current state of the object; capturing the underlying representation of the self -describing form of the current state of the object; converting the underlying representation of the self-describing form current state of the object into a stream; performing a conversion utility on the stream; and sending the stream to the host digital device. Next, while the object remains in the form of a stream, performing the following: determining whether to send the stream to another of the at least one second digital device; performing a conversion utility on the stream; and sending the stream to the at least one second digital device.

Another method consistent with the present invention streams at least one object between a host digital device and at least one second digital device, the host digital device and the at least one second digital device are connected by a link. The object is instantiated within a first application framework. The at least one second digital device has the first application framework, no framework or a second application framework. The second application framework is disparate from the first application framework. The method comprises the following steps. First, initializing a host buffer on the host digital device. Next, initializing a receiving buffer on the at least one second digital device, and then, initiating a first object class for the object on the host digital device. Next, instantiating a code representation of the object and the object class on the host digital device. Capturing a representation of the underlying data of the object and the object class on the host digital device. Then, attaching an object ID to the representation on the host digital device. Next, attaching a streaming object ID to the representation on the host digital device; performing a conversion utility on the object ID and the representation; and sending the object ID and the representation to the receiving buffer on the at least one second digital device. Then, receiving the object ID and the representation in the receiving buffer on the at least one second digital device. Next, initiating a second object class on the at least one second digital device, the second object class being respective to the at least one second digital device and corresponding to the first object class. Then, instantiating the object on the at least one second digital device, and while the digital devices are connected, at predetermined intervals, the at least one second digital device sending the current state of the object to the host digital device, comprising the following steps: capturing a representation of the underlying data of the current state of the object and the object class on the at least one second digital device; attaching an object ID to the representation on the at least one second digital device; attaching a streaming object ID to the representation on the at least one second digital device; performing a conversion utility on the object ID and the representation; and sending the object ID and the representation to the host buffer on the host digital device. The host digital device next receives the object ID and the representation in the host buffer on the host digital device. The host digital device then determines whether to send the object ID and the representation to the remaining of the at least one second digital device. Next, performing a conversion utility on the object ID and the representation, and finally, sending the object ID and said representation to the remaining of the at least one second digital devices.

These aspects of the invention are not meant to be exclusive and other features, aspects, and advantages of the present invention will be readily apparent to those of ordinary skill in the art when read in conjunction with the appended claims and accompanying drawings. Brief Description of Drawings

FIG. 1 A is a diagrammatic representation of the prior art.

FIG. IB is a diagrammatic representation of the overall functionality of the present invention.

FIG. 1C is a flow diagram of the preferred embodiment of present invention. FIG. ID is a flow diagram of the preferred embodiment of the present invention.

FIG. IE is a flow diagram of an alternate embodiment of the present invention.

FIG. IF is a schematic representation of the functionality of the .present invention.

FIG. 2A is a flow diagram of the preferred embodiment of the network functionality of the present invention on a first digital device. FIG. 2B is a flow diagram of the preferred embodiment of the network functionality of the present invention on an object router digital device.

FIG. 2C is a diagrammatic representation of the preferred embodiment of the OM Packet of the present invention.

FIG. 2D is a flow diagram of the preferred embodiment of applying the OM protocol to the OM Packet. FIG. 2E is a flow diagram of the preferred embodiment of the object router processing of the OM Packet.

FIG. 2F is a diagrammatic representation of the preferred embodiment of the OM network architecture.

FIG. 2G is a diagrammatic representation of one of the embodiments of the OM network where a client acts both as a client and as an object router.

FIG. 3A is a flow diagram of the preferred embodiment of the OM conversion utility module. FIG. 3B is an alternate embodiment of the OM conversion utility module. FIG. 3C is a flow diagram of the preferred embodiment of the stuffLong and unStuffLong process of the conversion utility module.

FIG. 3D is a flow diagram of the preferred embodiment of the index process of the conversion utility module. FIG. 3E is a flow diagram of the preferred embodiment of the stuffLong process of the conversion utility module.

FIG. 3F is a flow diagram representing the preferred embodiment of the process of the unStuffLong function of the conversion utility module.

FIG. 3G is a flow diagram of the preferred embodiment of the stuffChar and unStuffChar process of the conversion utility module.

FIG. 3H is a flow diagram of the preferred embodiment of the stuffString and unsStuffString function of the conversion utility module.

FIG. 31 is a flow diagram of the preferred embodiment of the stuffMemory function of the conversion utility module. FIG. 4A is a flow diagram of the preferred embodiment of the network functionality of the present invention on a first digital device using the conversion utility process.

FIG. 4B is a flow diagram of the preferred embodiment of the network functionality of the present invention on an object router digital device using the conversion utility process.

FIG. 5 is a flow diagram of one embodiment of the compression, encryption, and authentication modules as used in the OM network.

FIG. 6 is a flow diagram of one embodiment of the OM network.

FIG. 7A is a flow diagram of one embodiment of the compression module as used in the OM network.

FIG. 7B is a flow diagram of one embodiment of the encryption module as used in the OM network.

FIG. 7C is a flow diagram of one embodiment of the authentication module as used in the OM network. FIG. 7D is a flow diagram of one embodiment of the compression and authentication modules as used in the OM network.

FIG. 7E is a flow diagram of one embodiment of the compression and encryption modules as used in the OM network.

FIG. 7F is a flow diagram of one embodiment of the encryption and authentication modules as used in the OM network.

FIG. 8 is a diagrammatic representation of the cross-platform aspect of the preferred embodiment of the OM.

FIG. 9 is a flow diagram of the preferred embodiment of the OM that is running on the client digital device, establishing and maintaining a connection with the object router digital device. FIG. 10 is a flow diagram of the preferred embodiment of the linklist subroutine of the present invention.

FIG. 11 A is a diagrammatic representation of the preferred embodiment of the permissions module of the present invention.

FIG. 1 IB is a flow diagram of the permissions module.

FIG. 12 is a flow diagram of the preferred embodiment of the object router's management of the "In" and "Out" buffers and router function.

FIG. 13 is a flow diagram of the preferred embodiment of creating a shared object. FIG. 14 is a flow diagram representing the process whereby the client requests a specific shared object and the object router sends the specific shared object to the client.

FIG. 15 is a flow diagram representing the process of a client inviting a new digital device into the OM networking session. FIG. 16 is a flow diagram representing the preferred embodiment of the object router process of connecting the clients and associating their address with the client name.

FIG. 17 is a flow diagram representing the preferred embodiment of the monitoring process of the object router.

FIG. 18 is a flow diagram representing the pointer embodiment of the reading process of the OM. FIG. 19 is a flow diagram representing the pointer embodiment of the method of processing the data read by the OM.

FIG. 20A is a flow diagram representing one object router embodiment of the flow control module used for transmission of large data in bottleneck conditions.

FIG. 20B is a flow diagram representing one client embodiment of the flow control module used for transmission of large data in bottleneck conditions.

FIG. 21A is a flow diagram representing one object router embodiment of the flow control module based on the size of the data being transmitted.

FIG. 21B is a flow diagram representing one client embodiment of the flow control module based on the size of the data being transmitted. FIG. 22A is a flow diagram representing one object router embodiment of the flow control module used for coordinating transmission of the latest data.

FIG. 22B is a flow diagram representing one client embodiment of the flow control module used for coordinating transmission of the latest data.

FIG. 23A is a flow diagram representing one object router embodiment of the prioritization flow control module.

FIG. 23B is a flow diagram representing one client embodiment of the prioritization flow control module.

FIG. 24A is a flow diagram of the preferred embodiment of setting up a direct stream between a host and at least one receiving digital device.

FIG. 24B is a flow diagram of the preferred embodiment of the method of streaming objects between at least two digital devices.

FIG. 25 is a flow diagram of the preferred embodiment of the direct streaming method used to connect a new receiving digital device or host digital device to the direct streaming method.

FIG. 26 is a flow diagram of the preferred embodiment of the direct streaming method of accepting a connection request. FIG. 28 is a flow diagram of the preferred embodiment of the maintain function of the direct streaming method.

FIG. 30 is a flow diagram of the preferred embodiment of the method of sending out data for any stream in the direct streaming method.

FIG. 31 is a flow diagram of the preferred embodiment of the function for receiving data from a stream of the direct streaming method. FIG. 32 is a flow diagram of the preferred embodiment of the read AllData function of the direct streaming method.

FIG. 33 is a flow diagram of the function used to determine whether a new message has been sent in the direct streaming method. FIG. 34 is a flow diagram representing the method used for the function of the sending out a messages using the direct streaming method of the present invention.

Modes for Carrying out the Invention

The object manager (OM) is a method for sharing objects between digital devices, regardless of each digital device's operating system (OS), or application framework. An object from digital device 1, taken from a first application, is instantiated on digital device 1, and a first object class, corresponding to the object, is initiated on digital device 1. A code representation of that object and the respective object class are then instantiated on digital device 1. A representation of the underlying data of the object is then captured, an object ID is attached to that representation, and this representation with object ID is sent to at least one digital device 2.

Digital device 2 can either possesses the first application framework, have another application framework which is disparate from the first application framework (a second application framework), or, alternatively, have no application framework. Digital device 2 can run the same or different OS as digital device 1.

Digital device 2 receives the representation with the object ID, and digital device 2 initiates a second object class. The second object class is respective to digital device 2, and is initiated completely independently by digital device 2. Using the object ID, digital device 2 can determine the object level of the object, thereby is able to initiate a second object class for the object, this second object class being specific to digital device 2. Using this second object class, digital device 2 is able to instantiate the object, regardless of whether or not digital device 2 possesses the first application framework in which the object was originally generated from.

Therefore, the OM allows for any application aspect of an operating system (OS) currently running on digital device 1 to share data at any processing level with digital device 2, regardless of the operating systems currently run on either digital device 1 or digital device 2. Further, any application's input or output objects, static or automatic, running on the particular OS of either digital device 1 or digital device 2 can be captured by this invention.

In other embodiments, OM is also a complete networking and data management system. OM allows for one digital device, running the object router function of the OM, to connect to a multitude of client digital devices, and share with those client digital devices data from any application running on the object router, independent of whether the client digital devices possess or runs that application. Additionally, the OM object router function organizes and manages the shared objects, allowing for complete histories of shared objects, including client identification, to be indexed in the object router.

The OM is directed towards systems of sharing and networking objects and will be described with reference to several preferred embodiments as illustrated in the accompanying drawings. Although for simplification, with respect to many embodiments, the OM is described herein with reference only to 2 digital devices, a first digital device (also called digital device 1) and a second digital device (also called digital device 2) with respect to OM, and with respect to the networking embodiment, a sending client/sending digital device/first digital device/digital device 1 , a receiving client/receiving digital device/second digital device/digital device 2 and an object router digital device, this invention is intended for use with and between any number of digital devices. The embodiments of the OM described herein are implemented as logical operations in a digital device system. The logical operations of the present invention are implemented (1) as a sequence of digital device implemented steps running on the digital device and (2) as interconnected digital modules within the digital device's system. The implementation is a matter of choice dependent on the performance requirements of the digital device system implementing the invention. Accordingly, the logical operations making up the embodiments of the invention described herein are referred to variously as operations, steps, functions or modules.

For the present invention, the following terms are defined. Underlying data is a binary representation of fundamental information components. Binary shall refer to bytes or any binary construct. An object means a static object, or a state of a dynamic object, any number of dynamic objects or any number of different static objects. The binary object that is delivered to a digital device is a string of l's and 0's that the invention defines into integers, strings, characters, lumps of memory, etc., using a byte order. The binary string, with respect to dynamic objects, represents a state, and with respect to a static object, represents the data aspect of the object. An application means any digital device application, and in that respect therefore takes on its ordinary meaning, but also includes a database or a database application. Buffers are referred to in this description, and mean an assigned memory resource by the processor or the application functionality module. The present invention can use a pointer system as known to one of ordinary skill in the art, but, can accomplish the same function by writing the data to the memory resources, either RAM or secondary storage, to achieve the same function of the pointer system. In this second method, the present invention uses a function call in the OS that tells the processor to store the data in memory. In either the pointer or other memory resource method, the instantiation process of the present invention addresses the memory from its written and stored state. Class structures use the information in the buffer to instantiate the object. A link is a connection between at least two digital devices. The link can mean, but is not limited to, an Internet connection, a satellite communications link, wireless link or an Ethernet connection, or any other connection or link known in the art to connect or link two digital devices. A digital device is any machine having a processor and includes, but is not limited to: computer terminal, personal computer, laptop computer, Apple computer, or hand held device.

The OM connects digital devices that are running the OM to a network layer that communicates object- level data between multiple digital devices regardless of the operating system and application compatibility of the digital devices. Each digital device can create virtual networking sessions and manage multiple users on the network. Each digital device can accept modules that are developed to take data from buffers running on one digital device and package the data as an object and provide the instructions, using an object type code on how another digital device in the networking system can instantiate the object, interpret, or otherwise manipulate the data.

An object-oriented program is made up of objects that are instances of a "class" that constitutes a set of functions or variables. The class is a template that defines how a particular data set is to be interpreted and manipulated by the OS. The OS relies on the class to instantiate the object, and once instantiated, it becomes a program "entity" that, not unlike physical objects, has an internal state and outside characteristics that determine how it interacts with other data structures of an OS or application. An OS, or an object-oriented application, has its own object classes. These give the OS instructions for instantiating objects. In that respect, each object has an underlying data component and an internal data structure consisting of a set of functions or variables that define its characteristics. In the current art, there are applications designed to be run by certain OS. By current standards, each digital device is limited to the OS running on that particular digital device to run applications and perform operations on the digital device. However, there are some applications that create an object code for its own processes, above and beyond the object code of the OS. This object code tells the digital device's processor how to process the data so as to carry out the function of that specific application. Thus, the digital device can rely either on the OS, the application object code, or a combination of the two. In its simplest form, OM is a means for an application programmer to replicate desired objects that are created by an OS or an application on one digital device, and regenerate them or instantiate them on another (or several other) digital devices, regardless of the compatibility of the OS running on the other digital devices. In its preferred embodiment, OM is written using C++ computer language and is compiled on any OS platform with a respective C++ compiler program. In other embodiments, OM can be compiled and made to run on different platforms using any other computer language that is capable of supporting its functionality and compiled to run on any respective platform.

To utilize the OM as a networking layer, the application programmer first begins by identifying a particular functionality that is to be networked between one or more digital devices. The application programmer then identifies this functionality in terms of data sets (at the data level) and classes of objects (at the object level), if any, which constitute the particular functionality. Once determined, the application programmer proceeds to develop an Application Programmer Functionality Module (hereinafter APFM) that is compiled to run on the OS of digital device 1 with a corresponding APFM that is compiled to run on the OS of digital device 2.

The application programmer develops the APFM to run on digital device 1 by identifying the APFM with its own object code. The object code consists of a code representation of each object class (hereinafter AP-Object ID or object ID). The application programmer utilizes OM's Application Programming Interface (API) as an instruction to insert the OM function calls within the APFM. The OM function calls, in effect, instruct the OS to take any type of data from any digital device, and, using the function calls for taking data, which are specific for each OS, each application, or both, instructs the OS to replicate the raw data into OM buffers in RAM or secondary storage, in other embodiments, the OM function calls create pointers that instruct the OS to replicate the raw data into OM buffer.

OM operates using its own function calls. The OM stuffs the object ID (to determine the object level) and the raw underlying data (to fulfill the data level) of the instantiated object taken from digital device 1. In this manner, OM has the capability of capturing the raw data on digital device 1, and abstracting the data with an object code, and ultimately prepares the data for routing to an object router digital device and, ultimately, to any number of digital devices.

To fulfill the desired networking functionality, the APFM initiates the object class and the RAM buffer required for instantiation of the object on digital device 2. Once transmitted with the necessary data conversions (described below), the OM running on digital device 2 receives and un-stuffs the networked data and corresponding object ID. Under the direction of OM function calls (embedded in the APFM running on digital device 2), OM provides the networked data in the specified buffer in accordance with the object ID.

Once the data is placed in the specified buffer, the object, which originated on digital device 1, can be re- instantiated on digital device 2 in accordance with the corresponding object class. Essentially, each object that is captured, abstracted, and, in some embodiments, networked, by the OM system becomes a shared object that is instantiated in accordance with the corresponding object classes of the OS, or application, running on each digital device. Accordingly, OM has the power of overcoming OS or application compatibility barriers created by networking at strictly the data level as opposed to the object level. To overcome object class incompatibility between different OS platforms or applications, the application programmer may include compatibility modules.

These compatibility modules equate the object class of digital device 1 with that of digital device 2. Thus, the objects instantiated on digital device 1 are replicated on another or any number of digital devices that are running the same or any number of different OS platforms in which OM and the AFPM are compiled to run. For instance, one embodiment of the APFM is to harness the OM to convert file formats or other directory structures, so that they can be interpreted by applications running on cross-platforms. This file conversion APFM would convert data in real time while it is being networked between digital device 1 and digital device 2 with the conversion occurring on either device without a separate conversion process occurring on a separate conversion application or intervening digital device, although this, by no means, is the only APFM application, but it is of significant value. Therefore, APFM is, in this instance, used for file transfer, but the actual utility of the APFM is much broader and distinct in terms of networking live memory.

By continually networking the underlying data of each object, changes in the internal state and respective outside characteristics of the original object can be reflected in the instantiation of the objects on the other digital device(s). Also, the object classes that are used to instantiate the object on digital device 1 can be manipulated to produce different states or characteristics for objects instantiated on digital device 2. For instance, an object class can be simplified to optimize network performance with a digital device with limited resources (i.e. networking, memory, processor and other operational resources). These changes may produce or enhance the desired networking functionality.

Referring first to FIG. 1A, the prior art is shown. In the prior art, digital device 1 10, having an OS, is running an application framework 1 12. Object 1 14, having an object class 1 16, is instantiated on application 1 12. Object class 1 16 is taken from an object class library on application 1 12. When digital device 1 10 shares object 1 14 with digital device 2 18, running an OS, the object 1 14 and object class 1 16 (or an indication of the object class) are sent to digital device 2 18. Digital device 2, also running application 1 12, instantiates object 1 14 in application 1 framework 12, using object class 1 16, either taken from an object class library located on application 1 12, or else having receiving object class 1 12 from digital device 1.

Therefore, in the prior art, for digital device 1 to share an object with digital device 2, both devices must run the application framework in which the object is instantiated, and both devices must either have identical object class libraries, or else the object arrives with the object class.

The present invention is shown in FIG. IB. Referring now to FIG. IB, digital device 1 12, running OS 1, instantiates an object 14 having class N 16 on a first application framework 20. When digital device 1 12 shares the object 14 with digital device 2 18, a binary representation 22 (hereinafter binary object 22) of the object 14 is created in RAM or secondary storage (in the preferred embodiment). The object class 16 is either a generic object class from the application functionality module 24, or else it is a generic object class from the OS 26.

The binary object 22 is sent to digital device 2 18 with either the generic object class from the OS 26 or from the application functionality module 24. Digital device 2 18, running OS 2 (cross platform from OS 1) and application framework 228, where application framework 228 is disparate from application framework 1 20, receives the binary object 22 in RAM. Digital device 2 18 then instantiates the object 14 on application framework 228 using the object class 16. Either the generic OS class or the generic application functionality module class is understood and can be used to instantiate the object 14 on application framework 228. Referring now to FIG. 1C, the process of OM is exemplified by showing an example of taking any object

(here a graphics object) instantiated in any application framework (here a JPEG framework) and using OM, re- instantiating the original object, but without using the original application framework. On digital device l's screen 30, a graphics object is instantiated. This graphic's image was instantiated using a JPEG file in digital device 1 's memory 32. When digital device 1 wants to share this object, if both digital device's have the OM, the OM takes the underlying data 34, builds a binary construct 36 using the memory 32, and the APFM recreates class structures 38 which are equivalent to original class structures. Applying the class structures 38 to the binary construct 36, the original object is re-instantiated on digital device 240. Therefore, the original object is instantiated on digital device 240, and digital device 240 does not have the original application framework (in this example, JPEG).

Further, the underlying data can be networked 42 using OM to any number of digital devices 44. These other digital devices 44 simply apply the same process as described with respect to digital device 240, and re- instantiate the original object. The other digital devices 44 can now share the object with digital device 240, neither device having the original application framework. Referring now to FIG. ID, the preferred embodiment of the OM is shown. For illustration purposes only,

FIG. ID shows the method by which one object, originating on a first digital device, is shared with at least one second digital device. In practice, any number of objects can be shared between the digital devices, and those objects can be altered by the receiving digital device, and then sent back to the originating digital device. However, for each time an object is shared between digital device, the object follows the method exemplified in FIG. ID.

Still referring to FIG. ID, the first digital device retrieves or receives the object that is or will be shared between at least two digital devices (this step not shown). Whether the first digital device has received the object from another digital device, or else the first digital device retrieves the object from RAM or secondary storage, the following process shown in FIG. ID (and FIG. IE) applies. In step 70, the object class of the desired networking functionality is instantiated within a first application framework. In step 72, a first object class is initiated on the first digital device. In step 74, the code representation (from the first digital device) of the object and the object class are instantiated. Once the object is instantiated the APFM can instruct OM, in accordance with the OM API, to capture a representation of the underlying memory data of that object and the object class, in step 76. OM either relies on pointers given by the APFM, to identify where the data is buffered in either RAM or secondary , storage of digital device 1, or, uses, an assigned memory resource by the processor or the application functionality module. Thus, the present invention can accomplish the same function by writing the data to the memory resources, either RAM or secondary storage to achieve the same function of the pointer system. By writing the data to RAM or secondary storage, the present invention uses a function call in the OS that tells the processor to store the data in memory. In either the pointer or other memory resource method, the instantiation process of the present invention addresses the memory from its written and stored state.

In step 78, the underlying memory of the object is taken and its fundamental binary construct is determined. The binary construct is referred to either as a binary construct or the representation. In step 80, an object ID is attached to the binary construct. The object ID indicates to the API the type of data represented by the binary construct. The object ID is a serialized ID that is recognized by the OM API as the object class type. Therefore, object ID is used create object classes. The object ID and the AP-Object ID are different names for the same information, only the AP-Object ID refers specifically to the OM API object ID. Next, in step 82, the object ID and the binary construct are sent to at least one second digital device. The

OM copies the representation into the OM "Out" buffer, and the representation is sent over a link to at least one second digital device. The second digital device(s) are either running the first application framework, not running any application framework, or else are running a completely disparate application framework (second application framework). Additionally, the second digital device(s) can be running disparate applications one to another as well as to the first digital device (see FIG. IF). In step 84, the second digital device receives the object ID and the binary construct, and this copied into the OM "In" buffer on the second digital device, and in step 86, the second digital device reconstructs the binary construct to represent the original underlying memory from the first digital device. In step 88, the second digital device initiates a second object class, which is respective to the second digital device and corresponds to the first object class. Finally, in step 90, the second digital device instantiates the object.

Referring now to FIG. IE, an alternate embodiment of the OM is shown. This embodiment follows the same process as shown in FIG. ID and described above. However, in step 114, as indicated, the second digital device has the first application framework. This embodiment exemplifies that the OM functions to allows digital devices to share objects whether they are running the same application framework, disparate framework, or one digital device does not have an application framework. In the embodiment shown in FIG. IE, the OM API can simply use the object classes specified by the first application framework, since both digital devices have the first application framework, or the OM can follow the same process as shown in FIG. IE to accomplish sharing the object. Therefore, the OM is not limited to use in sharing objects between digital devices with disparate frameworks.

The processes, described above and shown in FIG. ID and FIG. IE can equally apply to objects that are instantiated on the second digital device(s) and re-instantiated on the first digital device. Furthermore, when a state change occurs with the object that is instantiated on either digital device, or at intervals determined by the APFM, the binary construct/representation and object ID can be sent to the other digital device(s) so that the state changes can be reflected in the instantiation of the object on the other digital device(s). In effect, OM networks objects by sharing those objects in simulated real-time between entirely separate digital devices, regardless of the compatibility of the OS or application that is sharing the object.

Referring next to FIG.2A and FIG. 2B, the preferred embodiment of the method of networking objects using an object router is shown. Referring first to FIG. 2A, the preferred embodiment of the OM process first digital device/ sending digital device, or, digital device 1 is shown. The first digital device retrieves or receives the object that is or will be shared between at least two digital devices (this step not shown). Whether the first digital device has received the object from another digital device, or else the first digital device retrieves the object from RAM or secondary storage, the following process shown in FIG.2A (and FIG.2B) applies. In step 130, the first digital device instantiates the object within a first application framework. In step 132, the object class of the desired networking functionality is initiated within the first application framework on the first digital device. In step 134, the code representation (from the first digital device) of the object and the object class are instantiated. Once the object is instantiated the APFM can instruct OM, in step 136, in accordance with the OM API, to capture a representation of the underlying memory data of that object and the object class. OM either relies on pointers given by the APFM, to identify where the data is buffered in either RAM or secondary storage of digital device 1, or, uses, an assigned memory resource by the processor or the application functionality module. Thus, the present invention can accomplish the same function by writing the data to the memory resources, either RAM or secondary storage to achieve the same function of the pointer system. By writing the data to RAM or secondary storage, the present invention uses a function call in the OS that tells the processor to store the data in memory. In either the pointer or other memory resource method, the instantiation process of the present invention addresses the memory from its written and stored state. In step 138, the underlying memory of the object is taken and its fundamental binary construct is determined. The binary construct is referred to either as a binary construct or the representation. In step 140, an object ID is attached to the binary construct. The object ID indicates to the API the type of data represented by the binary construct. The object ID is a serialized ID that is recognized by the OM API as the object class type.

Therefore, object ID is used create object classes. The object ID is synonymous with the AP-Object ID Next, in step 142, the object ID and the binary construct are sent to at least one second digital device.

The OM copies the representation into the OM "Out" buffer, and the representation is stuffed into an OM packet and sent over a link to the object router digital device in step 144.

Referring now to FIG. 2B, the object router has already sent the second digital device(s) the packet (not shown), and in step 146 the second digital device receives the OM packet from the first digital device via the object router. In step 148 the OM unstuffs the data from the OM packet and places the object data into an OM buffer.

The second digital device(s) are either running the first application framework, not running any application framework, or else are running a completely disparate application framework (second application framework). Additionally, the second digital device(s) can be running disparate applications one to another as well as to the first digital device (see FIG. IG). In step 150, the second digital device reconstructs the binary construct to represent the original underlying memory from the first digital device. In step 152, the second digital device initiates a second object class, which is respective to the second digital device and corresponds to the first object class. Finally, in step 154, the second digital device places the object data into the corresponding object class buffer, and finally, in step 156, the second digital device instantiates the object. The processes, described above and shown in FIG. 2A and FIG. 2B can equally apply to objects that are instantiated on the second digital device(s) and re-instantiated on the first digital device. Furthermore, when a state change occurs with the object that is instantiated on either digital device, or at intervals determined by the APFM, the representation and object ID can be sent to the other digital devices. so that the state changes can be reflected in the instantiation of the object on the other digital devices. In effect, OM networks objects by sharing those objects in simulated real-time between entirely separate digital devices, regardless of the compatibility of the OS or application that is sharing the object.

The application programmer can program the API to harness the OM system in anyway they desire. The OM is very easy to program because the OM network uses generic function calls that are utilized by the application programmer to network any type of object or other data structure. The function calls take the place of middleware, establishing a real-time "type" of middleware using real time function calls. A handful of function calls harness the entire OM system without the need for middleware, which acts to slow down a conventional network. These function calls, described in the OM API, allow the network to get and share objects, allow the shared objects to be set up, and allow digital devices to invite other digital devices to a shared object. Thus, a plurality of function calls allows for the entire OM to function as a true "object manager". The application programmer creates and defines the object code used for the various applications running in the networking session. This object code is used to create a universal object language with respect to the type of data contained in the shared object.

It is critical to note that the binary construct is a particular instantiated object that the application programmer wishes to instantiate on another digital device. From the perspective of the OM network, OM has no regard for the data content of the binary construct. Due to its cross platform networking functionality, the object router does not process the binary construct content. Rather, OM considers the networking of binary constructs and object IDs as "Shared Objects," which are also referred to as "shared object types". The "shared objects" can be further defined as "categorical data flow structures". Throughout the contained herein, "shared objects" are referred to as an "AP-Object" from the perspective of the application programmer. Correspondingly, from the perspective of the OM network, which deals with AP-Objects generically, they are herein referred to as "shared objects". Accordingly, the two designations are essentially two aspects of the same entity. For illustration, a collaborative network session such as a "lounge" is a shared object. In the preferred embodiment, these shared objects may be further specified with their categorical AP-Object types. OM, in its preferred embodiment uses the tilde (~) to categorize specific object types such as "draw" objects or "text" objects. In alternate embodiments, this could easily be designated by a "/" or any other special character or none at all. Thus, when OM is used to host a collaborative session, the session name may be called "lounge" which is a shared object. Within that lounge, clients are sharing particular draw and text object types which are designated as "lounge~draw" and "lounge~text," each of which OM deals with as a separately indexed "shared object" with a numerical "shared object ID."

An OM networking session is a connection or link between at least one client digital device and one object router digital device. The object router digital device can either be a client that also acts as the object router (shown in FIG. 2G), or, alternatively, acts solely as an object router (shown in FIG. 2F). The object router digital device can act as the object router for more than 1 networking session simultaneously. The connection or link can be any type of connection or link, including, but not limited to, an Internet connection, a satellite communications link, or an Ethernet connection, or any other connection or link known in the art to connect or link two digital devices.

Referring next to FIG. 2C the preferred embodiment of the OM Packet structure is shown. In alternative embodiments, the configuration of the OM Packet structure can be entirely different, with more or less or different components in any order, or combination of orders. The OM Packet functions to transfer data during a networking session. The OM Packet includes the IP address 160, or sending client identifier, which, in the preferred embodiment, is the IP address of the digital device that sent the message. Although in the preferred embodiment, the client's IP address is used, in other embodiments, this can be any other data link designation of the client's endpoint or node. The OM Packet additionally includes the port address 162 for the digital device that sent the OM Packet. The total packet size 164 in bytes is listed next. Although, in the preferred embodiment, the total packet size 164 is placed at the beginning of the packet, in other embodiments, this information can be placed anywhere. However, the further back the total packet size 164 is placed, the less efficient the OM system. The OM Packet next includes several identifiers (IDs) that can be represented in data including characters, strings, fixed or variable integers, or any other bit specification of any size. The system message type ID 166 and the shared object ID 168 are, in the preferred embodiment, both a 16 bit ID, in other embodiments this can be any other data. The client ID 170 is next, which in the preferred embodiment, is a 32 bit ID. In other embodiments, the client ID 170 can be any other data. Finally, the object ID (AP-Object ID) and the binary construct (AP- Object) 172 is included in the OM Packet.

Referring next to FIG. 2D the preferred embodiment of the OM Packet protocol on digital device 1 is shown. The OM Packet protocol starts at step 174 where the OM copies the AP-Object into the OM "Out" buffer. Next, in step 176, the OM stuffs the data from the OM "Out" buffer into the OM Packet structure. In step 178, the OM attaches the system message type ID to the OM Packet structure. The system message type ID identifies which type of file data is contained in the message. In step 180 the OM attaches the shared object ID to the OM Packet structure. The shared object ID can be either a numerical ID such as "1458" or a text ID such as "DRAW". The shared object ID identifies this file data as a shared object to the OM, for use in indexing the shared object and the events that transpire with respect to the shared object. In some alternate embodiments, and described in more detail below, the OM attaches an OM Packet ID to the OM Packet structure in step 182. In the preferred embodiment, however, and described below, step 182 is not implemented, and the OM Packet ID is attached by the object router (shown in FIG. 2E). Also in some embodiments, the client ID is attached at step 182. In other embodiments, and shown in FIG. 2E, step 196, the object router attaches the OM Packet ID, and in FIG. 2E, step 198, the object router attaches the client ID to the OM Packet. Referring again to FIG. 2D, the OM next determines the total OM Packet size (in bytes) and attaches this specification to the front of the OM Packet structure in step 184. Finally, in step 186 OM sends the OM Packet to the object router.

Referring now to FIG. 2E preferred embodiment of the OM Packet protocol on the object router is shown. The process starts with step 190 when the object router receives the OM Packet in client "In" buffer. In step 192, the process of the OM protocol begins. Tf, in step 194, OM determines that the OM Packet will be sent to other clients, in the preferred embodiment described below, object router attaches an OM Packet ID in step 196. In step 198, in some embodiments, the OM attaches the client ID of the originating digital device to the OM Packet structure. The client ID serves as a data originator identifier. In alternate embodiments, the client ID can be attached to the OM Packet structure by digital device 1 in previous steps (see FIG. 2D), however, this is unnecessary given that object router inherently identifies the origin of the OM Packet by receiving the packet from the sending client (herein referred to as digital device 1). Next, in step 200, the OM determines the new total OM Packet size and the OM revises the previous size specification of the OM Packet structure. Finally, in step 202, the OM copies the revised OM Packet into the client "Out" buffer(s) for those client's in which the OM Packet will be sent. OM assigns an ID to each packet that is sent over the OM network to fulfill the data flow requirements of a shared object (hereinafter OM Packet ID). In the preferred embodiment, the object router attaches an incremental counter to the shared object ID to generate a unique OM Packet ID. In alternative embodiments, the unique OM Packet ID can be assigned by the object router using any ID that can be represented in data including fixed or variable integers, or any other bit specification of any size. For static AP-Objects, the OM Packet ID is also a representation of the instantiation of an AP-Object on another or several other digital devices. For dynamic AP-Objects, the OM Packet ID is a representation of a particular state of the object. Accordingly, OM is able to determine, from the OM Packet ID, which particular data transmission altered the AP-Object state and in which chronological order. In either of these embodiments, the OM Packet ID allows for selective or managed deletions or replacements of AP-Objects or the particular change in state of the AP-Object. In alternative embodiments, the client can assign an ID to the OM Packet before sending it. In this embodiment, the OM Packet ID is attached to the OM Packet protocol structure. The client can assign the OM Packet ID as an incremental counter or by the client using any ID that can be represented in data including fixed or variable integers, or any other bit specification of any size. If the client utilizes an incremental counter method, attaching the incremental counter index to the client ID will generate a unique OM Packet ID. In either of these embodiments, the client is able to identify and index, independent of the other interconnected modules on the OM network, particular OM Packets that are sent from the client. Accordingly, the OM Packet ID allows for selective or managed deletions or replacements of AP-Objects or their change in state, at the client level.

Once the OM Packet is sent to the specified clients, the OM then generates the shared object on these clients, relying on either the OS object code or specific object code running on digital device 2. It is not necessary that the clients run the application related to the shared object. The clients then process the data, just as if the client opened the file from secondary storage. The OM on client digital device 2 is able to process the shared object because the OM running on client digital device 2 reads the object type and is able to process the data using object classes that are previously compiled and executed on the respected digital device. Client digital device 2 will also know where the data originated through the use of the client ID. If client digital device 2 chooses to send a message with respect to this particular shared object, when client digital device 2 sends this data to client digital device 1, the OM Packet ID will be assigned to this specific data from client digital device 2, and will be the next incremental integer. The data will also be given the shared object ID that will be identical to the message from client digital device 1. Additionally, the object router will place client digital device 2's client ID in the packet; thus, client digital device 1 will know where the data originated. The preferred embodiment includes the ability of the OM to run a networking session with a number of client digital devices, each throwing the shared object around the network, and each OM Packet ID will be stored in the OM object router memory. This function makes it possible for the object router to allow selective or managed deletions or replacements of the AP-Objects (for static objects) or the particular change in the state of the AP-Object for dynamic objects, and to categorically store the history of the shared object session.

Once the networking session is initiated, and both the object router and the client digital devices are connected through a network, the OM continues to transfer information from the object router to the client digital devices and visa versa. The processes shown in FIG.2A and FIG. 2B can be applied to any type of shared object. For example, with respect to input output shared object, an image displayed on the object router digital device can be displayed on the client digital device's screen, using OM and the object management utilities provided by the object router digital device's own OS. Additionally, any input device may be cross-flowed to either digital device, including an application running on a different digital device.

The object router in the OM acts as both a user management system, where the object router creates and supervises the networking session, and as a router, where the object router keeps track of the clients and their IP addresses, and sends the OM Packets to the correct locations.

Referring now to FIG. 2F and FIG. 2G, diagrammatic representations of the OM network architecture based on the present invention is shown. Any multitude of digital devices can participate in the networking session. However, one of the digital devices is designated as the object router digital device 220. The other digital devices are client digital devices 222, 224, 226. All of the digital devices in the network are running the OM 228 and are connected through a link 230, which can be any data linkage, including an Internet, wireless, or an Ethernet link. Although each digital device is running the OM 228, depending on whether the digital device is acting as a client or the object router, the digital device runs that respective module of OM. Thus, the client digital devices 222, 224, 226 run the client module 232, and the object router digital device 220 runs the object router module 234.

Independent of whether the OM network session is set up as shown in FIG. 2F or FIG. 2G, the session is initiated and runs the same way, using the same modules and operations. Referring to both FIG. 2F and FIG. 2G, embodiments of the OM digital device dedicated as the object router 220 is shown. The object router 220 digital device is not a traditional "server" but rather, is only dedicated as an object router for purposes of this networking session. In FIG. 2G, client 1 222, and client 2224 are each connected to the object router 220, but the object router 220 additionally serves as client 3 226. The OM 228 allows for a digital device to act both as a client and an object router. In either embodiment, the clients and the digital device dedicated as the object router run OM 228. Thus, all of the OM 228 modules reside on each of the digital devices participating in the networking session. However, only certain modules are utilized by each digital device, depending on the digital device's capacity during the networking session, whether as a client or an object router. If the digital device will act as the object router, the digital device will run the OM module that enables the router function, and this digital device is then termed the object router 220. The networking session begins with the negotiation phase. Referring to both FIG. 2F and FIG. 2G, the object router 220 sets up the linklist function in the RAM on the digital device acting as the object router 220. This linklist function allows OM to supervise the networking session, by indexing all of the packets. The linklist indexing function is described in more detail below.

Referring only to FIG. 2G, during the negotiation phase, two separate buffers are created on each client digital device 222, 224, 226. Each buffer is a temporary memory space for data. One buffer on each client 222,

224, 226 is dedicated to incoming data 236, 238, 240, and the other to outgoing data 242, 244, 246. All of the data flowing into and out of the buffers flows through a single input/output port on the digital devices (not shown). The data continually cycles through the buffers, giving the buffer architecture a dynamic characteristic. The buffer architecture follows a "first in'V'first out" strategy. A separate input and output buffer 248 for each client IP address is set up on the object router 220.

Additionally, a shared object ID list containing the different types of shared objects that will be shared during the networking session are present on the object router 220. The object router 220 also stores the historical data for each networking session. The historical data includes all of the shared objects transferred between the clients 222, 224, 226 during the networking session. The historical data is indexed by OM Packet ID. Therefore, if a client joins the networking session after the session is initiated, the new client can acquire part or all of the historical data for a particular shared object that was recorded prior to the new client joining the networking.

Once the networking session has been initialized, each client 222, 224, 226 then receives the IP address of the object router 220. After the IP address is acquired and the data linkages are made, each client 222, 224, 226 is then involved in the processing of the information sent over the network. The list of shared object IDs is also present on the clients 222, 224, 226.

Once a new user is set-up on the OM system, the new user's client ID is linked to specific shared objects. The new client then has the option of receiving the shared object's history. This will ensure the new user receives all shared object data including the AP-Object that have transpired between the clients in the networking sessions with respect to that specific shared object. Using the pointer method, in one embodiment of the invention, the OM stores the function pointer on this shared object, and then adds the new client to the shared object list. However, in the preferred embodiment, the data is written to buffers in RAM or secondary storage. Next, the object router is told to subscribe the new client to the object router, and then the object router will now send all OM Packets regarding this shared object to this new client.

Object Utility (OU) is the OM data packaging and conversion utility module that is capable of maximizing the efficiency of data flows in a real-time cross-platform network. The OU works by combining data packaging functions with conversion functions, these being coordinated on two or more digital devices on a network.

The OU is herein referred to as the "conversion utility" module. The conversion utility has the following advantages: independence from machine-specific representation of large numbers (ie. big-endian vs. little-endian), variable length strings can be represented, and different types (ie. Strings, integers, chars, etc.) can be combined in any order and amount (the buffer must be large enough to store what is converted). Big-endian / little-endian is how a machine represents large numbers (more than one byte). Different machines may store the most significant byte on the left (big-endian) or on the right (little-endian).

The conversion utility essentially uses two types of stuff and un-stuff processes: stuffLong and unStuffLong, and stuffShort and unStuffShort. These are the basic function calls that enable bit shift formatting and reformatting for transmission of object level data between "big endian" processors that address the memory with the significant byte first and the "little endian" processors that address memory with the significant byte last. The conversion utility API describes that combination of stuff/un-stuff functions used for the combinations of machines being networked. By utilizing the conversion utility API and respective function calls (the names of which may be different for alternative embodiments), the network programmer can, with ease and convenience, engage the entire data packaging and conversion process required for most data types to fulfill the desired networking functionality. The conversion utility function calls are simply embedded in the networking application or other system without unnecessary duplication or coding requirements for the entire process.

The decision of which stuff/un-stuff function to use is either based on the digital device the conversion utility is running at the time the stuff/un-stuff process is executed, or, on the order of instruction sets in which data is processed by each particular microprocessor.

The conversion utility translation process can also be customized to perform other data formatting conversations. For example, files formatted for one application can be converted to another file format that can be read by another application. These file format conversions are performed at the originating digital device while the file is being transferred to another digital device or multiple digital devices. Therefore, conversion utility performs the file conversion process by the way that the data is packaged and unpackaged while it is being transferred by a network to another digital device. The result is a network with no delays associated with setup and processing of a secondary file-type conversion utility. Thus, the OM conversion utility functions in a way that requires that memory be allocated just once while the conversion is processed and the data are buffered. The conversion utility can work with respect to any network operating at an object level. The conversion utility is a module in OM. The conversion utility is specific to the application functionality, and therefore to the APFM. The OM allows the sharing of objects cross platform. This function of the OM is accomplished through the conversion utility module. The OM is not application oriented, therefore it is a way of getting the same information to go to places/ digital devices that it would not have gone before. The key is to keep the information the same, and not to change the information in any way. This is the utility of the OM. The conversion utility uses an index to both keep track of the number of bytes stuffed into a packet, and also to index the type of data in which is being stuffed. The data type is communicated to the conversion utility through the APFM. The conversion utility construct is indexed and is only meaningful at the application level.

The APFM knows what the fundamental building blocks are, and since the objects are application specific, the

APFM communicates to the conversion utility the type of data being stuffed, and through the OM coordinated protocol (which depends on the APFM) the conversion utility will represent the type of data contained in the packet. The APFM is always running, and indicates to the conversion utility the type of data in the packet.

Because the AP-Object in the packet is a derivative of the original object class structure, the conversion utility just takes what is already there and uses this to recreate the object on another digital device.

In addition to indexing the type of data contained in the AP-Object, the conversion utility "stuffs" and

"unstuffs" in such a manner that the order of the bytes is preserved regardless of what types of digital devices that are used. Referring now to FIG. 3A, the preferred embodiment of the stuff and unstuff process is shown. The process starts in step 300 where the data to be stuffed, having an original order, is divided into a predetermined number of bytes. In the preferred embodiment, if the data is a long integer, then the data is divided into four separate bytes. If the data is a short integer, then it is divided into two separate bytes. Next, in step 302, the conversion utility stuffs the data into a first buffer following the stuff process in step 304. The index is set to 0 for purposes of counting the number of bytes stuffed.

The preferred embodiment of the stuff process is shown 304. First, in step 306 the highest order byte is stuffed by bit shifting to the right until the high order byte is in the lowest order position. Therefore, in the preferred embodiment, the stuff process follows a big endian order. However, as shown in FIG. 3B, in alternate embodiments, the stuff process 304 follows a little endian order, (see step 306 in FIG. 3B). The index is then increased by 1 in step 310. Next, in step 308, the next highest byte is stuffed by bit shifting to the right until the next lowest order position. Referring again to the little endian stuff embodiment shown in FIG. 3B, in step 308, the next highest byte is stuffed by bit shifting to the right until the next highest order position.

Referring now to both FIG.3A and FIG. 3B, in step 312, the index is increased by 1 to reflect the next byte that was stuffed in step 308. In step 314, a determination is made whether all the bytes have been stuffed. If all of the bytes have not been stuffed, then the process returns to step 308, another byte is stuffed, the index is increased by 1 in step 312, and the process returns again to step 314.

Once the determination is reached in step 314 that all of the bytes have been stuffed, then the process continues to step 316 where the new index value is set. This index value will reflect the total number of bytes that are stuffed in the packet. Next, in step 318, the buffer is sent to at least one second digital device. This is done using the OM. In step 320, a determination is made as to what type of processor the second digital device is running, either a big endian type processor or a little endian type processor. This information is used to make a decision whether to unstuff using the big endian unstuff process 326 or the little endian unstuff process 328.

If the processor is big endian, then the unstuff process 326 begins in step 330 where the conversion utility unstuffs the buffer one byte at a time from the highest byte order to the lowest byte order. After each byte is unstuffed, in step 334, a counter, set to the new index value from step 316, decreases by one. In step 336, if all bytes have not been unstuffed, then the process returns to step 330, until, in step 336, it is determined that all bytes have been unstuffed. Next, in step 340, the data is arranged to form the original order.

If the processor is little endian, then the unstuff process 328 begins in step 332 where the conversion utility unstuffs the buffer one byte at a time from the lowest byte order to the highest byte order. After each byte is unstuffed, in step 334, a counter, set to the new index value from step 316, decreases by one. In step 338, if all bytes have not been unstuffed, then the process returns to step 332, until, in step 338, it is determined that all bytes have been unstuffed. Next, in step 342, the data is arranged to form the original order.

In one embodiment of the present invention, the processes shown in FIG. 2A and FIG. 2B include, as part of step 142 in FIG. 2A, the conversion utility stuff process, and as part of step 148 in FIG. 2B, the conversion utility unstuff process. These embodiments are shown in FIG. 4A and FIG.4B, where FIG. 4A is an alternate embodiment of the process shown in FIG. 2A and FIG. 4B is an alternate embodiment of the process shown in

FIG. 2B. Both FIG. 2A and FIG. 2B are described above.

Referring now to FIG. 3C the preferred embodiment of the stuffLong and unStuffLong process is shown.

First, in step 350, the stuffLong process begins on digital device 1. The stuffLong process is detailed in step 352, where first, in step 354, stuffLong breaks up a long integer into four separate bytes. These bytes are then "stuffed" individually into the buffer, in their original order in step 356. Next, the unstuffLong process starts on digital device 2 at step 358. The unStuffLong process is further detailed in step 360, where, on the receiving end, the conversion utility effectively "unstuffs" the string one byte at a time in step 362, and then bit-wise arranges them together to form the original long integer in step 364. Another function of the conversion utility, the stuffString function (not shown) allows the programmer to "stuff any length string in the buffer (provided that the buffer is large enough).

The index is used to count and store the number of characters stored. The unStuffString function uses the index to determine how many characters should be "unstuffed" from the buffer. Using the index value allows the API to stack multiple "stuffs" together. Referring now to FIG. 3D, the preferred embodiment of the index process is shown. The process starts in step 370 where the index is set to zero. In step 372, as each "stuff is performed; the index is incremented by the size of the type that was "stuffed" (i.e. for a long integer, index is incremented by four); in other words, the index is incremented by a predetermined amount corresponding to the type of data that was "stuffed". This predetermined amount is set by the application programmer, and therefore, is not limited to those described herein. If it is determined in step 374 that there is still data left to stuff, then step 372 is repeated until all the data is stuffed. As the next "stuff" is stacked on, the index will be incremented again by the size of the type "stuffed". After all of the data is "stuffed", as determined in step 374, the index will represent the size of the data in the buffer in step 376. Thus, the networking application or other system can, at all times, determine the size of the data that is packaged in the respective buffer.

The nature of the index function allows for any number of "stuffs" and any types to be stacked together in any order provided that the following conditions are applied. First, the buffer that is used to store the "stuffed" data must be large enough to accommodate the entire string, because, in the preferred embodiment, there is no over-write protection. However, in alternate embodiments, the conversion utility includes over-write protection. Second, the data received by the other machine must be "unstuffed" in the order that it was stuffed by the sending machine. For example, if the sender wrote: stuffLongO; stuffChar(); stuffShort(); then the receiver must write: unStuffLongO; unStuffChar(); unStuffShortQ;- Unstuffing in a different order will result in corrupt data. The conversion utility API of the preferred embodiment includes a "meta function call" that engages the correct function calls in the correct order for implementation on each respective digital device. The conversion utility meta function call adds convenience to the networking programmer and reduces the incidence of incorrect data as a result of improper implementation. The conversion utility "stuffs" and "unstuffs" data in such a manner that the order of the bytes is preserved regardless of what types of machines are used. The stuffLong function breaks up a long integer into four separate bytes. These bytes are then "stuffed" individually into the buffer, in their original order. The unStuffLong function, on the receiving end, effectively "unstuffs" the string one byte at a time and bit-wise arranges them together to form the original long integer. The stuffString function allows the application programmer to "stuff" any length string in the buffer (provided that the buffer is large enough). The index is used to store and count the number of characters stored. The unStuffString function uses the index to determine how many characters should be "unstuffed" from the buffer. Using the index value allows the application programmer to stack multiple "stuffs" together. At first, the index must be set to zero. As each "stuff is performed, the index is incremented by the size of the type that was "stuffed" (ie. for a long integer, index is incremented by four). When the next "stuff" is stacked on, the index will be incremented again by the size of the type "stuffed".

Although the processes are described using pointers, as defined above, the buffer can either mean a pointer system or a system in which the data is written to memory resources, i.e., RAM or secondary storage and having the applicable processes address the memory from its written and stored state.

Referring now to FIG. 3E, the preferred embodiment of the stuffLong process is shown. The process starts in step 380, where the stuffLong function takes a long integer (4 bytes) and "stuffs" each byte individually into the buffer (buf). In step 382, the highest order byte is "stuffed" first. This is done by bit-shifting to the right until the high order byte is now in the lowest order position. In step 384 this value is type-cast as a char and assigned to buf. Next, in step 386, the next highest byte is then bit-shifted to the right until the value is now in the lowest order position and is cast as a char. In step 388, this value is added as the next char (buf[(*index)+lj). Next, in step 390, the next byte is also shifted, cast as a char, and added to buf. In step 392, the last byte is just cast as a char and added to buf. As described above with respect to FIG. 3A and FIG. 3B, the alternate embodiment (shown in FIG. 3B) where the data is stuffed as shown in step 306 and step 308 also can be applied to the process shown here in FIG. 3E, and more particularly, in step 382 and step 386.

Referring next to FIG. 3F, the preferred embodiment process of the unStuffLong function is shown. The function unStuffLong takes a character (char) pointer and "unstuffs" it into a long integer. First, in step 400, buf is bit-shifted to the left (buf [*index]«24) and type-cast as a long integer. In step 402, buf is incremented to point to the next char (buf [*index+l]), then, in step 404, bit-shifted left by 16, and, in step 406, it is cast to a long integer. The remaining two chars are converted to long integers in the same way. If, in step 408, it is determined that there are still char left, then the process continues back to step 402 until all four of the char have been "unstuffed". Finally, in step 410, all four of these long values are bitwise arranged together to re-create the original long integer value that the function returns.

The conversion utility also has a stuffShort function (not shown). This function "stuffs" a short integer (two bytes) into a buffer in the same manner as stuffLong. The main difference between the two functions is that only 2 bytes have to be stuffed instead of four. The function unStuffShort takes a char pointer and "unstuffs" it into a short integer in the same way as unStuffLong except that only two bytes need to be "unstuffed".

Referring now to FIG. 3G, the preferred embodiment of the stuffChar and unStuffChar process of the present invention is shown. The conversion utility uses the stuffChar process to stuff character type data. The stuffChar function begins on digital device 1 at step 430. First, in step 432, function stuffChar "stuffs" one character (val) into a char buffer (buf). Next, in step 434, val is type-cast as a char before being assigned to buf (buf[*index]=(char)(val)). Then, in step 438, the function unStuffChar begins on digital device 2, and in step 440

"unstuffs" one character from a buffer (buf) and in step 442, returns one character.

The conversion utility uses the stuffString and unStuffString function to stuff a string of data into a buffer and unstuff a string of data from a buffer. Referring now to FIG. 3H, the preferred embodiment of the stuffString and unsStuffString function is shown. The function begins with step 450, where function stuffString "stuffs" a string into a buffer (buf). In step 452, the string (str) is copied into buf using the string function strcpy. Each chiracter of the string is copied into its own byte of memory. An index is used to store the length of the string (number of bytes). Next, in step 454, the function unStuffString "unstuffs" a string from a buffer (buf). The string is next copied from buf to str using strcpy in step 456. The function returns the string in step 458. Referring next to FIG. 31, the preferred embodiment of the stuffMemory function of the present invention is shown. The function begins in step 470 where the function "stuffs" a piece of memory into a buffer (buf). In step 472, the pointer points to the first byte of the memory to be copied. The size of the memory to be copied (Length) is determined in step 474. The memory is then copied into buf using the function memcpy in step 476. Once a network is established between two or more digital devices, a short command from the application programmer to the network sets up the conversion utility. It is this short command that allow for the implementation of the conversion utility, and therefore, for the process of having a cross platform data network. The conversion utility allows for cross-platform conversion of data conversion in real time.

Using the big endian, little endian storing, the most significant byte is stored in the lowest/highest address. The separation of bytes accesses the big endian, little endian and allows for the conversion utility to work this way, and for the real-time conversion for any combination of data types and conversion types that are necessary for networking data between the same or cross platform digital devices (i.e. OS and processor types) for any number of digital devices on a single or multiple network, this occurring in the same or multiple buffers.

The networking aspect of the OM can include a number of different modules, and in any various combinations, to aid in the networking functions of the object router. Referring now to FIG. 5, an overview of the OM networking system including all of the various modules of OM is shown. In other embodiments, and shown in FIGS. 6 through 7F, any number of the modules 504, 506, 508 and the corresponding modules 516, 518, 520 can be included in the OM.

Referring back to FIG. 5, the sending digital device sends an OM packet in step 500. This packet is stuffed and indexed using the conversion utility in step 502. The conversion utility converts the data contained in the OM Packet into the correct data format for use by the receiving digital device. The conversion process is described in more detail above. The OM packet then goes through a compression layer 504, an encryption layer 506 and an authentication layer 508. The OM packet then arrives on the receiving digital device in step 510. The OM packet is unstuffed in step 514 by the conversion utility, and then the data is processed through the receiving digital device corresponding authentication layer 516, encryption layer 518 and compression layer 520. These corresponding layers check authentication of the sender, de-encrypt and de-compress the data so that it may be used by the receiving digital device. In step 522 a determination is made whether or not the complete OM packet has arrived. If it has not, then the process returns to step 500. This process is repeated each time an OM Packet is either sent or received by a digital device in the networking session. The compression, encryption, and authentication layers are not always necessary, and therefore they are options that must be elected by the application programmer for each application. In other embodiments of the present invention, the OM Packet is only put through the conversion utility

(see FIG. 6).\ In another embodiment, the OM packet is put through a compression layer and the conversion utility only (see FIG. 7A). In yet another embodiment, the OM packet is put through only the conversion utility and the encryption layer (see FIG. 7B). In another embodiment, the OM packet is only put through a conversion utility and an authentication layer (see FIG. 7C). In yet another embodiment, the OM packet is put through the conversion layer, the compression layer and the authentication layer (see FIG. 7D). In another embodiment, the

OM packet is put through the conversion utility, the compression layer and the encryption layer (see FIG. 7E).

And, finally, in another embodiment, the OM packet is put through the conversion utility, the encryption layer and the authentication layer (see FIG. 7F) The compression layer can be any compression layer known in the art. In the preferred embodiment, the encryption layer is either SSL, secured socket layers, Data Encryption Standard (DES), Triple DES, Skipjack, or any other encryption layer known in the art. In the preferred embodiment, the authentication layer is MD5, or any other authentication layer known in the art. This layer is a checksum and ensures that the OM Packet module has come from the source it says it came from. The authentication layer checks to ensure the data has not been snuffed. The authentication layer checks the size of the packet that is received against the size of the packet, specified in the byte size section of the OM Packet. If these byte sizes do not conform, the object router does not deliver the packet, because it has been snuffed.

Referring now to FIG. 8, a diagrammatic representation of the cross-platform aspect of preferred embodiment of the OM is shown. For explanation purposes, assume the object router 220 is running an Apple® OS, while the client 222 is running an OS written by Microsoft®. The OM 228 allows networking between these two digital devices, regardless of the fact that they are running two different OS. The OM 228 packs the data using a "big endian" (i.e. significant byte first order), as do most computer networks. To allow for cross-platform networking, the OM includes a module that converts the network byte order for "little endian" (i.e. significant byte last order) digital devices. In the embodiments of the OM 228, the byte order conversion may, for instance, include any of the following four methods. One, unsigned long htonl (unsigned long) host to network conversion for long ints (4 bytes). Two, unsigned short htons (unsigned short) host to network conversion for short ints (2 bytes). Three, unsigned long ntohl (unsigned long) network to host conversion for long ints. Four, unsigned short ntohs (short) network to host conversion for short ints. On big endian computers, these functions simply return their arguments. In other embodiments, any method known in the art can be used for each specific type of data that is networked. This series of functions is described herein as "conversion utility".

OM 228 is compiled separately for each platform, using a C compiler, which is designed to compile for that platform. Once executed on each platform, OM becomes platform specific to that digital device. However, the OM 228 is not limited to the OS described above, rather any OS known in the art can be networked with any other OS known in the art using the OM 228. These OS include APPLE®, WINDOWS®, LINUX®, UNIX®, SOLARIS® and PALM OS® and any other operating system known in the art.

The OM accomplishes its object management function through the use of object type variables. The following description of the process by which the OM operates is described in two parts. First, the OM from the client side is described in detail, and then the object router is described. The OM, in practice, is performing both the client side and the object router side at the same time, but is described separately herein for illustration purposes only. The OM is running on all digital devices involved in the OM networking session. To start a networking session, the object manager must be executed by first linking with other OM subroutines. Next, the identity of the global variables and functions are given. The OM is then initiated.

The client OM functions as follows. To establish an OM networking session, a connection must first be established between the OM running on the client digital device and the object router that is running on one other digital device. The object router uses a function to establish the connection between the clients and the object router. This function binds the TCP of the object router to the current IP address and port of the client, establishing a data linkage between the object router and the clients. This function of the object router opens sockets and sets the client ID for the connected clients. Referring now to FIG. 9, the networking session starts when the client digital device in step 600 first establishes a connection with the object router digital device through a data link. In step 602 the client digital device then counts 15 seconds, and sends a message to the object router digital device in step 604. This message tells the object router digital device that the client digital device is connected to the network. The object router digital device responds in step 606 and sends a message to the client digital device. The client digital device counts for 30 seconds in step 608, and in step 610, if the client digital device does not receive a message from the object router digital device for 30 seconds, the client digital device disconnects from the object router digital device in step 612, and this ends this networking session between this client digital device and the object router digital device. However, if the client digital device does receive a message from the object router digital device in step 610, then the message signals resume, and the OM cycles to step 602. Although, in the preferred embodiment, the above increments of time are used, the OM is not limited to these time increments. Any time increment could be used in this process. The process shown in FIG. 9 and described above is the preferred embodiment for the object router to maintain a list of which clients are participating in the networking, and for the clients to track whether the networking session is still current.

The OM creates memory buffers based on the byte size of the incoming OM Packet (these are described as "In" and "Out" buffers below). After the full OM Packet is received the data is read and processed according to the message handling described below.

Messages are handled as situations using a switch statement, which is a multi-way decision test known in the art. It is not a variable, but rather tests a value against many options. Each option is referred to in the art as a "case" or "case statement". The OM function uses several types of case statements. The application programmer adds specific case statements depending on what the application needs to achieve. There is a case statement specific for each OM system function. The names of the case statements can vary, depending on the application programmer.

The case statements serve as the instructions for handling objects that are being dealt with at a low level or a high level, depending on which networking functionality is desired by the application programmer. The application programmer creates a message type for every shared object that is sent over the object router. These message types tell the object router to list, create and delete shared objects, and as such, this is at the center of the OM functionality. A reference integer is assigned to each case statement, and everything a client sends to the object router has a message type assigned. The message type correlates to a case statement and is "switched" accordingly. Application programmers can add their own message types beyond anything that is already present on the

OM. Accordingly, the OM is a type of program for any sharing application, and for every new application, the application programmer must add additional message types to the OM.

For purposes of the following description, the term "client" refers to the client digital device. Turning briefly to the object router, once the networking session is negotiated, the object router begins the linklist subroutine. The linklist subroutine represents how the OM organizes the shared objects, and manages the shared objects to the digital devices participating in the networking session. One list includes all client digital devices connected to, and participating in, the networking session. The object router continuously updates this list. The client ID list is connected to the client list. For each client connected, the object router maintains a list of the respective client IDs. Additionally, the object router maintains a shared object ID list. This includes a list of the entire shared object IDs that OM sets up for each AP-Object data flow, or shared objects. Finally, the object router maintains a notification list. This list tells the object router the connected clients that are sharing each shared object in the object list. All of these lists are linked together, by the linklist subroutine.

Referring back to the client OM, the client OM sends messages in addition to handling messages that are received by the client. The OM notifies the client of a new client joining the shared object (i.e. session). The OM then notifies the new client that they are connected to the session, and sets up the new client on the session. This is a temporary process, and the OM sets up a virtual networking session. These sessions consist of shared objects or AP-Object data flows and an application programmer can configure the program to request data if a new client calls for a new shared object. The OM object router serves to manage the shared objects of the networking session. The OM uses a linklist function to manage and index the shared objects and the clients. The linklist function operates through use of the incremental counters, indexing the shared objects, IDs, OM Packet IDs and the client IDs. The OM is capable of linking the clients with the shared objects this way, because of the OM Packet architecture. Once a shared object is initiated, the object router then starts storing the historical data relating to the particular shared object. Additionally, the object router keeps track of the client digital devices both participating in the networking session, and participating in each of the shared objects. The process is as follows. Referring now to FIG. 10, for a given shared object, the process starts in step 620, where a message is sent by a client to the object router to set up or join a shared object. In step 622, the OM checks whether this shared object is in the linklist. If the shared object is not found in the linklist, this signals to the object router that this is a new-shared object. Next, in step 624, the shared object is added to the linklist. In step 626, if a client has sent a delete command to the object router to delete a specific AP-Object ID in step 628 the linklist function deletes this AP-Object ID from the linklist.

However, if a delete command is not found in step 626, then in step 630, the linklist function treats the shared object as new data to add to an existing shared object found in the linklist. In step 632, this new data is added to the existing shared object in the linklist, and in step 634, the client ID of the digital device that sent the data is added to this new shared object. If, in step 636, it is determined that a client logged off the networking session (determined from the process described above in FIG. 9) then, in step 638, the linklist function removes that particular client from the shared object and the client ID list. The process illustrated in FIG. 10 will continue to cycle with respect to each shared object, until the shared object is deleted from the linklist, or until the networking session ends. Referring now to FIG. 11 A, a diagrammatic representation of the preferred embodiment of the permissions function is shown. The OM 650 includes a permissions function in some embodiments. The permissions function includes a query module 652 that is layered over the permissions module 654. The query module 652 is toggled, and includes another toggle where the client is queried whether they wish a specific client to have access to specific shared objects.

The permissions module 654 includes two levels. The first level, the object router level 656, is another linklist, where this linklist function permits certain clients to have access to shared objects. The object router prevents clients from joining a shared object unless they have permission to participate. If access to a shared object does not exist for a specific client, the object router will not accept an OM Packet from that client with respect to that specific shared object.

The second level, the client level 658, is a permissions table that is set up at the client level to determine which clients have access to specific shared objects or function calls of the client OS. The permissions function is a system for controlling access to objects being shared in the networking session. This level of permissions additionally allows certain clients access to only specific AP-Object IDs. The application programmer establishes the client level permissions. A permissions table is an AP-Object ID list with a logic sequence attached to each controlled shared object. The logic table is based on the embedded AP-Object ID. The permissions table is a separate logic sequence put on top of every other logic sequence before the OM will manipulate or process the data. The permissions table lists the clients, and the corresponding shared objects or function calls that are controlled, and grants the client permission to specific AP-Object IDs. The OM reacts when the incoming client data includes a particular combination of client ID and a specified shared object or function call. The OM then takes the action, as determined by the logical sequence, for example, permission qualification or denial. This is possible because of the OM Packet structure placing the AP-Object type and client ID on each message. If the client is not permitted, then the object router sends a message to the originating client stating that the action is not permitted. For example, a client having client ID 3 sends an OM Packet having the following AP-Object IDs: 16, 17, 18, 19 where these specific AP-Object IDs refer to circle, fill, red and delete respectively. The OM will check for permission for client 3 to perform each of these functions. If it is found that client 3 does not have permission to delete, then the other actions will be taken, but the delete will not occur. The OM will send a notification message type to client 3 that the delete action is not permitted.

Referring next to FIG. 1 IB, the preferred embodiment of the process the OM applies to completing the permissions module function is shown. In step 660, an OM Packet is sent by digital device 1 to digital device 2. In step 662, the OM Packet is accepted by the object router. In step 664, the object router then applied the linklist function and permissions module. Then, using the linklist function, the object router compares the cliend ID and the shared object ID (on the OM Packet) to the permissions linklist. If the client identified by the client ID has permission to access the shared object ID, the object router allows access to the shared object ID and proceeds to step 666. However, if the client ID does not have access to the shared object ID, the object router denies permission to the shared object ID and sends a denied access message to the client (not shown). In step 666, the object router packs the OM Packet into a buffer, and in step 668, the object router sends the OM Packet to digital device 2.

The input and output buffers that have been described above are set up on each client by the OM and work together to significantly increase the operating speed/throughput of the network connection. Referring now to FIG. 12, in step 670 the object router continuously monitors each input buffer. In step 672, the object router will ask whether an OM Packet has arrived from any of the clients. If an OM Packet is received, in step 674 the object router determines, from the OM Packet, the total size of the data contained within the packet. In step 676, the object router determines whether the size of the data received equals the size of the data specified in the OM

Packet. If the size of the data received is not equal to the size of the data specified in the OM Packet, then the object router will go to step 678, and continuously monitor the data received in the buffer to determine precisely when the full packet has arrived. If step 680 determines that new data has arrived, the object router will go to step

674.

Once the size of the data received is equal to the size of the data specified in the OM Packet, the object router will proceed to step 682 and will replicate the data to the "Out" buffer. In step 684, the object router replicates the data to the necessary number of "Out" buffers for transmission to all clients that should receive the data pertaining to the specific shared object. Consequently, there are no unnecessary delays associated with routing the buffered data.

When a shared object is no longer required by the network system, the shared object is released from the shared object list. To release a shared object from the shared object ID list, the OM tells the object router to unsubscribe the shared object ID. This action removes the named shared object ID and the shared object ID from the linklist.

When a shared object is created, OM sets up and identifies these new-shared objects. Referring now to FIG. 13 the process of creating a shared object is shown. The process begins at step 690 where the OM determines the size of the AP-Object data that will become the shared object in the OM network, termed the object count amount. The OM, in step 692, then talks to the object router and tells the object router the object count amount. The AP-Object is then stuffed into the OM memory and the outgoing buffer in step 694. Next, in step 696, the new-shared object is assigned a shared object type ID. The total size of the shared object is then determined in step 698, and then in step 700, the OM uses the size determined in step 698 to prepare for the amount of information to pass into the expand block. Referring next to FIG. 14, a client receives a shared object using the following process. First, in step

710, the client intending to network an AP-Object, requests a shared object that is set up to network that particular AP-Object. Next, in step 712, the object router locates the shared object from the buffer where it is stored. In step 714, the object router asks if a shared object of that type exists. If the shared object has been created, and does exist, then in step 716, the object router notifies the client that the shared object requested exists. In step 718, the object router locates the shared object. Then, in step 720, the object router stuffs the "Out" buffer with the AP- Object of that shared object type, and finally in step 722, the object router sends the specific AP-Object to the client. In step 724, if the client receives the AP-Object, in step 726 the client sends a notification function call to the object router to notify the object router. In the alternative, if, in step 724, the object router determines that the AP-Object does not exist, then, in the preferred embodiment, the object router puts the requesting client on a linklist so that when the shared object is created the client is, by notification (at the clients option), linked to the AP-Object when it is created, or, automatically (with or without notification) linked to the AP-Object when it is created. In other embodiments, if, in step 714, the object router determines that the AP-Object does not exist, then the object router either does nothing, sends a notification message to the requesting client informing the client that there is no shared object of the type requested, or, in other embodiments, any combination of the embodiments described above are implemented. Any client can invite another digital device into the networking session. This is done through the process shown in FIG. 15. Referring now to FIG. 15, the process starts in step 740 where the client (inviter) sends an invitation to another digital device (invitee). In step 742, when the object router determines that the invitee has received the invitation, the object router, in step 744, notifies the inviter that the invitee has received the invitation. Next, in step 746, the inviter sends a command to the object router to notify the inviter user when the invitee user logs off the network. The object router then continuously checks whether the invitee has logged off the system in step 748. If the object router finds the invitee has logged off the system, the object router, in step 750, notifies the inviter.

The OM running the object router module operates according to the following description. The object router is handling multiple clients through the linklist function (described above). The object router acts as a hub between each OM unit running on each digital device involved in the network. The object router processes the detailed routing of data packets between clients without processing the data content. Using the linklist function, the object router keeps track of all shared objects.

The OM accomplishes these functions using the following processes. Referring now to FIG. 16, a representation of these processes is shown. In step 760, for each new client on the network, the object router opens a transport layer and in step 762, the object router associates this layer with that client's data link designation of endpoint node. In the preferred embodiment, this is the client's IP address, but in other embodiments, this can be any other designation of endpoint or node. Next, in step 764, the object router opens a socket for each client, and in step 766, the object router sets the data link designation of endpoint/node of the client to the socket, and initializes the strings in step 768. The object router then opens an accepting socket in step 770, and then sets a client ID for each client connected to the object router in step 772.

Referring next to FIG. 17, the process cycle by which the object router performs its object router functions is shown. The process starts at step 780. First, in step 782 the object router checks for client participation and connection to the networking session. This is the same process as shown in FIG. 9. The connection check tells the object router which clients remain on the network, and which clients have logged off. If a client logs off, then the object router removes the client from the client list and closes the socket to that client (described in more detail below). Following a client disconnect, no further shared objects will be sent to that client.

Next, the object router will check for any OM Packets being sent by any clients in step 784. If there is a packet being sent, the object router, in step 786, will stuff the data in the buffer, and then route the data to the appropriate client.

If, in step 784, the object router finds a client sent a character, then, in step 790, the object router checks if a client is sending a string of data. The client OM follows the procedure of first sending a one byte character following by a string of three-bytes, to the object router. This serves as a connection check to make certain the entire OM networking system is working. If the object router does not accept the character, this signals to the OM that there is a system error and the OM does not allow the sending of otherwise meaningful data. Although in the preferred embodiment, the connection check is performed as described above and shown in FIG. 17, in other embodiments the test is either not necessary, or is performed a different way. If a client is sending a string, then the OM will stuff this data into the "Out" buffer in step 786, and then route this data in step 788 to the appropriate client. Once an OM Packet is sent to the object router, the object router checks the data for its origin. If the data is from a client, the object router then reads the data. This process is exemplified in FIG. 18. The object router will only read a maximum number of bytes of data per read cycle. The application programmer sets this maximum number of bytes; therefore, it will vary from application to application. This function allows for large data packets to be read without slowing down the entire network.

Referring now to FIG. 18, the read process starts at step 800 where the object router reads the data in the packet. As described above, each packet specifies the size of the shared object. If the object router determines in step 802 that the size of the data is greater than the maximum number of bytes, then, in step 804, the object router copies the maximum number of bytes of data into a buffer. Next, in step 806, if there is data already in the buffer, this signals to the object router that this buffer is already being used to read the current data packet. In that case, the process continues to step 808 where a new buffer is created. If there is no data in the buffer, then the process skips to step 810. In step 810, the old data is copied into the new buffer. Next, in step 812 the new data is added to the buffer, in some embodiments where the pointer system is used, path "1" is taken, and in step 814 the old pointer is freed up. In other embodiments, path "2" is taken, and goes to directly to step 816. Using either path, in step 816, the new buffer is then stored in the object router.

The object router, in step 818, then checks to see if there is more data to be read. If there is more data, the process loops to step 804, and then the entire process is repeated until, in step 818, the object router determines there is no data left to be read, and the process ends.

If, on the other hand, there is less than the maximum number of bytes of data to be read initially in step 802, the process follows the path to step 820. The data is copied into the buffer, and then, in a first embodiment, path "1" is taken and, in step 822, the object router frees the old pointer, in the embodiment of OM that uses the pointer system. In a second embodiments, path "2" is taken and, the pointer system is not used, and step 822 is not completed, but rather step 820 is followed by step 824. In step 824, the object router stores the new buffer, and then the read process ends. After the object router reads the data, the OM Packet data is then processed in accordance with the OM

Packet protocol. The object router processes all data located in the "In" buffer. Any data that comes in from the client is processed by the method described below. However, if there is information to go out from the object router (system messages), then the object router processes the information. Referring now to FIG. 19, processing the data starts at step 840. Step 842 determines if there is greater than or equal to three bytes of data for the object manager to process. This test makes certain the data size is not less than 3 bytes of data, for data packets fewer than 3 bytes means there is no data to process. If there are at least 3 bytes of data, in step 844, the pointer is placed on the data in the "In" buffer. In step 846, the data is unstuffed from the buffer, and in step 848, the pointer is advanced to the next buffer. The embodiment described here is the pointer embodiment. However, in other embodiments, where the pointer system is not used, steps 844 through 848 are not completed. The object router will then check if there is any data left to process in step 850. If more data remains, then the object manager loops back to step 842, and the processing of data begins. If there is no data left to process, then in step 852, the object router disposes of the buffer completely, and in step 854, because the object router has determined that all of the data has been processed, the processing is complete. This processing of the data results in the object router creating memory allocations with pointers according to packet size. In the preferred embodiment of the invention, another module of the OM is the flow control module.

Using the flow control module, the object router can set the length of the packet being routed to the ideal size based on the type of information being transferred. The flow control module is used in conjunction with devices having a severe bottleneck, for example, wireless digital devices or PDA devices, or to allow for streaming data between other devices. The flow control module eliminates build up of data in buffers within the digital device's

OS and the Internet, and in certain embodiments, over-rides these buffering systems by operation of its own buffering system. The flow control module is also used, as shown in FIG. 22A and FIG. 22B to prevent bottlenecks by only sending the latest state of the object. With dynamic objects, this increases the efficiency of the networking system.

Referring now to FIG. 20A, one embodiment of the process of the flow control module is shown. This embodiment is used principally for transmission of large data sets in bottleneck conditions. Although the flow control module is described here with reference to data flows between the object router and a client, this process is applicable to data flows between a client and the object router (see FIG. 20B). In some embodiments, OM conducts a test to determine the network conditions. To establish optimal efficiency of data flow in the network, in step 870, the object router first runs a test to determine the network speed. This is called the data calibration tool. Next, if the object router determines there is no a bottleneck in step 872, then the flow control module, in step 874 is not required and the object router buffers data directly in step 876, otherwise the flow control module is initiated in step 878. The object router then reads the size of the data being sent in step 880. The size of the data is available as part of the OM Packet. The application programmer establishes the threshold size of data that is first sent to the receiving client. In step 882, the object router then buffers the predetermined amount of data to the receiving client's Out buffer and, in step 884, sends the data to the receiving client. In FIG. 20B, the same steps as described above are completed except, for example, the client runs the test in step 870, and the flow control module is applied to control bottlenecks in sending data from the client to the object router.

Referring now to FIG. 21A, another embodiment of the flow control module for accelerating data flows is shown. As with the flow control module shown in FIG. 20A, and described above, the flow control module in FIG. 21 A is also used by the client when sending data to the object router. The client embodiment of this flow control module is shown in FIG. 21B. Referring now to FIG. 21A, the OM uses this embodiment of the flow control module for managing different types of data. The process begins in step 900, where the size of the data is determined. This information is available as part of the OM Packet. If, in step 902, the object router determines that the data size is less than a minimum number of bytes, specified by the application programmer, the packet size is too small to transfer immediately and the object router holds the object in the "Out" buffer in step 904. If the data is not less than the minimum, but rather, it is determined in step 906 that the data is larger than the maximum number of bytes, in order to prevent the rest of the network from idling while larger packets are being transferred, the process proceeds to step 904, and the object router stores the data in the "Out" buffer until there is a lower amount of network activity. In step 910, when a low amount of network activity is determined, the object router then sends all the data in the "Out" buffer in step 912. Referring now to FIG. 21B, the client embodiment of this module is shown with the steps corresponding to those explained above in relation to FIG. 21A. The only difference is the client is acting to control data flow rather than the object router.

The next flow control module, shown in FIG. 22A, controls the flow of data by only sending the latest state or the most recent data. As with the flow control modules described above, this flow control module has embodiments implemented by both the client and the object router. Although in FIG. 22A, the object router embodiment is shown, in FIG. 22B, the corresponding client flow control module is shown. Each step corresponding to the steps described with respect to FIG. 22A, only the client is performing the steps rather than the object router. Referring now to FIG. 22A, in step 920, the object router sends the data to the receiving client.

Next, in step 922, when the receiving client receives the data, in step 924, the OM on the receiving client sends a packet to the object router instructing the object router to send the latest in step 924. If there is more data to send, which is determined in step 926, the process loops to step 920 and the object router then sends the next amount of data. This process eliminates bottlenecks created by a build up of out dated data packets that would otherwise be buffered throughout the network including OS buffers and Internet buffers. It continues until all of the data has been sent to the receiving client, as determined in step 926.

Another embodiment of the flow control module includes the ability of the OM client or object router to simulate a multi-channel flow of information within a single data flow. In this way, OM is able to react to changing networking demands by inserting additional information within the current data flow of an OM Packet. This form of flow control is critical when data intensive AP-Objects, such as graphics objects, create a bottleneck that prevents the immediate networking of system critical messages or less data intensive AP-Objects, such as text objects, or any other objects that the application programmer desires to have networking priority.

Although the flow control module is described herein with reference to data flows between a client and the object router, the process is applicable to data flows between the object router and any number of clients. The process is as follows. OM will setup a temporary client "Out" buffer to buffer the data for the new OM Packet. In one embodiment, using the pointer method, OM will first copy a pointer (hereinafter referred to as "insert pointer") in the beginning of the temporary buffer and then any number of OM Packets followed by an end insert pointer. While the ongoing OM Packet is in the process of being sent from the client to the object router, OM will, when instructed by the APFM, halt the transmission of the outgoing OM Packet and immediately switch over to transmission of the temporary "Out" buffer. After the temporary "Out" buffer (with the prioritized OM Packets) is sent, OM will switch back to transmission of the regular "Out" buffer and resume with sending the remaining portion of the ongoing OM Packet.

The object router, in the course of receiving the first OM Packet from the client, will continue its receiving cycle to determine if the entire OM Packet is received based on the OM Packet size specification as described above. When the object router proceeds with the size check of the data in the client's "In" buffer, it will proceed to scan the buffer data contents to determine if there is an insert pointer. If an insert pointer is detected, the object router will continue scanning in cycles until the second insert pointer is detected. Once the ending insert pointer is detected, object router will determine the size of the prioritized OM Packet and add this specification incrementally to the size specification of the ongoing OM Packet and will continue monitoring the "In" buffer until the entire packet is received.

Object router will then proceed to process the prioritized OM Packet as a new OM Packet, thus circumventing the bottleneck condition created by the ongoing OM Packet. Object router will then proceed to process the ongoing OM Packet. When it has received the entire OM Packet data, it will proceed to copy the packet into the respective "Out" buffers to the other client(s) with the exception of the prioritized OM Packet data as defined by the beginning and ending insert pointers.

The process is applied to data flows that the object router is sending to the client. Upon receipt of a prioritized OM Packet, the client will incrementally increase the OM Packet size specification of the ongoing OM Packet. Before or after the size specification is adjusted, the client will immediately process the prioritized OM Packet as defined by the insert pointers. Once this process is complete, the client will continue receiving the ongoing OM Packet in accordance with the new OM Packet size specification. Accordingly, the application programmer can determine a prioritization schedule of message types and the respective OM Packet types at either the OM network level and the AFPM client level. For example, if the object router is required to send a system message to a client, and at the same time, the client is receiving a graphics object, the OM network may prioritize OM Packets to be inserted into existing data flows in accordance with any number of prioritization schedules. One type of embodiment is to prioritize OM Packets based on either the size specification, message type, shared object type, client, chronological order of the OM Packet, or any combination of prioritization schemes.

Another type of embodiment is to prioritize based on a categorical percentage allocation. For example, system message types can be given 50% priority, text object types can be given 40% priority and graphics object types can be given 10% priority. Following this prioritization schedule, when the OM network has no other OM Packets to send, it will allocate 100% of the outgoing data flow to graphics objects. Other embodiments can rely on any other specification (in addition to percentage) to determine allocation specification.

Another embodiment of the flow control module is the ability of the object router or client to route several different types of data within a single OM Packet, thus simulating a multi-channel flow of information. In this embodiment, the OM Packet protocol is utilized to create complex OM Packets. The application programmer can set a "high volume" threshold to start the process of complex OM Packet routing, or can simply establish a fixed process of complex OM Packets regardless of networking conditions. In either case, this embodiment of the flow control utilizes a message type and / or a shared object type to indicate that the OM Packet contains complex information. The flow control module packs this complex information separately in the single OM Packet structure by setting an index pointer in the Packet that separates the different types of data. When the receiving client or the object router receives the complex OM Packet, it will proceed to process the OM Packet in accordance with the sectional divisions created by the index pointers. Each section of the complex OM Packet will then be processed separately in accordance with the predetermined OM Packet protocol for complex messages or shared objects. In other embodiments for all of the flow control methods described, the pointer method is not used, and the data is written to RAM or secondary storage.

Yet another embodiment of the flow control occurs at the APFM, which can utilize OM to route several different types of AP-Objects within a single OM Packet, thus simulating a multi-channel flow of information. The application programmer can set the prioritization of the routing of AP-Objects, as determined by a prioritization schedule of AP-Objects using any prioritization scheme that the application programmer desires to fulfill the networking functionality. The application programmer can set a "high volume" threshold to start the process of complex AP-Object routing, or can simply establish a fixed process of complex AP-Objects regardless of networking conditions. The process begins with an index pointer that the APFM on the sending digital device sets at the beginning of the AP-Object portion of the OM buffer (that OM will stuff into the OM Packet). It proceeds to copy the first AP-Object into the OM buffer. It then sets a second insert pointer and continues this process until all AP-Objects are buffered in the "Out" buffer to be sent in the single OM Packet. When the APFM on the receiving digital device receives the complex AP-Object, it will detect the index pointer and will proceed to process the OM Packet in accordance with the sectional division created by the index pointers. Each section of the complex AP-Object will then be processed separately, and thus instantiated separately, in accordance with the application programmers predetermined prioritization schedule with various embodiments as described above. Although this embodiment is described with respect to a pointer system, this flow control module, in other embodiments, does not utilize a pointer system, but rather writes the data to another memory resource, i.e. RAM or secondary storage.

Another embodiment of a prioritization flow control module is shown in FIG. 23A. This flow control module can be implemented either by the client or the object router. The prioritization schedule is set by the application programmer, and therefore, part of the APFM. This flow control module works with a priority buffer to override other flow control modules to make certain specific message types are sent before any other message type. The process starts in step 930, where the system message type ID on the OM Packet is compared to the prioritization schedule. This is done using the linklist function. If the system message type ID is on the prioritization schedule, and therefore is a priority message step 932, the system overrides all other flow control modules in step 934, and, in step 936, the OM Packet is copied into the priority buffer. The OM Packet is then sent to digital device 2 in step 938. However, if, in step 932, it is determined that the message type ID is not a priority message, then the regular system flow control modules are implemented for sending the packet, step 940.

The process described above for FIG. 23A is the same as for FIG. 23B, except the client replaces the object router.

The networking session ends when the object router determines that all clients that were included in the networking session have ceased to maintain a data linkage, and the object router closes the networking session.

Alternatively, the session can end when the object router receives a system message from a client, identified as a session administrator, instructing the object router digital device to close the networking session.

The object router has two functions: message processing, and client/user management. There are many operations involved in client management, and these will be discussed in detail below. The object router notifies clients when a user is connecting or disconnecting. Throughout the networking session the object router will check all current client names, and compare these to the current list of client IDs. If a new client subscribers, the object router determines if the client name is currently in use. If not, the object router allows the new client name. The object router will then notify the current networking clients of the new client, and add the new client name to the list of clients. If the client name requested is already in use, the object router will send the client name back to the client.

Once the new client is on the list, the client name is associated with a client ID, and added to the client ID list. The client ID can be associated with certain shared objects. This allows the object router to notify the appropriate clients when a new message arrives of a certain shared object.

During the networking session, when a new-shared object is created, the shared object is placed in the shared object list on the object router. When a new-shared object ID of this shared object is read by the object router, the object router reads through the list of clients that are associated with this specific object shared object, and then notifies all of the appropriate clients of the new-shared object ID. This notification function is the method by which the object router determines to which clients to route each new data packet.

The object router creates historical session data for each shared object using the following process. When a new message OM Packet ID is sent, the object router calls all the function pointers stored with this shared object. This data is then stored away for this shared object to update clients at a later time. Each new message

(each OM Packet ID) will also have the client ID for purposes of following the history of the networking session with respect to this shared object. When the next message for this shared object is sent, a new pointer will be called to the old messages. When a new shared object is being shared out, the object router checks the list of shared objects, and if the object router finds a shared object of that type, a new pointer is called, and the client is notified. This loop continues through all of the shared objects, and a notification is sent each time the object router finds another shared object of that type that exists.

When a shared object ID is deleted, the shared object data, including all OM Packets sent through the shared object data flow is removed from the list, and the pointer is deleted. The shared object ID is removed from the object router. Next, the object router loops through the information of each client and sends a command to every client related to the shared object to delete this shared object ID.

Once the object router discovers a client has been disconnected from the networking session, the endpoint is disconnected. The object router deletes the client from the client list, and the notify function for that client is removed. The data buffer for that client is deleted, and all unsent OM Packets for the deleted client are deleted. The object router then checks for the clients that are still connected to the network against the client list.

Additionally, the client ID coding in the OM Packet also provides a built-in security feature. The packets crossing the network are no longer anonymous. If necessary, the digital device source of any OM Packet can be identified. The OM modules are platform specific; therefore, when the packet arrives onto the client digital device, the client digital device will automatically receive the information in a form in which the OS can read.

Referring back to the AP-Object ID, as discussed above, OM creates its own object structure at the digital device level. Because of this feature, the OM network can take any section of data in a digital device's RAM, and convert that data to an object. The digital device in which the data originated assigns an AP-Object ID based on a predetermined object list established by the application programmer. This same AP-Object ID list is also set up on the other digital devices connected to the network. OM determines from the AP-Object ID list how the OS should interpret and instantiate the data in a particular shared object.

The object router provides simultaneous cross-flow of data between multiple clients. This data flow technique greatly increases the throughput, resulting in nearly real-time networking performance with data originating from networking nodes. While the object router is transferring data, the object router is not involved in sorting or processing the data transferred by the packet. Thus, the object router is simply sending data to the correct locations in real-time. This arrangement allows for the OM to operate at optimum speed, simulating realtime performance.

The present invention additionally includes a module by which at least two digital devices, a host digital device and a receiving digital device, can share at least one object via a direct streaming method. This method allows the object and the states of the object to be streamed to the devices, in real-time, without the object router processing layer. A stream is a byte stream. An object termed "self -describing" means it includes enough data in itself that, when shared, can be instantiated on any digital device using information included in the self-describing object. The information indicating the object class, recognizable by the DS, is included in the self -describing object.

This module of the OM, referred to as the direct streaming module (DS), connects digital devices that are running the DS to a network layer that communicates object-level data between multiple digital devices regardless of the operating system and application compatibility of the digital devices. The host digital device can create virtual networking sessions with another digital device (receiving digital device) on the network. Each digital device can accept objects that are developed to take data from buffers running on one digital device and package the data as an object and provide the instructions, using an object type code on how another digital device in the networking system can instantiate the object, interpret, or otherwise manipulate the data. The connection or link between the digital devices can be any type of connection or link, including, but not limited to, an Internet connection, a satellite communications link, or an Ethernet connection, or any other connection or link known in the art to connect or link two digital devices. The DS allows for direct and digital streaming of objects between two digital devices. In its preferred embodiment, DS is written using C++ computer language and is compiled on any OS platform with a respective

C++ compiler program. In other embodiments, DS can be compiled and made to run on different platforms using any other computer language that is capable of supporting its functionality and is compiled to run on any respective platform. To utilize the DS as a networking layer, the application programmer first begins by identifying a particular functionality that is to be networked between one or more digital devices. The application programmer then identifies this functionality in terms of data sets (at the data level) and classes of objects (at the object level), if any, which constitute the particular functionality. Once determined, the application programmer proceeds to develop an Application Programmer Functionality Module (hereinafter APFM) that is compiled to run on the OS of a first digital device with a corresponding APFM that is compiled to run on the OS of a second digital device. It is critical to note that the AP-Object is a particular instantiated object that the application programmer wishes to instantiate on another digital device. From the perspective of the DS network, DS in itself has no regard for the data content of the AP-Object. Due to its cross platform networking functionality, the DS system does not process the AP-Object data content. Rather, DS considers the networking of AP-Objects as "streaming/ shared objects," which are also referred to as "streaming objects" or simply as "streams". The "streaming/ shared objects" can be further defined as "categorical data flow structures". Throughout the descriptions contained herein, "streaming/ shared objects" are referred to as an "AP-Object" from the perspective of the DS application programmer. Correspondingly, from the perspective of the DS network, which deals with AP-Objects generically, they are herein referred to as "streaming/ shared objects". Accordingly, the two designations are essentially two aspects of the same entity.

The application programmer develops the APFM to run on a digital device by identifying the APFM with its own object code. The object code consists of a code representation of each object class (hereinafter AP-Object ID). This code representation can be any type of data including integers, characters or strings. The application programmer utilizes DS's Application Programming Interface (API) as an instruction to insert the DS function calls within the APFM. The DS function calls, in effect, instruct the OS to take any type of data from any digital device, and, using the function calls for taking data, which are specific for each OS, each application, or both, either creates pointers that instruct the OS to replicate the raw data into DS buffers in RAM, or, in other embodiments, instead of pointers, writes the data into the RAM or secondary storage.

DS operates using its own function calls. The DS uses a utility program (in the preferred embodiment, the utility used is the conversion utility, as described above) to package the AP-Object ID (to determine the object level) and the raw underlying data (to fulfill the data level) of the instantiated object taken from a first digital device. In this manner, DS has the capability of capturing the raw data on a first digital device, and abstracting the data with an object code, and ultimately prepares the data for routing to any number of second digital devices.

To fulfill the desired networking functionality, the APFM initiates the object class and the RAM (or other secondary storage) buffer required for instantiation of the object on a second digital device. Once transmitted with the necessary data conversions the DS running on a second digital device receives and extracts the networked data and corresponding AP-Object ID. Under the direction of DS function calls (embedded in the APFM running on the second digital device), DS provides the networked data in the specified buffer in accordance with the AP- Object ID.

Once the data is placed in the specified buffer, the object, which originated on a first digital device, can be re-instantiated on a second digital device in accordance with the corresponding object class. Essentially, each AP-Object that is captured, abstracted, and networked by the DS system becomes a streaming/ shared object that is instantiated in accordance with the corresponding object classes of the OS, or application, running on each digital device.

Accordingly, DS has the power of overcoming OS or application compatibility barriers created by networking at strictly the data level as opposed to the object level. To overcome object class incompatibility between different OS platforms or applications, the application programmer may include compatibility modules. These compatibility modules equate the object class of the first digital device with that of the second digital device. Thus, the objects instantiated on the first digital device are replicated on another or any number of second digital devices that are running the same or any number of different OS platforms in which DS and the AFPM are compiled to run. For instance, one embodiment of the APFM is to harness the DS to convert file formats or other directory structures, so that they can be interpreted by applications running on otherwise incompatible platforms (referred to as the conversion utility). This file conversion APFM would convert data in real time while it is being networked between the first digital device and the second digital device with the conversion occurring on either device without a separate conversion process occurring on a separate conversion application or intervening digital device, although this, by no means, is the only APFM application, but it is of significant value. Therefore, APFM is, in this instance, used for file transfer, but the actual utility of the APFM is much broader and distinct in terms of networking live memory.

By continually networking the underlying data of each object, changes in the internal state and respective outside characteristics of the original object can be continually reflected in the instantiation of the objects on the other digital device(s). In this manner, DS can accommodate the networking of highly dynamic objects that undergo a continual state change in addition to static objects that have a fixed state or undergo only periodic state changes. Also, the object classes that are used to instantiate the object on the first digital device can be manipulated to produce different states or characteristics for objects instantiated on the second digital device. For instance, an object class can be simplified to optimize network performance with a digital device with limited resources (i.e. networking, memory, processor and other operational resources). These changes may produce or enhance the desired networking functionality.

Referring now to FIG. 24A, the preferred embodiment of the beginning of the DS process is shown. The DS process begins with step 1000, when a digital device is established as the host digital device. One digital device is designated as the host digital device, and the host digital device is responsible for coordinating direct streaming data with the client digital devices connected to the streaming object network session. The network can be either an Internet, or Ethernet network, or any other network known in the art. Next, in step 1010, a connection is established with the receiving digital devices by binding the receiving digital devices' TCP port. In step 1012, the TCP address is then associated with the receiving digital device's endpoint designation or data link designation. In the preferred embodiment of the present invention, the endpoint designation is an IP address. However, in other embodiments, the endpoint designation can be any endpoint designation known in the art. Next, in step 1016, the DS host digital device establishes each receiving digital device's client ID with the linklist function. The linklist function is described in more detail below. In step 1018, the host digital device opens the TCP/IP sockets for each receiving digital device connected to the network. Next, in step 1020, if a digital device wishes to begin a streaming object session, then, in step 1022, the host digital device starts the stream with the receiving digital device, and in step 1024, objects in the preferred embodiment, are created for keystrokes, mouse and displays. In alternate embodiments, the object can be any digital object known in the art.

Next, in step 1026, the receiving digital device utilizes the streaming object to re-instantiate the host's screen (or keystrokes or mouse movements or any other respective object in alternative embodiments) on the receiving digital device. As shown in step 1028, the stream continues until the stream is disconnected, via a network disconnection.

The host digital device, established in step 1000 above, is further described here. A direct stream object router (DSOR) is set up on the host digital device. The DS then establishes a DSOR for every streaming object that is established. The DS can establish multiple DSORs on one host digital device, and may also establish DSORs on multiple digital devices that are hosting streaming objects on the network. Each DSOR creates a single independent "out" buffer on the host digital device. The DSOR then initiates the direct streaming session by setting up three structures on each receiving digital device participating in the networking session. First, a client ID structure identifies the host digital device. Second, an object ID that identifies the streaming objects. The first and second structures can be any representation in data including integers, characters or strings. Third, an "in" buffer structure is established. Once the DSOR network layer is negotiated, the DSOR on the host digital device instantiates the streaming object. The DSOR continuously registers the instantiated data in its "out" buffer. The streaming object is then routed directly to the "in" buffer of each of the receiving digital devices. As the data is continuously transmitted, in some embodiments, it is routed through a conversion layer (i.e. conversion utility), compression layer or an encryption layer on the sending digital device and the respective layer on the receiving device. In alternate embodiments, an authentication layer may be implemented. The DS running on each of the receiving digital devices then continuously instantiates the streaming object. The result is a continual re- instantiation of AP-Objects on the receiving digital device through transmission of streaming objects.

Once the networking session has been initialized, each receiving digital device then receives the IP address of the host digital device. After the IP address is acquired and the data linkages are made, each receiving digital device is then involved in the processing of the information sent over the network. The list of streaming object IDs is also present on the receiving digital devices.

Once a new receiving digital device is set-up on the DS system, the new receiving digital device's client ID is linked to specific streaming object IDs. The DS stores the function pointer on this streaming object, and then adds the new receiving digital device to the streaming object ID list. Next, the DSOR is told to subscribe the new receiving digital device to the DSOR, and then the DSOR will now send all streaming objects regarding this streaming object ID to this new receiving digital device.

The direct streaming method incorporates the cross platform functionality and method of the OM, but does not include an OM object router. Therefore, the direct streaming method allows direct networking of streaming objects between at least two digital devices regardless of the fact that they are running two different OS. The direct streaming method uses the conversion utility described above to bring cross platform functionality to the direct streaming method. The direct streaming programming instructions are compiled separately for each platform, using a C compiler, which is designed to compile for that platform. Once executed on each platform, the direct streaming method becomes platform specific to that digital device. The direct streaming method is not limited to any particular OS, rather any OS known in the art can be networked with any other OS known in the art using the direct streaming method. These OS include APPLE®, WINDOWS®, LINUX®, UNIX®, SOLARIS® and

PALM OS® and any other operating system known in the art.

Referring now to FIG. 24B, the preferred embodiments of the method of direct streaming of an object between at least two digital devices is shown. The method of DS shown in FIG. 24B can be applied to the at least two digital devices, here a first digital device, and a second digital device, which are directly connected. The first digital device and the second digital device each have an "in" buffer for the object and all subsequent states of the object. In practice, any number of objects can be shared between the digital devices. The first digital device, when beginning the stream, is the host digital device. However, as the object is streamed between the digital devices, in FIG. 24B, the first digital device designation refers to the digital device that is sending the object.

Whether the first digital device has received the object from another digital device, or else the first digital device retrieves the object from RAM or secondary storage, the following process shown in FIG. 24B applies. The method starts in step 1030, where the object to become a streaming object, is instantiated on a first digital device within a first application framework. In step 1032, a first object class is initiated on the first digital device. The object class is either a generic object class from the application functionality module or else it is a generic object class from the OS of the first digital device. Next, in step 1034, the first digital device instantiates a code representation of the object and the object class. Once the object is instantiated the APFM can instruct DS, in accordance with the DS API, to capture a representation of the underlying memory data of that object and the object class in step 1036. DS either relies on pointers given by the APFM, to identify where the data is buffered in either RAM or secondary storage of the first digital device, or, uses an assigned memory resource by the processor or the APFM. Thus, the present invention can accomplish the same function by writing the data to the memory resources, either RAM or secondary storage, to achieve the same function of the pointer system. By writing the data to RAM or secondary storage, the present invention uses a function call in the OS that tells the processor to store the data in memory. In either the pointer or other memory resource method, the instantiation process of the present invention addresses the memory from its written and stored state.

Next, in step 1038 the underlying data of the object is taken and its fundamental binary constructs are determined. In step 1040, an object ID is attached to the representation/ binary construct. The binary construct is referred to either as a binary construct or the representation. The object ID indicates to the API the type of data represented by the binary construct. The object ID is a serialized ID that is recognized by the DS API as the object class type. Therefore, the object ID is used to create object classes. The object ID and the AP-Object ID are different names for the same information, only the AP-Object ID refers specifically to the DS API object ID, In step 1042 a streaming object ID is attached to the object ID and the representation. The streaming object ID is a serialized ID used by the DS linklist function to index the streaming object. As described above, the host digital device sets up a linklist function (similar to the linklist functions described with respect to the OM object router) and indexes the steaming objects with the client IDs of the digital devices participating in the streaming networking session. Next, in step 1044, the object ID and the representation/ binary construct are sent to at least one second digital device. The DS copies the representation into a DS "out" buffer, and the representation is sent over a link to at least one second digital device. The second digital device(s) are either running the first application framework, not running any application framework, or else are running a completely disparate application framework (second application framework). Additionally, the second digital device(s) can be running disparate applications one to another as well as to the first digital device (see FIG. IF). In the preferred embodiment, in step 1045, a conversion utility is performed on the object ID and binary construct. The preferred embodiment of the conversion utility is described above. In alternate embodiments, the conversion utility is not performed. Next, in step 1046, the second digital device receives the object ID and the binary construct, and copies this into the DS

"in" buffer on the second digital device, and in step 1048, the second digital device reconstructs the binary construct to represent the original underlying memory from the first digital device. In step 1050, the second digital device initiates a second object class, which is respective to the second digital device and corresponds to the first object class. Because the object class from the first digital device is either the generic OS class or the generic application functionality module class, the second digital device can understand the object class and the object class can be used to instantiate the object in the second digital device's application framework (or, if the second digital device does not have a framework). In step 1052, the object is instantiated by the second digital device.

At a predetermined interval, determined by the application programmer, the latest state of the object is sent to the host digital device for the streaming object networking session. This function is accomplished, in the preferred embodiment, using a hardware interrupt. The application programmer sets this up as a task, with a timer. However, in other embodiments, any interval and any technique known and used in the art can be used to send the latest state of the object. The latest state of the object on the host digital device is not sent to the host digital device.

Therefore, in step 1054 the latest state of the streaming object is sent to the host digital device. For each digital device participating in a streaming networking session with respect to a particular streaming object ID, the latest object state will be sent to the host digital device. The host digital device will receive the latest object state, and, using the linklist function, will send the latest object state to each digital device whose client ID is linked to the streaming object ID. After the initiation of the streaming object, the same process shown in step 1032 through step 1054 is followed for each sharing of the streaming object between digital devices, where the first digital device is the digital device where the object or latest state of the object originates, and the second digital device is the host digital device. The host digital device will send the latest streaming object state to the remainder of the digital devices participating in the streaming object networking session (variation on step 1044 and step 1045), and the remainder of the digital devices participating in the streaming object networking session will instantiate the streaming object by following steps 1046-1052. The streaming object networking session will continue until the stream or the, connection between all of the digital devices participating in the streaming object networking session and the host digital device is broken. The direct streaming software is running on all digital devices involved in the direct streaming networking session. To start a networking session, the direct streaming programming instructions must be executed by first linking with other direct streaming subroutines. Next, the identity of the global variables and functions are given. The direct streaming method is then initiated.

The receiving digital devices DS module functions as follows. To establish a DS networking session, a connection must first be established between the DS running on the receiving digital device and the DSOR that is running on one other digital device (host digital device). The DSOR uses a function to establish the connection between the receiving digital devices and the DSOR. This function binds the TCP of the DSOR to the current IP address and port of the receiving digital device, establishing a data linkage between the DSOR and the receiving digital devices. This function of the DSOR opens sockets and sets the client ID for the connected receiving digital devices. Referring now to FIG. 25, to connect a new receiving digital device or host digital device to the network, the following process is used. Starting with step 1058, the following input parameters are determined: stream name (referred to as streaming object ID), which is the name of the stream in which the digital device is associated with; serverlPName, which is the IP address of the other digital device, but in other embodiments, any endpoint or data link can be used; portNumber, which is the port of the digital device that will be receiving the stream; size, which is the maximum data size that can be sent; theCallBack, which is the call back function that the receiving digital device will use to process this stream; and maxOut, which is the amount of data in the current stream. Next, in step 1060, the DS initiates various structures needed for TCP/IP transmission of data on each respective platform that DS is complied to run on (collectively referred to herein as "OT"). Specifically, "Berkley Software Distribution" (BSD) governs UNIX® platforms, "Open Transport" governs Apple® platforms, and "Windows Sockets" govern Microsoft® platforms.

Next, in step 1062, another DS function sets a specified size and location of memory to a specified value. In step 1064, the DS establishes an OT endpoint, which is the connection between the application and the OT interface. In step 1066, the OT endpoint is configured, and in step 1068, an attempt to bind the endpoint to the new digital device is made. In step 1070, the new digital device IP address and port number is converted into an OT specific address format. Next, in step 1072, the connection to the new receiving digital device is made; otherwise, the process then continues to step 1074 if the connection fails, and a delay is created to wait for the connection to be made. Once the connection is made, in step 1076, the new stream is added to the linklist of active streams (the streaming object ID is added to the list of active streams). In step 1078, the DSOR sends out the name of the stream to the new receiving digital device (the streaming object ID is added to the receiving digital devices list of streaming object IDs). Finally, in step 1080, the completed streamlnfo structure is returned to the function that requested a new stream.

Messages are handled as situations using a switch statement, which is a multi-way decision test known in the art. It is not a variable, but rather tests a value against many options. Each option is referred to in the art as a "case" or "case statement". The DS function uses several types of case statements. The application programmer adds specific case statements depending on what the application needs to achieve. There is a case statement specific for each DS system function. The names of the case statements can vary, depending on the application programmer.

The case statements serve as the instructions for handling objects that are being dealt with at a low level or a high level, depending on which networking functionality is desired by the application programmer. The application programmer creates a message type for every streaming object that is sent over the object router.

These message types tell the DSOR to list, create and delete steaming objects, and as such, this is at the center of the DS functionality. A reference integer is assigned to each case statement, and everything a client sends to the DSOR has a message type assigned. The message type correlates to a case statement and is "switched" accordingly. Programmers can add their own message types beyond anything that is already present on the DS.

Accordingly, the DS is a type of program for any sharing application, and for every new application, the programmer must add additional message types to the DS.

Once the networking session is negotiated, the DSOR begins the linklist subroutine. The linklist subroutine represents how the DS organizes the streaming objects, and manages the streaming objects to the digital devices participating in the streaming object networking session. One list includes all receiving digital devices connected to, and participating in, the networking session. The DSOR continuously updates this list. The client ID list is connected to the receiving digital device list. For each receiving digital device connected, the

DSOR maintains a list of the respective client IDs. Additionally, the DSOR maintains a streaming object ID list. This includes a list of the entire streaming object IDs that DS sets up for each AP-Object data flow. Finally, the DSOR maintains a notification list. This list tells the DSOR which connected receiving digital devices are sharing each streaming object in the streaming object ID list. All of these lists are linked together, by the linklist subroutine.

Referring now to FIG. 26, the preferred embodiment of the DS process of accepting a connection request is shown. In step 1090, a digital device sends a connection request. Next, in step 1092, the address of the client / digital device sending the request is associated with the request. In step 1094, if an error is detected, either because the attempt to connect failed, the client has already been added to the list, or other error types, the process ends. However, if there is no error found in step 1094, the process continues to step 1096, where the new stream is added to the linklist function streamList. In step 1098, a delete request is sent to delete the request from the list of requests. Next, in step 1100, the stream is configured, and in step 1102, the socket is opened to receive the new stream.

Anytime a streaming object is instantiated, a constructor is called by the DS running on the DSOR. The constructor "builds" the object and initializes certain variables associated with the object. The OT is initialized and the special tasks that the OT will perform at certain times are created. These tasks include system tasks, deferred tasks, and hardware interrupts. Anytime a streaming object is created, a destructor is called to destroy the object when it is not longer needed. This function performs "housekeeping". The call to function shutDown closes all network sockets that are open and properly shuts down the OT.

In the preferred embodiment, DS utilizes a callback function to process each active stream. The callback function is implemented when DS traverses the streamList (described below in more detail), which is a list of all the streams known to the program, and detects an active stream that requires processing. Once detected, the callback function determines how the data flow of each stream is to be processed into a streaming object. Specifically, the callback function applies the correct implementation of AP-Object utilities and other processes that are necessary to re-instantiate the streaming object into an instantiated AP-Object on the receiving computer. A port is a logical point that the hardware (ethernet card) and the software (DS) combine to receive data that is sent to it. A socket is created on the digital devices participating in the DS networking session for receiving incoming streams. A socket is a piece of software that acts as an addressable entity. A socket is where all incoming streams will be directed. Various data structures are created, the DS reserves memory for the data structures, and the DS clears out any "junk" that was left over within the reserved memory space. Required data is inserted into the listenReq data structure, and an endpoint is opened for the digital device. An endpoint is the communications path between the DS and the OT. The DS has a built in function to determine whether or not a given OT function was successfully completed. A pause and wait function in the DS allows the OT to finish performing its tasks before a new function begins. A function also sets a blocking parameter for the new endpoint. The blocking parameter is used to allow the endpoint to finish its tasks. All processing on the digital device is halted until the endpoint has completed all of its tasks. The endpoint is bound to an address. Binding an endpoint to an address associates the endpoint with a logical address.

There are many functions that allow for the functionality of the DS networking session. After the digital device joins the networking session, a function is used to open the digital device's socket to receive incoming streams. A nonrelocatable block of memory of a specified size is allocated for this socket. Another structure is then set up that holds all of the data associated with the connection, and various data is additionally set up in the structure.

When an endpoint is no longer needed, a function closes the endpoint, and the memory associated with the endpoint is returned. The disconnect function disconnects the digital device from the networking session. A disconnect request can be made by another system in the DS session. The disconnect request is also used to reject incoming connection requests or to tear down a connection. A listening endpoint can also be disconnected from a DS networking session. When a stream is requested to be shut down, a function is used to close the outgoing connection.

The DS maintain function is the logical process that maintains each active stream. Referring now to FIG. 28, the preferred embodiment of the maintain function of the present invention is shown. The maintain function is utilized to maintain the flow of data in each active stream. It begins in step 1120 when the traverseList function traverses through the list of active streams and passes a pointer from the stream to the function processListens. This function checks the listening endpoint to see if there are any new connection requests from remote clients. If a new stream connection request is detected in step 1122, then, in step 1124, it is added as a new stream to the streamList. If it is found that a stream has been previously marked for deletion by a different function in step 1126, then, in step 1128, the stream is deleted from the streamList. The traverseList function continues with step 1130, where if it is found that there is data waiting to be sent for any available stream, then, in step 1132, the data is sent from each respective stream. In alternate embodiments, step 1132 can be implemented in accordance with a prioritization schedule of streaming object types. Accordingly, DS will traverse the streamList to detect data to be sent in a predetermined order, thus giving certain streams priority in data flow over other streams. Next, the traverseList function continues to step 1134, where, if it is found that there is any data waiting to be processed in any available stream, then in step 1136, the data is read. In alternate embodiments, step 1136 can be implemented in accordance with a prioritization schedule of streaming object types. Accordingly, DS will traverse the streamList to detect data to be read in a predetermined order, thus giving certain streams priority in data processing over other streams. If the maintain function is continued, as determined by a different function in step 1138, then it loops to step 1140 where a timer interval is set by the Application programmer. This time interval imposes a cyclic time delay to allow connections to be requested for new streams, streams to be marked for deletion and data to be sent or processed to accumulate in the available streams. Following the timer interval, the maintain function continues to step 1120 and begins again.

Referring next to FIG. 30, the preferred embodiment of the process of sending out data for any stream is shown. This function is called by a previously defined function and the process starts in step 1160 where it checks to see if data is currently being sent (if flowControl). This is used because the timer function will cause this function to be called several times per second. If the function is not in flow control, step 1162, the function will attempt to send the data in step 1164. The variable bytes is used to monitor how many bytes of the data has been sent, step 1166. The OT function OTsnd transmits the data and returns the size of the data sent and sets the variable bytes equal to the value, step 1168. The outcome of this operation can be one of four cases. The first case is shown in step 1170, where, if it is determined that the number of bytes sent equals the number of bytes to send, then all data has been sent out and therefore the process exits. The second case is shown in step 1172 where the OT function returns a flow error code. This indicates that data could not be sent and the process exits. If a flow error code is not returned in step 1172, then the process continues to the third case, shown in step 1174, where it is determined whether the number of bytes is less than the number of bytes to send. If the number of bytes is less, then the process continues to step 1176 where the DS recalculates the number of remaining bytes to be sent and then exits. These bytes are sent the next time the function is called by DS maintain function described above. If none of the previous cases are found, then the fourth case is determined by default as shown in step 1178, where it is determined that the number of bytes to be sent is less than zero. This signals to the DS that there is a system error and the DS does not attempt to send the data. In alternate embodiments, DS returns a system error message to the APFM or other appropriate module on the sending digital device as shown in step 1180.

Referring next to FIG. 31, the preferred embodiment of the function for receiving data from a stream is shown. This function begins when the OT function OTRcv gets data sent through the stream in step 1190. Next, in step 1192, the function sets the variable theResult to the size of the data. The function then checks for OT specific messages in step 1194. The read function is then initiated in step 1196. The read function is used to read all data associated with a stream. The read function then reads the first 4 bytes of the message in step 1198.

These 4 bytes in the preferred embodiment can be any other data size in alternate embodiments providing that it contains a representation of the size of the entire message. This size is necessary so that DS knows how much data to process. The read function next reads the entire message in step 1200. If it is determined in step 1202 that the entire message has not been read, than the read function loops back to step 1200. This will continue until the entire message is read. Next, in step 1204, if it is determined that there is a callback function associated with the message, the callback will be performed in step 1206.

Referring now to FIG. 32 the preferred embodiment of the read AllData function is shown. The purpose of this function is to determine which stream the incoming data is associated with. The function starts at step 1220 where the function uses a utility program (in many embodiments it is the conversion utility described above) to extract a short integer from the data. This integer is a message code that instructs the DS on how to manipulate the data. The function then uses a utility program to extract a string from the data as shown in step 1222, which is the stream name (streaming object ID). Next, in step 1224, the stream name (streaming object ID) is then compared to the linklist streamList, which is a list of all the available streams. If, in step 1226, it is determined that a match is found, the function then attaches all of the stream's attributes to the new data in step 1228. If, however, in step 1226, a match is not found, the process proceeds to step 1230, where it is determined if the stream has disconnected. If the stream has disconnected, then the function exits.

During the networking session, a function is performed periodically which determines whether any streams currently listed on the stream linklist streamList has disconnected. If it is found that a stream has disconnected, then the stream is removed from the streamList, and the endpoint is closed. When a new stream is created, the new stream is registered with the DS. The parameters passed into the function are as follows: name, which is the stream name or streaming object ID; size, which is the maximum size for the stream's data; theCallBack, which is the function to be performed every time an instance of this stream is received; establishBack, which is another callback function that is only used during the first instance of the stream; and maxOut, which is the size of the data currently associated with the new stream. The stream definition is then added to the linklist of streams, streamList. Referring next to FIG. 33, the preferred embodiment of the function used to determine whether a new message has been sent is shown. If, in step 1250 it is determined there is a message already in the queue waiting to be sent, then the function returns a zero in step 1252. This indicates that no new messages can be sent at this time. Next, in step 1254, the function checks if the desired stream is valid. If the desired stream is not valid, then, in step 1256, an error message is returned. If in step 1254 the desired stream is determined to be valid, the process proceeds to step 1258, where the function checks if there is a valid network connection. If there is a valid network connection, then the message is sent to the appropriate digital device in step 1260. If there is no valid connection, the message is saved in step 1262 until a valid connection is achieved.

Referring next to FIG. 34, the preferred embodiment of the function that sends messages out is shown. The input parameters to the function are as follows: stream data, which is the size of ptr; ptr, which is a buffer that contains the message type; and, the stream name. The process starts at step 1280 where the function tests to see if the stream is still connected. If the stream is no longer connected, then in step 1282 the message is not sent. This signals the DS that there is a system error and the DS does not attempt to send the message data. In some embodiments, DS returns a system error code to the APFM or other appropriate module on the sending digital device as shown in step 1284. The message is either deleted or, in alternate embodiments, a new connection request to initiated to facilitate transmission of the message. If the stream is still connected, then in step 1286 the function tests to see if there are any outstanding messages to be sent. If there are outstanding messages to be sent then the process goes to step 1288 where the message is passed to function sendDataOutStream to be transmitted, and the function is exited. If there was no old messages waiting to be sent as determined by step 1286, then the size of the message is stuffed in step 1290, and the message type and stream name is copied in step 1292. Next, in step 1294, the byteToSend variable is adjusted to reflect the size of the message. The function then, resets the buffer index to zero in step 1296. Next, in step 1298, the function increments the outsandingMessages variable. The message is then sent to the function sendDataOutStream to be transmitted in step 1300.

A function to decrement the outstandingMessages counter of a particular stream is then implemented (not shown). This is how DS knows if it still has a previous message to send before allowing a new message to be queued.

Storage devices suitable for tangibly embodying computer program instructions include all forms of nonvolatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially designed ASICs (application-specific integrated circuits).

Other embodiments are within the scope of the following claims. For example, depending on the nature of the work items involved, the computer station may be a terminal instead of a personal computer.

The technique (i.e., the methods described above) may be implemented in hardware or software, or a combination of both. Preferably, the technique is implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. Program code is applied to data entered using the input device to perform the method described above and to generate output information. The output information is applied to one or more output devices.

Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.

Each such computer program is preferably stored on a storage medium or device (e.g., ROM or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.

One skilled in the art of computer science will easily be able to combine the software created as described with appropriate general purpose or special purpose computer hardware to create a computer system embodying the invention. Although the present invention has been described with reference to certain preferred embodiments thereof, other versions are readily apparent to those of ordinary skill in the art. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred embodiments contained herein.

Claims

What is claimed is:

1. A method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: converting said object into a self-describing form of said object; capturing the underlying representation of said self-describing form of said object; converting said underlying representation of said self-describing form of said object into a stream; sending said stream to said at least one second digital device such that the object is instantiated on said at least one second digital device; while said digital devices are connected by said link, at predetermined intervals, said at least one second digital device performing the steps of: converting current state of said object into a self-describing form of said current state of said object; capturing underlying representation of said self-describing form of said current state of said object ; converting said underlying representation of said self-describing form current state of said object into a stream; and sending said stream to said host digital device; and while said object remains in the form of a stream, performing the steps of: determining whether to send said stream to another of said at least one second digital device; and sending said stream to said at least one second digital device. 2. A method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: a) initializing a host buffer on said host digital device; b) initializing a receiving buffer on said at least one second digital device; c) initiating a first object class for said object on said host digital device; d) instantiating a code representation of said object and said object class on said host digital device; e) capturing a representation of underlying data of said object and said object class on said host digital device; f) attaching an object ID to said representation on said host digital device; g) attaching a streaming object ID to said representation on said host digital device; h) sending said object ID and said representation to said receiving buffer on said at least one second digital device; i) receiving said object ID and said representation in said receiving buffer on said at least one second digital device; j) initiating a second object class on said at least one second digital device, said second object class being respective to said at least one second digital device and corresponding to said first object class; k) instantiating said object on said at least one second digital device;

1) while said digital devices are connected, at predetermined intervals, said at least one second digital device sending current state of said object to said host digital device comprising the steps of:

1) capturing a representation of underlying data of said current state of said object and said object class on said at least one second digital device;

2) attaching an object ID to said representation on said at least one second digital device;

3) attaching a streaming object ID to said representation on said at least one second digital device; and

4) sending said object ID and said representation to said host buffer on said host digital device; m) receiving said object ID and said representation in said host buffer on said host digital device; n) determining whether to send said object ID and said representation to remaining of said at least one second digital device; o) sending said object ID and said representation to said remaining of said at least one second digital devices. 3. A method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: converting said object into a self-describing form of said object; capturing the underlying representation of said self-describing form of said object; converting said underlying representation of said self -describing form of said object into a stream; performing a conversion utility on said stream; sending said stream to said at least one second digital device such that the object is instantiated on said at least one second digital device; while said digital devices are connected by said link, at predetermined intervals, said at least one second digital device performing the steps of: converting current state of said object into a self-describing form of said current state of said object; capturing underlying representation of said self-describing form of said current state of said object ; converting said underlying representation of said self-describing form current state of said object into a stream; performing a conversion utility on said stream; and sending said stream to said host digital device; and while said object remains in the form of a stream, performing the steps of: determining whether to send said stream to another of said at least one second digital device; performing a conversion utility on said stream; and sending said stream to said at least one second digital device.

4. A method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: a) initializing a host buffer on said host digital device; b) initializing a receiving buffer on said at least one second digital device; c) initiating a first object class for said object on said host digital device; d) instantiating a code representation of said object and said object class on said host digital device; e) capturing a representation of underlying data of said object and said object class on said host digital device; f) attaching an object ID to said representation on said host digital device; g) attaching a streaming object ID to said representation on said host digital device; h) performing a conversion utility on said object ID and said representation; i) sending said object ID and said representation to said receiving buffer on said at least one second digital device; j) receiving said object ID and said representation in said receiving buffer on said at least one second digital device; k) initiating a second object class on said at least one second digital device, said second object class being respective to said at least one second digital device and corresponding to said first object class;

1) instantiating said object on said at least one second digital device; m) while said digital devices are connected, at predetermined intervals, said at least one second digital device sending current state of said object to said host digital device comprising the steps of:

3) attaching a streaming object ID to said representation on said at least one second digital device;

4) performing a conversion utility on said object ID and said representation; and 5) sending said object ID and said representation to said host buffer on said host digital device; n) receiving said object ID and said representation in said host buffer on said host digital device; o) determining whether to send said object ID and said representation to remaining of said at least one second digital device; p) performing a conversion utility on said object ID and said representation; and q) sending said object ID and said representation to said remaining of said at least one second digital devices.

5. A computer readable medium containing programming instructions for controlling a data processing system to perform a method, the method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: converting said object into a self-describing form of said object; capturing the underlying representation of said self-describing form of said object; converting said underlying representation of said self-describing form of said object into a stream; sending said stream to said at least one second digital device such that the object is instantiated on said at least one second digital device; while said digital devices are connected by said link, at predetermined intervals, said at least one second digital device performing the steps of: converting current state of said object into a self-describing form of said current state of said object; capturing underlying representation of said self-describing form of said current state of said object ; converting said underlying representation of said self-describing form current state of said object into a stream; and sending said stream to said host digital device; and while said object remains in the form of a stream, performing the steps of: determining whether to send said stream to another of said at least one second digital device; and sending said stream to said at least one second digital device.

6. A computer readable medium containing programming instructions for controlling a data processing system to perform a method, the method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: a) initializing a host buffer on said host digital device; b) initializing a receiving buffer on said at least one second digital device; c) initiating a first object class for said object on said host digital device; d) instantiating a code representation of said object and said object class on said host digital device; e) capturing a representation of underlying data of said object and said object class on said host digital device; f) attaching an object ID to said representation on said host digital device; g) attaching a streaming object ID to said representation on said host digital device; h) sending said object ID and said representation to said receiving buffer on said at least one second digital device; i) receiving said object ID and said representation in said receiving buffer on said at least one second digital device; j) initiating a second object class on said at least one second digital device, said second object class being respective to said at least one second digital device and corresponding to said first object class; k) instantiating said object on said at least one second digital device; 1) while said digital devices are connected, at predetermined intervals, said at least one second digital device sending current state of said object to said host digital device comprising the steps of:

1) capturing a representation of underlying data of said current state of said object and said object class on said at least one second digital device; 2) attaching an object ID to said representation on said at least one second digital device;

4) sending said object ID and said representation to said host buffer on said host digital device; m) receiving said object ID and said representation in said host buffer on said host digital device; n) determining whether to send said object ID and said representation to remaining of said at least one second digital device; o) sending said object ID and said representation to said remaining of said at least one second digital devices.

7. A computer readable medium containing programming instructions for controlling a data processing system to perform a method, the method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: converting said object into a self-describing form of said object; capturing the underlying representation of said self-describing form of said object; converting said underlying representation of said self-describing form of said object into a stream; performing a conversion utility on said stream; sending said stream to said at least one second digital device such that the object is instantiated on said at least one second digital device; while said digital devices are connected by said link, at predetermined intervals, said at least one second digital device performing the steps of: converting current state of said object into a self-describing form of said current state of said object; capturing underlying representation of said self-describing form of said current state of said object ; converting said underlying representation of said self-describing form current state of said object into a stream; performing a conversion utility on said stream; and sending said stream to said host digital device; and while said object remains in the form of a stream, performing the steps of: determining whether to send said stream to another of said at least one second digital device; performing a conversion utility on said stream; and sending said stream to said at least one second digital device.

8. A computer readable medium containing programming instructions for controlling a data processing system to perform a method, the method for streaming at least one object between a host digital device and at least one second digital device, said host digital device and said at least one second digital device connected by a link, said object being instantiated within a first application framework, said at least one second digital device having said first application framework, no framework or having a second application framework, said second application framework being disparate from said first application framework, the method comprising the steps of: a) initializing a host buffer on said host digital device; b) initializing a receiving buffer on said at least one second digital device; c) initiating a first object class for said object on said host digital device; d) instantiating a code representation of said object and said object class on said host digital device; e) capturing a representation of underlying data of said object and said object class on said host digital device; f) attaching an object ID to said representation on said host digital device; g) attaching a streaming object ID to said representation on said host digital device; h) performing a conversion utility on said object ID and said representation; i) sending said object ID and said representation to said receiving buffer on said at least one second digital device; j) receiving said object ID and said representation in said receiving buffer on said at least one second digital device; k) initiating a second object class on said at least one second digital device, said second object class being respective to said at least one second digital device and corresponding to said first object class; 1) instantiating said object on said at least one second digital device; m) while said digital devices are connected, at predetermined intervals, said at least one second digital device sending current state of said object to said host digital device comprising the steps of:

4) performing a conversion utility on said object ID and said representation; and

5) sending said object ID and said representation to said host buffer on said host digital device; n) receiving said object ID and said representation in said host buffer on said host digital device; o) determining whether to send said object ID and said representation to remaining of said at least one second digital device; p) performing a conversion utility on said object ID and said representation; and q) sending said object ID and said representation to said remaining of said at least one second digital devices.

9. A system for streaming at least one object, said system comprising: a host digital device; at least one receiving digital device connected via a connection means to said host digital device; means for sending and receiving said data; said host digital device and said at least one second digital device having a memory for storing said data; and a processor coupled to said memory functioning to (i) convert said object into a self-describing form of said object; (ii) capture the underlying representation of said self-describing form of said object; (iii) convert said underlying representation of said self -describing form of said object into a stream; (iv) send said stream to said at least one second digital device such that the object is instantiated on said at least one second digital device; (v) while said digital devices are connected by said link, at predetermined intervals, said at least one second digital device (v)(l) converts current state of said object into a self-describing form of said current state of said object;

(v)(2) captures underlying representation of said self-describing form of said current state of said object; (v)(3) converts said underlying representation of said self-describing form current state of said object into a stream; and

(v)(4) sends said stream to said host digital device; and (vi) while said object remains in the form of a stream (vi)(l) determine whether to send said stream to another of said at least one second digital device; (vi)(2) send said stream to said at least one second digital device.

10. The system claimed in claim 9, wherein said system is a computer system wherein said digital devices communicate with one another.

11. A system for streaming at least one object, said system comprising: a host digital device; at least one receiving digital device connected via a connection means to said host digital device; means for sending and receiving said data; said host digital device and said at least one second digital device having a memory for storing said data; and a processor coupled to said memory functioning to (a) initialize a host buffer on said host digital device;

(b) initialize a receiving buffer on said at least one second digital device; (c) initiate a first object class for said object on said host digital device; (d) instantiate a code representation of said object and said object class on said host digital device; (e) capture a representation of underlying data of said object and said object class on said host digital device; (f) attach an object ID to said representation on said host digital device; (g) attach a streaming object ID to said representation on said host digital device; (h) send said object ID and said representation to said receiving buffer on said at least one second digital device; (i) receive said object ID and said representation in said receiving buffer on said at least one second digital device; (j) initiate a second object class on said at least one second digital device, said second object class being respective to said at least one second digital device and corresponding to said first object class; (k) instantiate said object on said at least one second digital device; (1) while said digital devices are connected, at predetermined intervals, said at least one second digital device sends current state of said object to said host digital device by (1)(1) capture a representation of underlying data of said current state of said object and said object class on said at least one second digital device; (1)(2) attach an object ID to said representation on said at least one second digital device; (1)(3) attach a streaming object ID to said representation on said at least one second digital device; (1)(4) send said object ID and said representation to said host buffer on said host digital device; (m) receive said object ID and said representation in said host buffer on said host digital device; (n) determine whether to send said object ID and said representation to remaining of said at least one second digital device; (o) send said object ID and said representation to said remaining of said at least one second digital devices.

12. The system claimed in claim 11, wherein said system is a computer system wherein said digital devices communicate with one another.