US20030145089A1 - System and method for enabling arbitrary components to transfer data between each other - Google Patents

System and method for enabling arbitrary components to transfer data between each other Download PDF

Info

Publication number
US20030145089A1
US20030145089A1 US10/058,268 US5826802A US2003145089A1 US 20030145089 A1 US20030145089 A1 US 20030145089A1 US 5826802 A US5826802 A US 5826802A US 2003145089 A1 US2003145089 A1 US 2003145089A1
Authority
US
United States
Prior art keywords
data
component
data transfer
transfer
components
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/058,268
Inventor
Warren Edwards
Mark Newman
Jana Sedivy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gula Consulting LLC
Original Assignee
Xerox Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Xerox Corp filed Critical Xerox Corp
Priority to US10/058,268 priority Critical patent/US20030145089A1/en
Assigned to XEROX CORPORATION reassignment XEROX CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EDWARDS, WARREN K., NEWMAN, MARK W., SEDIVY, JANA Z.
Assigned to BANK ONE, NA, AS ADMINISTRATIVE AGENT reassignment BANK ONE, NA, AS ADMINISTRATIVE AGENT SECURITY AGREEMENT Assignors: XEROX CORPORATION
Priority to JP2003018254A priority patent/JP4424910B2/en
Priority to EP03002068A priority patent/EP1331571B1/en
Priority to DE60302368T priority patent/DE60302368T2/en
Publication of US20030145089A1 publication Critical patent/US20030145089A1/en
Assigned to JPMORGAN CHASE BANK, AS COLLATERAL AGENT reassignment JPMORGAN CHASE BANK, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: XEROX CORPORATION
Priority to US10/732,700 priority patent/US7421494B2/en
Assigned to XEROX CORPORATION reassignment XEROX CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: BANK ONE, NA
Assigned to XEROX CORPORATION reassignment XEROX CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: JP MORGAN CHASE BANK, NA
Assigned to YORANSO CONSULTING LIMITED LIABILITY COMPANY reassignment YORANSO CONSULTING LIMITED LIABILITY COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: XEROX CORPORATION
Assigned to XEROX CORPORATION reassignment XEROX CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: JPMORGAN CHASE BANK, N.A. AS SUCCESSOR-IN-INTEREST ADMINISTRATIVE AGENT AND COLLATERAL AGENT TO BANK ONE, N.A.
Assigned to XEROX CORPORATION reassignment XEROX CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: JPMORGAN CHASE BANK, N.A. AS SUCCESSOR-IN-INTEREST ADMINISTRATIVE AGENT AND COLLATERAL AGENT TO JPMORGAN CHASE BANK
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Definitions

  • This invention relates generally to communication systems and methods and, more particularly, to a system and method for enabling arbitrary components to transfer data between each other using one or more universal data transfer interfaces employing mobile code.
  • An arbitrary component such as a PDA attempting to communicate with a file system, or a printer device attempting to do the same, must be explicitly programmed to understand one or more of the standardized protocols mentioned above.
  • An example includes a computer device or application having to be programmed to understand a printer device by installing a domain-specific printer driver. If the device or application is programmed to understand how to communicate and use a printer device, generically, the driver will only enable the device or application to access a particular type of printer device and not the universe of all printer devices. Thus, when new and unknown components enter the equation, the application must be reprogrammed to understand the new standardized protocols used to communicate with the new components.
  • JiniTM developed by Sun Microsystems of Palo Alto, Calif. and described in “A collection of JiniTM Technology Helper Utilities and Services Specifications,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-214, 2000; and “JiniTM Technology Core Platform Specification,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-126, 2000, all of which are hereby incorporated by reference in their entirety, which uses domain-specific interfaces
  • the PDA system in order for a component such as a PDA system to communicate with another component such as a printer, the PDA system must contain a priori knowledge of the semantics of the printer's programmatic interfaces. In other words, a component that knows how to print still might not know how to transfer data between a file system, a scanner device or a network translation service until it is explicitly programmed to know how to communicate with the interface for the particular components.
  • a system for enabling components to transfer data between each other in accordance with the present invention includes a first component having a universal data transfer interface and a second component invoking the universal data transfer interface to use a data transfer session object to transfer data between the first component and at least one of the components.
  • a system for enabling components to transfer data between each other in accordance with the present invention includes a first component having a first universal data transfer interface, a second component having a second universal data transfer interface, and a third component invoking the first universal data transfer interface and the second universal data transfer interface to use a data transfer session object to transfer data between the first component and the second component.
  • a method and a program storage device readable by a machine and tangibly embodying a program of instructions executable by the machine for enabling components to transfer data between each other in accordance with the present invention include invoking a universal data transfer interface to obtain a data transfer session object, and using the data transfer session object to transfer data between a first component and at least one of the components.
  • a method and a program storage device readable by a machine and tangibly embodying a program of instructions executable by the machine for enabling components to transfer data between each other in accordance with the present invention include invoking a first universal data transfer interface and a second universal data transfer interface, obtaining a data transfer session object from one of the invoked first universal data transfer interface or the second universal data transfer interface, and using the data transfer session object to transfer data between a first component and a second component.
  • the present invention allows components using the same or different communications protocols and/or data types to transfer data between each other without having a priori knowledge of any domain-specific interfaces, protocols or data formats.
  • the invention enables components to initiate data transfer sessions between other components.
  • FIG. 1 is a diagram of a system for enabling arbitrary components to transfer data between each other in accordance with one embodiment
  • FIG. 2 is a block diagram of an exemplary arbitrary component utilized in the system for enabling arbitrary components to transfer data between each other;
  • FIG. 3 is a diagram of a system for enabling one arbitrary component to receive data from another arbitrary component in accordance with another embodiment
  • FIG. 4 is a flow chart of a process for receiving data from another arbitrary component
  • FIG. 5 is a diagram of a system for enabling one arbitrary component to transmit data to another arbitrary component in accordance with another embodiment
  • FIG. 6 is a flow chart of a process for transmitting data to another arbitrary component
  • FIG. 7 is a block diagram of a system where one arbitrary component enables two other arbitrary components to transfer data between each other in accordance with another embodiment
  • FIG. 8 is a flow chart of a process where an arbitrary component enables other arbitrary components to transfer data between each other.
  • system 10 for enabling arbitrary components to transfer data between each other in accordance with one embodiment of the present invention is shown in FIG. 1.
  • system 10 includes computer 20 , printer 21 , personal digital assistant (“PDA”) 22 , server 23 and facsimile machine 24 (“components 20-24”).
  • a method in accordance with one embodiment includes computer 20 obtaining one of the universal data transfer interfaces (i.e., the data source interface or the data sink interface) associated with one or more of components 21 - 24 , and invoking the one or more obtained universal data transfer interfaces to transfer data between components 20 - 24 .
  • the universal data transfer interfaces i.e., the data source interface or the data sink interface
  • the present invention allows components 20 - 24 using the same or different communication protocols and/or data types to transfer data between themselves without having a priori knowledge of any domain-specific interfaces, protocols or data formats.
  • the present invention also enables components 20 - 24 to initiate data transfer sessions between other components 20 - 24 .
  • computer 20 is operatively coupled to each of the components 21 - 24 in this particular embodiment, although other coupling arrangements or configurations can be used as well as greater or lesser numbers of components.
  • system 10 could comprise one or more of the components 21 - 24 directly coupled to one or more of the other components 21 - 24 (e.g., a peer-to-peer system) or system 10 could comprise components 20 and 21 , which are coupled together.
  • a conventional dial-up communication system through private branch exchanges (“PBX”) and using public switched telephone lines and line based telephone communication protocols may be used by components 20 - 24 to communicate with each other.
  • PBX private branch exchanges
  • a variety of different types of communication systems and/or protocols may be used.
  • communication systems or network architectures such as local area networks (“LAN”), wide area networks (“WAN”) and cellular or satellite communications network systems that utilize signals, such as satellite signals, radio waves, microwaves and/or infrared signals, can be used.
  • LAN local area networks
  • WAN wide area networks
  • satellite communications network systems that utilize signals, such as satellite signals, radio waves, microwaves and/or infrared signals
  • a variety of communication protocols for transferring data such as xDSL, ISDN, TCP/IP or protocols defined by the RFC and OSI organizations can also be used.
  • Components 20 - 24 may use one or more communications protocols. Moreover, the arrows in FIG. 1 depict the flow of communications between components 20 - 24 .
  • computer 20 comprises a central processing unit (“CPU”) 30 , memory 32 and I/O unit 34 , which are coupled together by a bus 36 , although computer 20 may comprise any type of device or system that can store, process and execute instructions for performing one or more methods of the present invention.
  • computer 20 may also comprise a scanner, cellular telephone, display device, video input/output device, audio input/output device, remote control device or an appliance.
  • Computer 20 could also comprise any type of device with circuitry that is hard-wired to execute instructions for performing one or more methods of the present invention.
  • Computer 20 executes instructions for an operating system environment it is operating in, such as the UNIX® environment, as described in “Advanced Programming in the UNIX® Environment,” W. Richard Stevens, Addison-Wesley Publishing Company, 1974, which is hereby incorporated by reference in its entirety.
  • computer 20 does not use the same communication protocol as any of the other components 21 - 24 , but in other embodiments computer 20 does use the same communication protocol as any of the other components 21 - 24 .
  • computer 20 may be operating in the UNIX® environment using a first type of communication protocol to transfer data, while printer 21 may be operating in a Microsoft Windows® environment, but using a second type of communication protocol.
  • CPU 30 may comprise a processor, such as an Intel Pentium III processor.
  • the CPU 30 executes at least one program of stored instructions for a method for enabling arbitrary components to transfer data between each other in accordance with the present invention as described and illustrated herein.
  • CPU 30 may also execute instructions for other tasks, including network services, such as providing data, memory, file directories, individual files, word processing applications, accounting applications or engineering applications.
  • network services such as providing data, memory, file directories, individual files, word processing applications, accounting applications or engineering applications.
  • the instructions for the task such as for creating a spreadsheet, as well as the instructions for performing one or more of the methods of the present invention are carried out by the CPU 30 in computer 20 .
  • the instructions may be expressed as executable programs written in a number of computer programming languages, such as BASIC, Pascal, C, C++, C#, Java, Perl, COBOL, FORTRAN, assembly language, machine code language, or any computer code or language that can be understood and performed by the CPU 30 .
  • computer programming languages such as BASIC, Pascal, C, C++, C#, Java, Perl, COBOL, FORTRAN, assembly language, machine code language, or any computer code or language that can be understood and performed by the CPU 30 .
  • Memory 32 may comprise any type of fixed or portable memory device accessible by the CPU 30 , such as hard-disks, floppy-disks, compact disks (“CD”), digital video disks, magnetic tape, optical disk, ferroelectric memory, read only memory, random access memory, electrically erasable programmable read only memory, flash memory, erasable programmable read only memory, static random access memory, dynamic random access memory, ferromagnetic memory, charge coupled devices, smart cards, or any other type of computer-readable mediums.
  • Memory 32 stores instructions 38 for a method of enabling arbitrary components to transfer data between each other in accordance with one embodiment of the present invention for execution by CPU 30 , although some or all of these instructions can be stored elsewhere.
  • One or more sets of universal interfaces or data objects may be stored in memory 32 so they can be retrieved as needed by the CPU 30 during operation of the present invention as will be described in further detail herein. Although in this embodiment the CPU 30 and memory 32 are shown in the same physical location, they may be located at different physical locations, such as in server 23 shown in FIG. 1.
  • Computer 20 may communicate with components 21 - 24 using I/O unit 34 .
  • I/O unit 34 may comprise a router such as any type of Ethernet based device having sufficient ports to operatively couple computer 20 to components 21 - 24 .
  • printer 21 comprises a conventional printing device capable of rendering graphical representations on a printing medium, for example. Since devices such as printer 21 are well known in the art, the specific elements, their arrangement within printer 21 and operation will not be described in detail here.
  • PDA 22 comprises a conventional hand held device that may perform such functions as telephony, facsimile transmissions or networking. Since devices such as PDA 22 are well known in the art, the specific elements, their arrangement within PDA 22 and operation will not be described in detail here.
  • Server 23 comprises a conventional computer system having one or more CPU's, memory, I/O units and one or more storage mediums, which are coupled together by a bus and used by server 23 to store and process instructions in accordance with one or more embodiments of the present invention as described further herein. Since devices such as server 23 are well known in the art, the specific elements, their arrangement within server 23 and operation will not be described in detail here.
  • Facsimile machine 24 comprises a conventional facsimile device that can send and receive pictures or text over a telephone line or network. Since devices such as facsimile machine 24 are well known in the art, the specific elements, their arrangement within facsimile machine 24 and operation will not be described in detail here.
  • PDA 22 has stored in a memory, or otherwise has access to by accessing server 23 , for example, which will hereinafter be referred to as being “associated with,” a set of universal interfaces 22 a comprising a data source interface, a contextual interface, a notification interface and a user interface.
  • the particular number and/or combination of interfaces may vary and will depend upon the particular type of device PDA 22 is, and the capabilities and/or services desired or provided by it.
  • PDA 22 and hence the set of universal interfaces 22 a, may be updated at any time to add, delete or modify interfaces.
  • computer 20 is programmed to access the interfaces associated with PDA 22 .
  • PDA 22 could access one or more interfaces (not illustrated) associated with computer 20 .
  • Computer 20 may access the set of universal interfaces 22 a through data object 22 b to effect different types of communications as described herein.
  • Each of the interfaces in the set of universal interfaces 22 a comprise instructions, sets of operations and/or other data that can be understood and performed by computer 20 to enable it to communicate and transfer data (i.e., transmitting or receiving data) with PDA 22 , exchange contextual information with PDA 22 , provide computer 20 with event notifications for PDA 22 , or enable computer 20 to receive user interfaces to allow users of computer 20 to access and/or manipulate PDA 22 .
  • each interface in the set of universal interface 22 a is not domain-specific with respect to PDA 22 .
  • the data source interface includes several operations such as a getSourceDataFlavor( ) operation and a beginTransferSession( ) operation. Further, the data source interface includes instructions and data that can be performed by computer 20 to establish a data transfer session to enable computer 20 to receive data from PDA 22 .
  • the getSourceDataFlavor( ) operation includes instructions and data that may be performed by computer 20 for determining the types of data PDA 22 can transmit.
  • computer 20 performs the getSourceDataFlavor( ) operation that returns a list of one or more data types supported by PDA 22 .
  • the data types in this embodiment are typically MIME data types.
  • computer 20 may determine that PDA 22 supports data in a “JPEG” format.
  • the beginTransferSession( ) operation includes instructions and data that may be performed by computer 20 to request PDA 22 to establish a data transfer session to receive data by returning a data transfer session object 22 c to computer 20 through data object 22 b.
  • the beginTransferSession( ) operation may be passed parameters when invoked such as a context parameter, an initial lease duration parameter and a data flavor parameter.
  • computer 20 passes a context parameter to the beginTransferSession( ) operation when invoking it to inform PDA 22 of its identity for a variety of reasons, such as for identifying computer 20 to PDA 22 , identifying a user at computer 20 to PDA 22 , identifying the location of computer 20 on a network to PDA 22 or for security purposes.
  • PDA 22 may decide whether to transmit data to computer 20 based upon the identity information provided in the context parameter. Further, data transfer sessions are leased and would thus need to be renewed periodically by computer 20 at intervals of time corresponding to a value specified in the initial lease duration parameter passed to the beginTransferSession( ) operation to keep the data transfer session active, although in other embodiments the sessions need not be leased.
  • PDA 22 will stop transmitting data to computer 20 under the assumption that computer 20 has failed to renew the lease because it has either crashed or has otherwise become unreachable.
  • PDA 22 supports one or more types of data, as determined by performing the getSourceDataFlavor( ) operation, a data flavor parameter may be passed into the beginTransferSession( ) operation.
  • Computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event computer 20 and PDA 22 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer.
  • computer 20 may determine a preferred data type using a number of methods such as enabling users at computer 20 to indicate preferred data types, randomly selecting one of the compatible data types between computer 20 and PDA 22 or selecting the data type that will be most efficient for the particular data being transferred.
  • the contextual interface comprises a getcontexto operation that includes instructions and data that can be performed by computer 20 for retrieving contextual information from PDA 22 .
  • the contextual information is stored in a memory at PDA 22 as a multi-valued data structure that resembles a hash table, although the contextual information can be stored in any other format.
  • the contextual information includes information about PDA 22 such as what type of device it is, its operating status, identity, location, administrative domain, or any other type of environment data.
  • the contextual information may be stored at another physical location such as server 23 .
  • the notification interface includes a register( ) operation, which may be passed one or more parameters and performed by computer 20 to enable it to receive asynchronous notifications about events generated by PDA 22 , although it may receive synchronous notifications as well.
  • Computer 20 performs the registers operation, passing to it a context parameter, a component parameter and an initial lease duration parameter.
  • the context parameter provides PDA 22 with the identity of computer 20 for a number of reasons, such as enabling PDA 22 to decide whether it would desire sending notifications to computer 20 for security purposes or record keeping.
  • the component parameter identifies computer 20 as desiring to be notified of events occurring at PDA 22 .
  • event registrations are leased and must be renewed periodically by computer 20 at intervals of time corresponding to the value specified in the initial lease duration parameter to keep the event registration active.
  • the notification interface includes instructions for relieving PDA 22 of its obligation to provide computer 20 with notifications about generated events since it will assume that computer 20 has failed to renew the lease because it has either crashed or has otherwise become unreachable.
  • PDA 22 instead was a printer device and computer 20 instead was a word processing application
  • PDA 22 would be able to provide computer 20 with an event notification in the case where paper in the printer device jammed.
  • computer 20 could display the event notification (i.e., paper jam) to the user using a graphical user interface (“GUI”).
  • GUI graphical user interface
  • the user interface comprises a getUI( ), getState( ) and setState( ) operation that includes instructions and data that can be performed by computer 20 for retrieving or generating a user window specific to PDA 22 to provide users of computer 20 with so they can access and/or manipulate PDA 22 to take advantage of additional functionality of PDA 22 .
  • the getUI( ) operation can be passed parameters when invoked by computer 20 to indicate which type of user window the user would like generated, as described in further detail herein.
  • the getuI( ) operation returns to computer 20 , from PDA 22 , a user window and/or instructions for generating or retrieving a user window, which may be instantiated by computer 20 to display the user window to users, for example.
  • the getState( ) operation includes instructions and data for requesting that a state token object be returned to computer 20 from PDA 22 .
  • the state token object may be an opaque object with respect to computer 20 , which is particular to PDA 22 and further may encapsulate the current state (e.g., device settings or configuration) of PDA 22 , although the state token object may be transparent with respect to computer 20 in a case where computer 20 is able to understand the state token object of PDA 22 .
  • PDA 22 may use different types of state token objects depending upon the particular type of device it is (e.g., a printer device or word processing application). Still further, PDA 22 may encode its respective state token objects in various ways, such as pointers or URLs pointing to particular configurations.
  • the state token objects may include a representation of the current state of PDA 22 .
  • the setstate( ) operation includes instructions and data that may be performed by computer 20 for generating the user window using the configuration data included in the state token object.
  • Computer 20 may pass the state token object as a parameter to the setState( ) operation when it is invoked, which can be used by PDA 22 to return instructions and data that can be performed by computer 20 for retrieving or generating the user window having the stored configuration included in the state token object.
  • the setState( ) operation may also be invoked by computer 20 to reset the state of PDA 22 without having to recreate the user window for the user.
  • Mobile code is executable data that can be transmitted to computer 20 where it is executed.
  • Java is an implementation of executable content (i.e., mobile code) that is widely used on the Internet. Users can download the mobile code from the Internet, for example, and locally run a program written in a truly common programming language.
  • the mobile code is object oriented mobile code, which is a programming methodology that is well known in the programming arts, where data types may be defined along with associated procedures or sets of instructions, the data types in this context often referred to as classes. Thus, a set of procedures or instructions may be associated with one or more data types.
  • a draw procedure could be performed to draw circles or rectangles depending upon the type of data provided, or passed, to the procedure when it is invoked.
  • a circle data type defines a radius coordinate, for example, and a draw procedure is invoked and the circle data type is passed to the draw procedure, the draw procedure, inheriting any other data types associated with the draw procedure, can use the data provided thereto to perform the appropriate procedure or sets of instructions to draw a circle.
  • the procedures, sets of instructions and other data associated with the particular interface become available to computer 20 to access and perform, as will be described further herein.
  • variables, parameters and data may be passed or provided to the universal interfaces that will be understood and utilized accordingly by computer 20 , depending upon the particular type of communication desired.
  • the interfaces may comprise sets of instructions or references to other interfaces, wherein computer 20 could utilize the data or perform the instructions accordingly.
  • Computer 20 may also directly access each of the interfaces included in the set of universal interfaces 22 a without needing to obtain data object 22 b to effect the different types of communications described herein.
  • each of the interfaces in the set of universal interfaces 22 a would comprise the same instructions, sets of operations and/or other data that could be understood and performed by computer 20 to enable it to communicate and transfer data with PDA 22 as well as the other functions described above. Therefore, mobile code may not be required in this example, although it could be used as necessary such as where data is being transferred.
  • data object 22 b is received from PDA 22 and stored in computer 20 , although the data object 22 b could be stored elsewhere, such as server 23 .
  • the set of universal interfaces 22 a is accessible to computer 20 through the data object 22 b. More specifically, data object 22 b supports the various operations defined by the interfaces associated with PDA 22 , which are assumed to be known and understood by computer 20 .
  • the data object 22 b comprises instructions (i.e., computer executable code) and/or data that provide particular implementations of the one or more interfaces associated with the PDA 22 from which the data object 22 b is associated with.
  • data object 22 b as provided by PDA 22 to computer 20 would provide a custom implementation of the data source interface that would be specialized to communicate with PDA 22 using whichever protocols and/or data formats have been decided upon by the developer of PDA 22 .
  • the data transfer session object 22 c includes a getTransferData( ) operation, a getDataSource( ) operation, an abort( ) operation, a fail( ) operation, a completed( ) operation, the register( ) operation associated with the notification interface described above, a getLease( ) operation, a getViewer( ) operation, a getEditor operation, a getPrinter( ) operation, as well as any other instructions needed to enable computer 20 to receive data from PDA 22 , including protocols for video or file transfer, for example, which may depend upon the type of data being received.
  • Data transfer session object 22 c includes the above-mentioned operations and instructions that are particular to PDA 22 , but may be performed by computer 20 to receive data.
  • computer 20 i.e., a data sink component
  • PDA 22 i.e., a data source component
  • computer 20 invokes the getDataTransfer( ) operation to actually retrieve the data from PDA 22 .
  • computer 20 may invoke the getDataSource( ) operation to determine the identity and other attributes of PDA 22 .
  • Computer 20 may also invoke the getDataSource( ) operation to determine whether it should modify its behavior during data transfers or whether it should even allow certain data transfers to occur.
  • computer 20 does not need to know details with respect to how to receive and understand the data sent from the PDA 22 through the data transfer session object 22 c.
  • the instructions and various operations included within data transfer session object 22 c include information regarding the specific protocols, mediums and types of data that are particular to PDA 22 , which may be executed by computer 20 to be able to receive and understand data transferred from PDA 22 , even though PDA 22 may utilize different protocols, mediums or types of data.
  • data transfer session object 22 c includes instructions for enabling computer 20 to negotiate with PDA 22 during the transfer of data to select a communications protocol or medium to use to transfer data between each other based upon the type of data being transferred.
  • the instructions may also enable computer 20 and PDA 22 to negotiate with each other for using different protocols for the data transfer session based upon the type of data being transferred. Moreover, the instructions may enable computer 20 to modify the format or the content of data being transferred through the data transfer session object 22 c to convert the data as necessary from a first data transfer protocol associated with computer 20 to a second data transfer protocol associated with PDA 22 . For example, if PDA 22 is transferring streaming video to computer 20 , then it may be more efficient for PDA 22 to transfer the data using compression or progressive encodings.
  • Computer 20 could perform the instructions and operations included within data transfer session object 22 c so that the data transfer session object 22 c negotiates with computer 20 to decide upon the particular protocol to use for the data transfer session, and in turn provide computer 20 , through data transfer session object 22 c, with the operations, instructions and data necessary to enable computer 20 to retrieve and understand the data transferred through the data transfer session object 22 c. Further, computer 20 and PDA 22 may negotiate on a preferred physical transport medium, if one is available. For instance, if a shared FireWire, IR or a Bluetooth connection is found to link computer 20 and PDA 22 together it could be used instead of an Ethernet connection as the physical transport medium to transfer the data.
  • the instructions may also include operations for scaling down data rates over slow data transmission links, or may include operations for increasing redundancy in the face of errors during a data transfer session.
  • data transfer session object 22 c may include instructions that may be performed by computer 20 to enable it to view the type of data being transferred through data transfer session object 22 c.
  • computer 20 may perform the instructions included in data transfer session object 22 c to view, on a display device associated with computer 20 , for example, the data being transferred.
  • data transfer session object 22 c may include a getViewer( ) operation that returns a viewer object when the operation is invoked by computer 20 .
  • the viewer object is specific to the particular type of data that is understood and used by PDA 22 .
  • the viewer object may include the same instructions described above for providing computer 20 with a user interface except that the instructions, when performed by computer 20 , enable computer 20 to view the data being transferred.
  • the viewer object may also include instructions for enabling computer 20 to view the particular data type associated with PDA 22 and being transferred despite computer 20 not being previously programmed to view such types of data.
  • the getViewer( ) operation may be passed parameters, as described above with respect to the user interface, for enabling computer 20 to specify the type of user window (i.e., graphical or speech) computer 20 would like to display.
  • the getViewer( ) operation may be stored in PDA 22 and accessible to computer 20 through data object 22 b.
  • the getViewer( ) operation may be stored in a central repository, such as in server 23 (FIG. 1).
  • the server 23 may store one or more getViewer( ) operations, where each operation includes instructions for enabling computer 20 to view a particular type of data.
  • view or “display” in this embodiment may encompass other forms of output, such as where the instructions in data transfer session object 22 c enable computer 20 to play an audio file in a particular format through an audio output device such as a speaker.
  • data transfer session object 22 c may include additional operations, such as a getEditor( ) operation and a getPrinter( ) operation, which have the same instructions as the getViewer( ) operation except the getEditor( ) operation and the getPrinter( ) operation include instructions for enabling computer 20 to edit or print, respectively, data being transferred, regardless of whether computer 20 has been programmed to understand the particular type of data associated with PDA 22 .
  • computer 20 would not need to understand all of the types of data formats it may encounter in a data transfer session because the instructions to understand such data may be included in data transfer session object 22 c.
  • computer 20 at least has the capability of executing the various instructions and operations included within data transfer session object 22 c.
  • the abort( ) operation includes instructions that enable computer 20 to terminate the data transfer session with PDA 22 .
  • computer 20 may indicate to PDA 22 that a data transfer session has failed or has been completed by performing the fail( ) operation or the complete( ) operation, respectively.
  • listeners at components 20 - 24 who expressed an interest in the status of the data transfer session by registering will be notified of the event through the register( ) operation.
  • a signaling protocol enables computer 20 to indicate when computer 20 has completed using the data transfer session object 21 c in the case where PDA 22 cannot automatically determine when computer 20 is finished such as where the data transfer session has an indeterminate duration (e.g., streaming video).
  • the getLease( ) operation enables computer 20 to renew the lease according to the initial lease duration parameter to ensure the data transfer session remains active.
  • computer 20 performs a discovery process to determine whether computer 20 and PDA 22 can transfer data between each other.
  • computer 20 discovers PDA 22 using a variety of discovery systems such as the BluetoothTM Service Location Protocol (“SLP”) developed by Bluetooth SIG, inc., described in “Specification of the Bluetooth System,” Version 1.1 core, Bluetooth Consortium 2001, the Universal Description, Discovery, and Integration Protocol (“UDDI”), developed by the Ariba, IBM and Microsoft Corporation., described in “UDDI Technical Whitepaper,” Universal Description, Discovery, and Integration Consortium, pp. 1-12, 2000; “Universal Description, Discovery and Integration Data Structure Reference V 1.0,” Ariba, Inc., International Business Machines Corporation and Microsoft Corporation, pp.
  • SLP BluetoothTM Service Location Protocol
  • UDDI Universal Description, Discovery, and Integration Protocol
  • Discovered PDA 22 returns data object 22 b to computer 20 .
  • Computer 20 may introspect the received data object 22 b to determine which one or more interfaces are associated with PDA 22 .
  • computer 20 upon computer 20 performing the above-described discovery and receiving data object 22 b from PDA 22 , computer 20 introspects the received data object 22 b to determine which universal interfaces PDA 22 is associated with.
  • Computer 20 determines that PDA 22 is at least associated with a data source interface, and thus PDA 22 can provide it with data.
  • Computer 20 invokes the data source interface associated with PDA 22 and included in data object 22 b, which includes instructions that instruct computer 20 to perform the getSourceDataFlavors( ) operation included in data object 22 b.
  • the getSourceDataFlavors( ) operation in turn includes instructions for accessing PDA 22 to provide computer 20 with the types of data supported by PDA 22 .
  • step 42 computer 20 performs the beginTransferSession( ) operation included in the data source interface.
  • the beginTransferSession( ) operation when invoked may be passed the context parameter, the initial lease duration parameter and the data flavor parameter.
  • PDA 22 returns the data transfer session object 22 c to computer 20 .
  • Computer 20 may determine a preferred data type using the methods described above and provide a preferred data type value to receive the data in to the data flavor parameter, otherwise computer 20 will receive the data in whichever data format it is provided in by PDA 22 .
  • Computer 20 may receive data from PDA 22 by way of the data transfer session object 22 c.
  • data transfer session object 22 c includes the getTransferData( ) operation and the other operations and instructions described above that may be performed by computer 20 to retrieve data from PDA 22 .
  • the data is transferred from PDA 22 to computer 20 through data transfer session object 21 c at step 46 .
  • computer 20 maybe able to view data types that it is not natively programmed to understand.
  • PDA 22 may return the instructions, operations or data directly to computer 20 to enable it to understand the data being transferred from PDA 22 .
  • facsimile machine 24 has stored in a memory, or otherwise has access to by accessing server 23 , for example, a set of universal interfaces 24 a comprising a data sink interface, which will be described in further detail herein.
  • facsimile machine 24 may be associated with any number of interfaces and in any combination.
  • Facsimile machine 24 may access the set of universal interfaces 24 a through data object 24 b to effect different types of communications.
  • Each of the interfaces in the set of universal interfaces 24 a comprise instructions, sets of operations and/or other data that can be understood and performed by computer 20 to enable it to communicate and transfer data with facsimile machine 24 .
  • Except for the data sink interface, each of the interfaces mentioned above are the same as those described above in connection with PDA 22 , but each interface includes instructions that are specific to the particular device they are associated with (i.e., facsimile machine 24 ).
  • the data sink interface includes several operations such as a getSinkDataFlavor( ) and a Transfer( ) operation. Further, the data sink interface includes instructions and data that can be performed by computer 20 for establishing a data transfer session to enable computer 20 to transmit data to facsimile machine 24 .
  • the getSinkDataFlavor( ) operation includes instructions and data that may be performed by computer 20 for determining which types of data facsimile machine 24 can support.
  • computer 20 may perform the getSinkDataFlavor( ) operation which returns a list of one or more data types supported by facsimile machine 24 .
  • the data types in this embodiment are typically MIME data types.
  • the Transfer( ) operation includes instructions and data that may be performed by computer 20 to request facsimile machine 24 to establish a data transfer session so computer 20 can begin transmitting data to facsimile machine 24 .
  • the Transfer( ) operation may be passed parameters in this embodiment when invoked such as data transfer session object 20 c associated with computer 20 , a context parameter and a data flavor parameter.
  • computer 20 passes the data transfer session object 20 c into the Transfer( ) operation to make it available to facsimile machine 24 so it may perform the instructions therein to actually receive the data from computer 20 .
  • the data transfer session object 20 c associated with computer 20 includes the same types of instructions, data and operations as data transfer session object 22 c described above, except that the instructions, data and operations included therein are particular to computer 20 .
  • Computer 20 passes a context parameter into the Transfer( ) operation when invoking it to inform facsimile machine 24 of its identity for a variety of reasons, such as for security purposes. Facsimile machine 24 may decide whether to allow computer 20 to transmit data to it based upon the identity information provided in the context parameter.
  • facsimile machine 24 supports one or more types of data, as determined by performing the getSinkDataFlavor ( ) operation, a data flavor parameter may be passed into the Transfer( ) operation to inform facsimile machine 24 the type of data that will be transmitted by computer 20 .
  • computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event computer 20 and facsimile machine 24 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer.
  • computer 20 may determine a preferred data type using a number of methods such as enabling users at computer 20 to indicate preferred data types, randomly selecting one of the compatible data types between computer 20 and facsimile machine 24 or selecting the data type that will be most efficient for the particular data being transferred. Additionally, where computer 20 and facsimile machine 24 support a finite number of compatible data types with respect to each other, computer 20 may select the compatible data type to transmit the data to facsimile machine 24 .
  • computer 20 performs the discovery process and determines by introspecting data object 24 b, as described above in connection with one or more embodiments, that computer 20 and facsimile machine 24 can transfer data between each other because facsimile machine 24 is at least associated with a data sink interface.
  • Computer 20 invokes the data sink interface associated with facsimile machine 24 and included in data object 24 b, which includes instructions that instruct computer 20 to perform the getSinkDataFlavor( ) operation.
  • the getSinkDataFlavor( ) operation in turn includes instructions for accessing facsimile machine 24 to provide computer 20 with the types of data supported by facsimile machine 24 , as described above.
  • step 52 computer 20 performs the Transfer( ) operation included in the data sink interface.
  • computer 20 passes into the Transfer( ) operation data object 20 c, the context parameter and the data flavor parameter when invoked as described above.
  • facsimile machine 24 performs the instructions included within data transfer session object 20 c as provided to it through the Transfer( ) operation to receive data from computer 20 .
  • the data is transferred from computer 20 to facsimile machine 24 by way of data transfer session object 20 c at step 56 .
  • printer 21 is associated with a set of universal interfaces 21 a comprising a data source interface, a data sink interface and a contextual interface.
  • Server 23 is associated with a set of universal interfaces 23 a comprising a data source interface, a data sink interface and a contextual interface.
  • Each of the interfaces mentioned above are the same as those described above in connection with FIGS. 3 and 5, except that each interface in this embodiment includes instructions that are specific to the particular device they are associated with (i.e., printer 21 or server 23 ).
  • the data transfer session object 25 associated with printer 21 includes the same instructions, data and operations as data transfer session objects 20 c and 22 c as described above, except that the instructions, data and operations included therein are particular to printer 21 .
  • step 60 computer 20 performs the discovery process and determines by introspecting data objects 21 b and 23 b, as described above in connection with one or more embodiments, that printer 21 and server 23 can transfer data between each other because printer 21 is associated with a data source interface and server 23 is associated with a data sink interface.
  • Computer 20 invokes the data source interface associated with printer 21 and performs the getSourceDataFlavors( ) operation included in data object 21 b to access printer 21 to determine the types of data supported by printer 21 , as described above.
  • step 62 computer 20 performs the beginTransferSession( ) operation included in the data source interface.
  • the beginTransferSession( ) operation may be passed the context parameter associated with computer 20 or server 23 .
  • computer 20 may invoke the contextual interface associated with server 23 and accessible through data object 23 b.
  • computer 20 would receive the contextual information from server 23 but in turn provide it to printer 21 through the beginTransferSession( ) operation. This enables printer 21 to decide whether it would like to transfer the data with server 23 .
  • computer 20 may provide its own contextual information to printer 21 for the same reasons as well as the initial lease duration parameter when invoked as described above.
  • Computer 20 invokes the data sink interface associated with server 23 and included in data object 23 b, which includes instructions that instruct computer 20 to perform the getSinkDataFlavor( ) operation.
  • the getSinkDataFlavor( ) operation in turn includes instructions for accessing server 23 to provide computer 20 with the types of data supported by server 23 .
  • server 23 supports one or more types of data, as determined by performing the getSinkDataFlavor( ) operation, a data flavor parameter may be passed into the Transfer( ) operation to inform server 23 the type of data that will be transmitted to it.
  • computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event printer 21 and server 23 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer between printer 21 and server 23 .
  • Printer 21 returns the data source object 25 to computer 20 through data object 21 b.
  • step 64 computer 20 performs the Transfer( ) operation included in the data sink interface associated with server 23 and included in data object 23 b.
  • the Transfer( ) operation may also be passed parameters when invoked, including the data source object 25 received by computer 20 from printer 21 , a context parameter and/or the data flavor parameter associated with printer 21 .
  • Computer 20 provides to server 23 the context parameter associated with computer 20 and/or printer 21 so that server 23 may decide whether it would like to participate in the data transfer for a number of reasons, such as for security purposes.
  • Computer 20 is able to provide server 23 with its own contextual information by performing its own instructions to obtain its contextual information and passing the information into the Transfer( ) operation via the context parameter.
  • Server 23 may receive data from printer 21 by way of the data transfer session object 25 received from computer 20 from printer 21 and transferred to server 23 from computer 20 through the Transfer( ) operation.
  • server 23 performs the getTransferData( ) operation included in data transfer session object 25 to retrieve data from printer 21 .
  • the data is transferred from printer 21 to server 23 through data transfer session object 25 at step 68 .
  • one or more of computer 20 , printer 21 or server 23 may access and perform the abort( ) operation, fail( ) operation or the complete( ) operation described above and included in the data transfer session object 25 .
  • one or more of computer 20 , printer 21 or server 23 may be held responsible for renewing the leased data transfer session.
  • one or more of computer 20 , printer 21 or server 23 may register as a listener with each other by invoking the notification interface (not illustrated) associated with computer 20 , printer 21 or server 23 to receive event notifications, as described above.
  • computer 20 may invoke the notification interface associated with printer 21 and/or server 22 to register as a listener to monitor the progress of the data transfer.
  • the participation of computer 20 is not required. Whether or not computer 20 continues to participate in the data transfer session depends upon several factors, such as whether computer 20 would like to receive event notifications associated with the data transfer sessions and whether computer 20 is responsible for renewing the leased data transfer session, as described above.
  • any one of computer 20 , printer 21 or server 23 may serve as data sources and data sinks between each other employing one or more of the above-described embodiments.
  • computer 20 may initiate a data transfer where server 23 serves as a data source and thus transmits data to printer 21 via data object transfer session 25 following the same steps as described above with respect to printer 21 transmitting data to server 23 .
  • components 20 - 24 While devices such as computer 20 , printer 21 , PDA 22 , server 23 and facsimile machine 24 (i.e., components 20 - 24 ) have been used as examples in one or more embodiments described above, a number of other systems may be used as components 20 - 24 such as software services, applications or portions thereof including language translation services, data format converters, e-mail applications, calendar applications, or a spell checking routine executing within a word processing application. For instance, a word processor could make currently selected text available as a data source component so that it could be sent to PDA 22 , which is a data sink component.

Abstract

Methods and systems for enabling arbitrary components to transfer data without having a priori knowledge of each other. The data transfer system includes a set of arbitrary components associated with one or more universal data transfer interfaces. The one or more universal data transfer interfaces comprise a data source interface and a data sink interface. The universal interfaces can be provided to and performed by each other to enable the components to transfer data between each other despite utilizing different communication protocols or understanding different data types. Further, the components may directly request and directly receive data from other components or may initiate transmitting data directly to other components. Moreover, a component may initiate a data transfer session between one or more other components to enable the components to transfer data between each other.

Description

    FIELD OF THE INVENTION
  • This invention relates generally to communication systems and methods and, more particularly, to a system and method for enabling arbitrary components to transfer data between each other using one or more universal data transfer interfaces employing mobile code. [0001]
  • BACKGROUND OF THE INVENTION
  • In data communication environments, such as a distributed network, many different vendors provide a number of products for specific services. Heretofore, a predetermined set of domain specific protocols has been required to be specified to enable arbitrary components in the environment to communicate with each other, assuming the components were transmitting or receiving data, hereinafter referred to as (“transferring data”). For example, a device manufactured by one vendor would have difficulty communicating with a device manufactured by another vendor without using the predetermined set of protocols mentioned above. The problem of different vendors requiring different predetermined protocols has been partially dealt with by adopting existing protocol standards. However, there are different standards organizations and thus different protocol standards. [0002]
  • When arbitrary components such as computer applications or programs, data, memory, file directories, individual files, printer devices, cellular telephones, facsimile machines, copier machines, scanner devices, desk-top computers, lap-top computers, personal digital assistant (“PDA”) systems, or any other device, for example, attempt to communicate without having a priori knowledge of each other, particular domain-specific protocols, such as the file system domain (e.g., NFS and CIFS) or the printer domain (e.g., IPP and LPR), must be known a priori by both parties to successfully communicate. An arbitrary component, such as a PDA attempting to communicate with a file system, or a printer device attempting to do the same, must be explicitly programmed to understand one or more of the standardized protocols mentioned above. An example includes a computer device or application having to be programmed to understand a printer device by installing a domain-specific printer driver. If the device or application is programmed to understand how to communicate and use a printer device, generically, the driver will only enable the device or application to access a particular type of printer device and not the universe of all printer devices. Thus, when new and unknown components enter the equation, the application must be reprogrammed to understand the new standardized protocols used to communicate with the new components. Referring to the above computer and printer device example, if a new type of printer were introduced, the computer device would have to be re-programmed to be able to transfer data with the new printer device by installing a printer driver specific to the new printer device. Thus, each application must be explicitly written to use a particular set of standardized protocols a priori to communicating with the components associated with the protocols. [0003]
  • In a system such as Jini™, developed by Sun Microsystems of Palo Alto, Calif. and described in “A collection of Jini™ Technology Helper Utilities and Services Specifications,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-214, 2000; and “Jini™ Technology Core Platform Specification,” Palo Alto, Calif., Sun Microsystems, Inc., pp. [0004] 1-126, 2000, all of which are hereby incorporated by reference in their entirety, which uses domain-specific interfaces, in order for a component such as a PDA system to communicate with another component such as a printer, the PDA system must contain a priori knowledge of the semantics of the printer's programmatic interfaces. In other words, a component that knows how to print still might not know how to transfer data between a file system, a scanner device or a network translation service until it is explicitly programmed to know how to communicate with the interface for the particular components.
  • SUMMARY OF THE INVENTION
  • A system for enabling components to transfer data between each other in accordance with the present invention includes a first component having a universal data transfer interface and a second component invoking the universal data transfer interface to use a data transfer session object to transfer data between the first component and at least one of the components. [0005]
  • A system for enabling components to transfer data between each other in accordance with the present invention includes a first component having a first universal data transfer interface, a second component having a second universal data transfer interface, and a third component invoking the first universal data transfer interface and the second universal data transfer interface to use a data transfer session object to transfer data between the first component and the second component. [0006]
  • A method and a program storage device readable by a machine and tangibly embodying a program of instructions executable by the machine for enabling components to transfer data between each other in accordance with the present invention include invoking a universal data transfer interface to obtain a data transfer session object, and using the data transfer session object to transfer data between a first component and at least one of the components. [0007]
  • A method and a program storage device readable by a machine and tangibly embodying a program of instructions executable by the machine for enabling components to transfer data between each other in accordance with the present invention include invoking a first universal data transfer interface and a second universal data transfer interface, obtaining a data transfer session object from one of the invoked first universal data transfer interface or the second universal data transfer interface, and using the data transfer session object to transfer data between a first component and a second component. [0008]
  • The present invention allows components using the same or different communications protocols and/or data types to transfer data between each other without having a priori knowledge of any domain-specific interfaces, protocols or data formats. In addition, the invention enables components to initiate data transfer sessions between other components.[0009]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a diagram of a system for enabling arbitrary components to transfer data between each other in accordance with one embodiment; [0010]
  • FIG. 2 is a block diagram of an exemplary arbitrary component utilized in the system for enabling arbitrary components to transfer data between each other; [0011]
  • FIG. 3 is a diagram of a system for enabling one arbitrary component to receive data from another arbitrary component in accordance with another embodiment; [0012]
  • FIG. 4 is a flow chart of a process for receiving data from another arbitrary component; [0013]
  • FIG. 5 is a diagram of a system for enabling one arbitrary component to transmit data to another arbitrary component in accordance with another embodiment; [0014]
  • FIG. 6 is a flow chart of a process for transmitting data to another arbitrary component; [0015]
  • FIG. 7 is a block diagram of a system where one arbitrary component enables two other arbitrary components to transfer data between each other in accordance with another embodiment; and [0016]
  • FIG. 8 is a flow chart of a process where an arbitrary component enables other arbitrary components to transfer data between each other. [0017]
  • DETAILED DESCRIPTION OF THE INVENTION
  • A [0018] system 10 for enabling arbitrary components to transfer data between each other in accordance with one embodiment of the present invention is shown in FIG. 1. In this particular embodiment, system 10 includes computer 20, printer 21, personal digital assistant (“PDA”) 22, server 23 and facsimile machine 24 (“components 20-24”). A method in accordance with one embodiment includes computer 20 obtaining one of the universal data transfer interfaces (i.e., the data source interface or the data sink interface) associated with one or more of components 21-24, and invoking the one or more obtained universal data transfer interfaces to transfer data between components 20-24. The present invention allows components 20-24 using the same or different communication protocols and/or data types to transfer data between themselves without having a priori knowledge of any domain-specific interfaces, protocols or data formats. The present invention also enables components 20-24 to initiate data transfer sessions between other components 20-24.
  • Referring more specifically to FIG. 1, [0019] computer 20 is operatively coupled to each of the components 21-24 in this particular embodiment, although other coupling arrangements or configurations can be used as well as greater or lesser numbers of components. For example, system 10 could comprise one or more of the components 21-24 directly coupled to one or more of the other components 21-24 (e.g., a peer-to-peer system) or system 10 could comprise components 20 and 21, which are coupled together.
  • A conventional dial-up communication system through private branch exchanges (“PBX”) and using public switched telephone lines and line based telephone communication protocols may be used by components [0020] 20-24 to communicate with each other. Although one type of communication system and protocol is shown, a variety of different types of communication systems and/or protocols may be used. For example, communication systems or network architectures, such as local area networks (“LAN”), wide area networks (“WAN”) and cellular or satellite communications network systems that utilize signals, such as satellite signals, radio waves, microwaves and/or infrared signals, can be used. Additionally, a variety of communication protocols for transferring data, such as xDSL, ISDN, TCP/IP or protocols defined by the RFC and OSI organizations can also be used. The type of protocol used will depend upon the type of communication system being used by a particular component, the type of component (e.g., a printer device or a scanner device) and/or the type of network environment the component is operating in (e.g., the UNIX operating environment). Components 20-24 may use one or more communications protocols. Moreover, the arrows in FIG. 1 depict the flow of communications between components 20-24.
  • Referring to FIG. 2, in this embodiment, [0021] computer 20 comprises a central processing unit (“CPU”) 30, memory 32 and I/O unit 34, which are coupled together by a bus 36, although computer 20 may comprise any type of device or system that can store, process and execute instructions for performing one or more methods of the present invention. By way of example only, computer 20 may also comprise a scanner, cellular telephone, display device, video input/output device, audio input/output device, remote control device or an appliance. Computer 20 could also comprise any type of device with circuitry that is hard-wired to execute instructions for performing one or more methods of the present invention. Computer 20 executes instructions for an operating system environment it is operating in, such as the UNIX® environment, as described in “Advanced Programming in the UNIX® Environment,” W. Richard Stevens, Addison-Wesley Publishing Company, 1974, which is hereby incorporated by reference in its entirety. In this embodiment, computer 20 does not use the same communication protocol as any of the other components 21-24, but in other embodiments computer 20 does use the same communication protocol as any of the other components 21-24. By way of example only, computer 20 may be operating in the UNIX® environment using a first type of communication protocol to transfer data, while printer 21 may be operating in a Microsoft Windows® environment, but using a second type of communication protocol.
  • [0022] CPU 30 may comprise a processor, such as an Intel Pentium III processor. The CPU 30 executes at least one program of stored instructions for a method for enabling arbitrary components to transfer data between each other in accordance with the present invention as described and illustrated herein. CPU 30 may also execute instructions for other tasks, including network services, such as providing data, memory, file directories, individual files, word processing applications, accounting applications or engineering applications. As a result, when one of these applications is executed, the instructions for the task, such as for creating a spreadsheet, as well as the instructions for performing one or more of the methods of the present invention are carried out by the CPU 30 in computer 20. The instructions may be expressed as executable programs written in a number of computer programming languages, such as BASIC, Pascal, C, C++, C#, Java, Perl, COBOL, FORTRAN, assembly language, machine code language, or any computer code or language that can be understood and performed by the CPU 30.
  • [0023] Memory 32 may comprise any type of fixed or portable memory device accessible by the CPU 30, such as hard-disks, floppy-disks, compact disks (“CD”), digital video disks, magnetic tape, optical disk, ferroelectric memory, read only memory, random access memory, electrically erasable programmable read only memory, flash memory, erasable programmable read only memory, static random access memory, dynamic random access memory, ferromagnetic memory, charge coupled devices, smart cards, or any other type of computer-readable mediums. Memory 32 stores instructions 38 for a method of enabling arbitrary components to transfer data between each other in accordance with one embodiment of the present invention for execution by CPU 30, although some or all of these instructions can be stored elsewhere. One or more sets of universal interfaces or data objects may be stored in memory 32 so they can be retrieved as needed by the CPU 30 during operation of the present invention as will be described in further detail herein. Although in this embodiment the CPU 30 and memory 32 are shown in the same physical location, they may be located at different physical locations, such as in server 23 shown in FIG. 1.
  • [0024] Computer 20 may communicate with components 21-24 using I/O unit 34. In this embodiment, I/O unit 34 may comprise a router such as any type of Ethernet based device having sufficient ports to operatively couple computer 20 to components 21-24.
  • Referring back to FIG. 1, [0025] printer 21 comprises a conventional printing device capable of rendering graphical representations on a printing medium, for example. Since devices such as printer 21 are well known in the art, the specific elements, their arrangement within printer 21 and operation will not be described in detail here.
  • [0026] PDA 22 comprises a conventional hand held device that may perform such functions as telephony, facsimile transmissions or networking. Since devices such as PDA 22 are well known in the art, the specific elements, their arrangement within PDA 22 and operation will not be described in detail here.
  • [0027] Server 23 comprises a conventional computer system having one or more CPU's, memory, I/O units and one or more storage mediums, which are coupled together by a bus and used by server 23 to store and process instructions in accordance with one or more embodiments of the present invention as described further herein. Since devices such as server 23 are well known in the art, the specific elements, their arrangement within server 23 and operation will not be described in detail here.
  • [0028] Facsimile machine 24 comprises a conventional facsimile device that can send and receive pictures or text over a telephone line or network. Since devices such as facsimile machine 24 are well known in the art, the specific elements, their arrangement within facsimile machine 24 and operation will not be described in detail here.
  • Referring to FIG. 3, [0029] computer 20 is coupled to PDA 22 as described above in connection with FIG. 1. PDA 22 has stored in a memory, or otherwise has access to by accessing server 23, for example, which will hereinafter be referred to as being “associated with,” a set of universal interfaces 22 a comprising a data source interface, a contextual interface, a notification interface and a user interface. The particular number and/or combination of interfaces may vary and will depend upon the particular type of device PDA 22 is, and the capabilities and/or services desired or provided by it. Also, PDA 22, and hence the set of universal interfaces 22 a, may be updated at any time to add, delete or modify interfaces. Further, computer 20 is programmed to access the interfaces associated with PDA 22. Likewise, PDA 22 could access one or more interfaces (not illustrated) associated with computer 20.
  • [0030] Computer 20 may access the set of universal interfaces 22 a through data object 22 b to effect different types of communications as described herein. Each of the interfaces in the set of universal interfaces 22 a comprise instructions, sets of operations and/or other data that can be understood and performed by computer 20 to enable it to communicate and transfer data (i.e., transmitting or receiving data) with PDA 22, exchange contextual information with PDA 22, provide computer 20 with event notifications for PDA 22, or enable computer 20 to receive user interfaces to allow users of computer 20 to access and/or manipulate PDA 22. In general, each interface in the set of universal interface 22 a is not domain-specific with respect to PDA 22.
  • In particular, the data source interface includes several operations such as a getSourceDataFlavor( ) operation and a beginTransferSession( ) operation. Further, the data source interface includes instructions and data that can be performed by [0031] computer 20 to establish a data transfer session to enable computer 20 to receive data from PDA 22. The getSourceDataFlavor( ) operation includes instructions and data that may be performed by computer 20 for determining the types of data PDA 22 can transmit. In this particular embodiment, computer 20 performs the getSourceDataFlavor( ) operation that returns a list of one or more data types supported by PDA 22. Moreover, the data types in this embodiment are typically MIME data types. For example, after performing the above-mentioned operations, computer 20 may determine that PDA 22 supports data in a “JPEG” format. The beginTransferSession( ) operation includes instructions and data that may be performed by computer 20 to request PDA 22 to establish a data transfer session to receive data by returning a data transfer session object 22 c to computer 20 through data object 22 b. Moreover, the beginTransferSession( ) operation may be passed parameters when invoked such as a context parameter, an initial lease duration parameter and a data flavor parameter. In this embodiment, computer 20 passes a context parameter to the beginTransferSession( ) operation when invoking it to inform PDA 22 of its identity for a variety of reasons, such as for identifying computer 20 to PDA 22, identifying a user at computer 20 to PDA 22, identifying the location of computer 20 on a network to PDA 22 or for security purposes. PDA 22 may decide whether to transmit data to computer 20 based upon the identity information provided in the context parameter. Further, data transfer sessions are leased and would thus need to be renewed periodically by computer 20 at intervals of time corresponding to a value specified in the initial lease duration parameter passed to the beginTransferSession( ) operation to keep the data transfer session active, although in other embodiments the sessions need not be leased. Where sessions are leased, if computer 20 fails to renew the lease PDA 22 will stop transmitting data to computer 20 under the assumption that computer 20 has failed to renew the lease because it has either crashed or has otherwise become unreachable. In addition, if PDA 22 supports one or more types of data, as determined by performing the getSourceDataFlavor( ) operation, a data flavor parameter may be passed into the beginTransferSession( ) operation. Computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event computer 20 and PDA 22 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer. In this embodiment, computer 20 may determine a preferred data type using a number of methods such as enabling users at computer 20 to indicate preferred data types, randomly selecting one of the compatible data types between computer 20 and PDA 22 or selecting the data type that will be most efficient for the particular data being transferred.
  • The contextual interface comprises a getcontexto operation that includes instructions and data that can be performed by [0032] computer 20 for retrieving contextual information from PDA 22. In this embodiment, the contextual information is stored in a memory at PDA 22 as a multi-valued data structure that resembles a hash table, although the contextual information can be stored in any other format. Also in this embodiment, the contextual information includes information about PDA 22 such as what type of device it is, its operating status, identity, location, administrative domain, or any other type of environment data. In another embodiment, the contextual information may be stored at another physical location such as server 23.
  • The notification interface includes a register( ) operation, which may be passed one or more parameters and performed by [0033] computer 20 to enable it to receive asynchronous notifications about events generated by PDA 22, although it may receive synchronous notifications as well. Computer 20 performs the registers operation, passing to it a context parameter, a component parameter and an initial lease duration parameter. The context parameter provides PDA 22 with the identity of computer 20 for a number of reasons, such as enabling PDA 22 to decide whether it would desire sending notifications to computer 20 for security purposes or record keeping. The component parameter identifies computer 20 as desiring to be notified of events occurring at PDA 22. Further, event registrations are leased and must be renewed periodically by computer 20 at intervals of time corresponding to the value specified in the initial lease duration parameter to keep the event registration active. If computer 20 fails to renew the lease, the notification interface includes instructions for relieving PDA 22 of its obligation to provide computer 20 with notifications about generated events since it will assume that computer 20 has failed to renew the lease because it has either crashed or has otherwise become unreachable. Once computer 20 has registered itself with PDA 22 by performing the register( ) operation, if a condition occurs in PDA 22 that should cause it to notify computer 20 according to the instructions provided in the notification interface and associated operations, PDA 22 will send an event notification object to computer 20. Computer 20 may then generate a user window, as described further herein below, to display the event information to a user. For example, if PDA 22 instead was a printer device and computer 20 instead was a word processing application, PDA 22 would be able to provide computer 20 with an event notification in the case where paper in the printer device jammed. Moreover, in this example, computer 20 could display the event notification (i.e., paper jam) to the user using a graphical user interface (“GUI”).
  • The user interface comprises a getUI( ), getState( ) and setState( ) operation that includes instructions and data that can be performed by [0034] computer 20 for retrieving or generating a user window specific to PDA 22 to provide users of computer 20 with so they can access and/or manipulate PDA 22 to take advantage of additional functionality of PDA 22. In this embodiment, the getUI( ) operation can be passed parameters when invoked by computer 20 to indicate which type of user window the user would like generated, as described in further detail herein. The getuI( ) operation returns to computer 20, from PDA 22, a user window and/or instructions for generating or retrieving a user window, which may be instantiated by computer 20 to display the user window to users, for example. The getState( ) operation includes instructions and data for requesting that a state token object be returned to computer 20 from PDA 22. The state token object may be an opaque object with respect to computer 20, which is particular to PDA 22 and further may encapsulate the current state (e.g., device settings or configuration) of PDA 22, although the state token object may be transparent with respect to computer 20 in a case where computer 20 is able to understand the state token object of PDA 22. Further, PDA 22 may use different types of state token objects depending upon the particular type of device it is (e.g., a printer device or word processing application). Still further, PDA 22 may encode its respective state token objects in various ways, such as pointers or URLs pointing to particular configurations. Alternatively, the state token objects may include a representation of the current state of PDA 22. Additionally, the setstate( ) operation includes instructions and data that may be performed by computer 20 for generating the user window using the configuration data included in the state token object. Computer 20 may pass the state token object as a parameter to the setState( ) operation when it is invoked, which can be used by PDA 22 to return instructions and data that can be performed by computer 20 for retrieving or generating the user window having the stored configuration included in the state token object. The setState( ) operation may also be invoked by computer 20 to reset the state of PDA 22 without having to recreate the user window for the user.
  • Each of the above-described interfaces and associated operations therein, as well as any others that may be subsequently described herein, comprise mobile code. Mobile code is executable data that can be transmitted to [0035] computer 20 where it is executed. For example, Java is an implementation of executable content (i.e., mobile code) that is widely used on the Internet. Users can download the mobile code from the Internet, for example, and locally run a program written in a truly common programming language. In this embodiment, the mobile code is object oriented mobile code, which is a programming methodology that is well known in the programming arts, where data types may be defined along with associated procedures or sets of instructions, the data types in this context often referred to as classes. Thus, a set of procedures or instructions may be associated with one or more data types. Moreover, the same name or identifier can be assigned to identify a procedure or a set of instructions that perform corresponding instructions depending upon the particular data types associated therewith, often referred to as polymorphism. Thus, for exemplary purposes only, a draw procedure could be performed to draw circles or rectangles depending upon the type of data provided, or passed, to the procedure when it is invoked. Further in this example, if a circle data type defines a radius coordinate, for example, and a draw procedure is invoked and the circle data type is passed to the draw procedure, the draw procedure, inheriting any other data types associated with the draw procedure, can use the data provided thereto to perform the appropriate procedure or sets of instructions to draw a circle. In this embodiment, when the set of universal interfaces 22 a is provided to computer 20, the procedures, sets of instructions and other data associated with the particular interface become available to computer 20 to access and perform, as will be described further herein. Moreover, variables, parameters and data may be passed or provided to the universal interfaces that will be understood and utilized accordingly by computer 20, depending upon the particular type of communication desired. Still further, the interfaces may comprise sets of instructions or references to other interfaces, wherein computer 20 could utilize the data or perform the instructions accordingly.
  • [0036] Computer 20 may also directly access each of the interfaces included in the set of universal interfaces 22 a without needing to obtain data object 22 b to effect the different types of communications described herein. Moreover, each of the interfaces in the set of universal interfaces 22 a would comprise the same instructions, sets of operations and/or other data that could be understood and performed by computer 20 to enable it to communicate and transfer data with PDA 22 as well as the other functions described above. Therefore, mobile code may not be required in this example, although it could be used as necessary such as where data is being transferred.
  • In this embodiment, data object [0037] 22 b is received from PDA 22 and stored in computer 20, although the data object 22 b could be stored elsewhere, such as server 23. The set of universal interfaces 22 a is accessible to computer 20 through the data object 22 b. More specifically, data object 22 b supports the various operations defined by the interfaces associated with PDA 22, which are assumed to be known and understood by computer 20. The data object 22 b comprises instructions (i.e., computer executable code) and/or data that provide particular implementations of the one or more interfaces associated with the PDA 22 from which the data object 22 b is associated with. For example, data object 22 b as provided by PDA 22 to computer 20 would provide a custom implementation of the data source interface that would be specialized to communicate with PDA 22 using whichever protocols and/or data formats have been decided upon by the developer of PDA 22.
  • In this embodiment, the data [0038] transfer session object 22 c includes a getTransferData( ) operation, a getDataSource( ) operation, an abort( ) operation, a fail( ) operation, a completed( ) operation, the register( ) operation associated with the notification interface described above, a getLease( ) operation, a getViewer( ) operation, a getEditor operation, a getPrinter( ) operation, as well as any other instructions needed to enable computer 20 to receive data from PDA 22, including protocols for video or file transfer, for example, which may depend upon the type of data being received. Data transfer session object 22 c includes the above-mentioned operations and instructions that are particular to PDA 22, but may be performed by computer 20 to receive data. In an embodiment where computer 20 (i.e., a data sink component) receives data from PDA 22 (i.e., a data source component), for example, computer 20 invokes the getDataTransfer( ) operation to actually retrieve the data from PDA 22. Further, computer 20 may invoke the getDataSource( ) operation to determine the identity and other attributes of PDA 22. Computer 20 may also invoke the getDataSource( ) operation to determine whether it should modify its behavior during data transfers or whether it should even allow certain data transfers to occur.
  • In this embodiment, [0039] computer 20 does not need to know details with respect to how to receive and understand the data sent from the PDA 22 through the data transfer session object 22 c. In particular, the instructions and various operations included within data transfer session object 22 c include information regarding the specific protocols, mediums and types of data that are particular to PDA 22, which may be executed by computer 20 to be able to receive and understand data transferred from PDA 22, even though PDA 22 may utilize different protocols, mediums or types of data. Furthermore, data transfer session object 22 c includes instructions for enabling computer 20 to negotiate with PDA 22 during the transfer of data to select a communications protocol or medium to use to transfer data between each other based upon the type of data being transferred. The instructions may also enable computer 20 and PDA 22 to negotiate with each other for using different protocols for the data transfer session based upon the type of data being transferred. Moreover, the instructions may enable computer 20 to modify the format or the content of data being transferred through the data transfer session object 22 c to convert the data as necessary from a first data transfer protocol associated with computer 20 to a second data transfer protocol associated with PDA 22. For example, if PDA 22 is transferring streaming video to computer 20, then it may be more efficient for PDA 22 to transfer the data using compression or progressive encodings. Computer 20 could perform the instructions and operations included within data transfer session object 22 c so that the data transfer session object 22 c negotiates with computer 20 to decide upon the particular protocol to use for the data transfer session, and in turn provide computer 20, through data transfer session object 22 c, with the operations, instructions and data necessary to enable computer 20 to retrieve and understand the data transferred through the data transfer session object 22 c. Further, computer 20 and PDA 22 may negotiate on a preferred physical transport medium, if one is available. For instance, if a shared FireWire, IR or a Bluetooth connection is found to link computer 20 and PDA 22 together it could be used instead of an Ethernet connection as the physical transport medium to transfer the data. The instructions may also include operations for scaling down data rates over slow data transmission links, or may include operations for increasing redundancy in the face of errors during a data transfer session.
  • Moreover, data [0040] transfer session object 22 c may include instructions that may be performed by computer 20 to enable it to view the type of data being transferred through data transfer session object 22 c. For instance, where computer 20 is not programmed or configured to display “JPEG” image files, or streaming video data transfers transmitted from PDA 22, for example, computer 20 may perform the instructions included in data transfer session object 22 c to view, on a display device associated with computer 20, for example, the data being transferred. In particular, data transfer session object 22 c may include a getViewer( ) operation that returns a viewer object when the operation is invoked by computer 20. The viewer object is specific to the particular type of data that is understood and used by PDA 22. Further, the viewer object may include the same instructions described above for providing computer 20 with a user interface except that the instructions, when performed by computer 20, enable computer 20 to view the data being transferred. The viewer object may also include instructions for enabling computer 20 to view the particular data type associated with PDA 22 and being transferred despite computer 20 not being previously programmed to view such types of data. In addition, the getViewer( ) operation may be passed parameters, as described above with respect to the user interface, for enabling computer 20 to specify the type of user window (i.e., graphical or speech) computer 20 would like to display. In this embodiment, the getViewer( ) operation may be stored in PDA 22 and accessible to computer 20 through data object 22 b. Alternatively or in addition, the getViewer( ) operation may be stored in a central repository, such as in server 23 (FIG. 1). In this example, the server 23 may store one or more getViewer( ) operations, where each operation includes instructions for enabling computer 20 to view a particular type of data. It should be appreciated that the terms “view” or “display” in this embodiment may encompass other forms of output, such as where the instructions in data transfer session object 22 c enable computer 20 to play an audio file in a particular format through an audio output device such as a speaker. Furthermore, data transfer session object 22 c may include additional operations, such as a getEditor( ) operation and a getPrinter( ) operation, which have the same instructions as the getViewer( ) operation except the getEditor( ) operation and the getPrinter( ) operation include instructions for enabling computer 20 to edit or print, respectively, data being transferred, regardless of whether computer 20 has been programmed to understand the particular type of data associated with PDA 22. Thus, in this embodiment computer 20 would not need to understand all of the types of data formats it may encounter in a data transfer session because the instructions to understand such data may be included in data transfer session object 22 c. It should be noted that computer 20 at least has the capability of executing the various instructions and operations included within data transfer session object 22 c.
  • In this embodiment, the abort( ) operation includes instructions that enable [0041] computer 20 to terminate the data transfer session with PDA 22. Further, computer 20 may indicate to PDA 22 that a data transfer session has failed or has been completed by performing the fail( ) operation or the complete( ) operation, respectively. In the event that a data transfer session between computer 20 and PDA 22 has failed, completed, or aborted, listeners at components 20-24 who expressed an interest in the status of the data transfer session by registering will be notified of the event through the register( ) operation. A signaling protocol enables computer 20 to indicate when computer 20 has completed using the data transfer session object 21 c in the case where PDA 22 cannot automatically determine when computer 20 is finished such as where the data transfer session has an indeterminate duration (e.g., streaming video). The getLease( ) operation enables computer 20 to renew the lease according to the initial lease duration parameter to ensure the data transfer session remains active.
  • Referring to FIG. 4 at [0042] step 40, computer 20 performs a discovery process to determine whether computer 20 and PDA 22 can transfer data between each other. In this embodiment, computer 20 discovers PDA 22 using a variety of discovery systems such as the Bluetooth™ Service Location Protocol (“SLP”) developed by Bluetooth SIG, inc., described in “Specification of the Bluetooth System,” Version 1.1 core, Bluetooth Consortium 2001, the Universal Description, Discovery, and Integration Protocol (“UDDI”), developed by the Ariba, IBM and Microsoft Corps., described in “UDDI Technical Whitepaper,” Universal Description, Discovery, and Integration Consortium, pp. 1-12, 2000; “Universal Description, Discovery and Integration Data Structure Reference V 1.0,” Ariba, Inc., International Business Machines Corporation and Microsoft Corporation, pp. 1-31, 2000; “Universal Description, Discovery and Integration Programmer's API 1.0,” Ariba, Inc. and International Business Machines Corporation and Microsoft Corporation, pp. 1-67, 2000; and “Universal Description, Discovery and Integration Technical White Paper,” Ariba, Inc., International Business Machines Corporation and Microsoft Corporation, pp. 112, 2000, the various Jini™ system discovery protocols or simple lookup in a name server, for example, all of which are hereby incorporated by reference in their entirety. Discovered PDA 22 returns data object 22 b to computer 20. Computer 20 may introspect the received data object 22 b to determine which one or more interfaces are associated with PDA 22. Thus, upon computer 20 performing the above-described discovery and receiving data object 22 b from PDA 22, computer 20 introspects the received data object 22 b to determine which universal interfaces PDA 22 is associated with. Computer 20 determines that PDA 22 is at least associated with a data source interface, and thus PDA 22 can provide it with data. Computer 20 invokes the data source interface associated with PDA 22 and included in data object 22 b, which includes instructions that instruct computer 20 to perform the getSourceDataFlavors( ) operation included in data object 22 b. The getSourceDataFlavors( ) operation in turn includes instructions for accessing PDA 22 to provide computer 20 with the types of data supported by PDA 22.
  • Next, at [0043] step 42 computer 20 performs the beginTransferSession( ) operation included in the data source interface. In addition, the beginTransferSession( ) operation when invoked may be passed the context parameter, the initial lease duration parameter and the data flavor parameter. PDA 22 returns the data transfer session object 22 c to computer 20. Computer 20 may determine a preferred data type using the methods described above and provide a preferred data type value to receive the data in to the data flavor parameter, otherwise computer 20 will receive the data in whichever data format it is provided in by PDA 22. Computer 20 may receive data from PDA 22 by way of the data transfer session object 22 c.
  • Next, at [0044] step 44 data transfer session object 22 c includes the getTransferData( ) operation and the other operations and instructions described above that may be performed by computer 20 to retrieve data from PDA 22. The data is transferred from PDA 22 to computer 20 through data transfer session object 21 c at step 46. Still further, computer 20 maybe able to view data types that it is not natively programmed to understand. When computer 20 performs the beginTransferSession( ) operation, PDA 22 may return the instructions, operations or data directly to computer 20 to enable it to understand the data being transferred from PDA 22.
  • Referring to FIG. 5, [0045] computer 20 is coupled to facsimile machine 24 as described above in connection with FIG. 1. Facsimile machine 24 has stored in a memory, or otherwise has access to by accessing server 23, for example, a set of universal interfaces 24 a comprising a data sink interface, which will be described in further detail herein. However, facsimile machine 24 may be associated with any number of interfaces and in any combination.
  • [0046] Facsimile machine 24 may access the set of universal interfaces 24 a through data object 24 b to effect different types of communications. Each of the interfaces in the set of universal interfaces 24 a comprise instructions, sets of operations and/or other data that can be understood and performed by computer 20 to enable it to communicate and transfer data with facsimile machine 24. Except for the data sink interface, each of the interfaces mentioned above are the same as those described above in connection with PDA 22, but each interface includes instructions that are specific to the particular device they are associated with (i.e., facsimile machine 24).
  • In particular, the data sink interface includes several operations such as a getSinkDataFlavor( ) and a Transfer( ) operation. Further, the data sink interface includes instructions and data that can be performed by [0047] computer 20 for establishing a data transfer session to enable computer 20 to transmit data to facsimile machine 24. In particular, the getSinkDataFlavor( ) operation includes instructions and data that may be performed by computer 20 for determining which types of data facsimile machine 24 can support. In this particular embodiment, computer 20 may perform the getSinkDataFlavor( ) operation which returns a list of one or more data types supported by facsimile machine 24. Moreover, the data types in this embodiment are typically MIME data types. The Transfer( ) operation includes instructions and data that may be performed by computer 20 to request facsimile machine 24 to establish a data transfer session so computer 20 can begin transmitting data to facsimile machine 24. The Transfer( ) operation may be passed parameters in this embodiment when invoked such as data transfer session object 20 c associated with computer 20, a context parameter and a data flavor parameter. In particular, computer 20 passes the data transfer session object 20 c into the Transfer( ) operation to make it available to facsimile machine 24 so it may perform the instructions therein to actually receive the data from computer 20. In this embodiment, the data transfer session object 20 c associated with computer 20 includes the same types of instructions, data and operations as data transfer session object 22 c described above, except that the instructions, data and operations included therein are particular to computer 20. Computer 20 passes a context parameter into the Transfer( ) operation when invoking it to inform facsimile machine 24 of its identity for a variety of reasons, such as for security purposes. Facsimile machine 24 may decide whether to allow computer 20 to transmit data to it based upon the identity information provided in the context parameter. In addition, if facsimile machine 24 supports one or more types of data, as determined by performing the getSinkDataFlavor ( ) operation, a data flavor parameter may be passed into the Transfer( ) operation to inform facsimile machine 24 the type of data that will be transmitted by computer 20. Moreover, computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event computer 20 and facsimile machine 24 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer. In this embodiment, computer 20 may determine a preferred data type using a number of methods such as enabling users at computer 20 to indicate preferred data types, randomly selecting one of the compatible data types between computer 20 and facsimile machine 24 or selecting the data type that will be most efficient for the particular data being transferred. Additionally, where computer 20 and facsimile machine 24 support a finite number of compatible data types with respect to each other, computer 20 may select the compatible data type to transmit the data to facsimile machine 24.
  • Referring to FIG. 6, at [0048] step 50 computer 20 performs the discovery process and determines by introspecting data object 24 b, as described above in connection with one or more embodiments, that computer 20 and facsimile machine 24 can transfer data between each other because facsimile machine 24 is at least associated with a data sink interface. Computer 20 invokes the data sink interface associated with facsimile machine 24 and included in data object 24 b, which includes instructions that instruct computer 20 to perform the getSinkDataFlavor( ) operation. The getSinkDataFlavor( ) operation in turn includes instructions for accessing facsimile machine 24 to provide computer 20 with the types of data supported by facsimile machine 24, as described above.
  • Next, at [0049] step 52 computer 20 performs the Transfer( ) operation included in the data sink interface. In addition, computer 20 passes into the Transfer( ) operation data object 20 c, the context parameter and the data flavor parameter when invoked as described above.
  • Next, at [0050] step 54 facsimile machine 24 performs the instructions included within data transfer session object 20 c as provided to it through the Transfer( ) operation to receive data from computer 20. The data is transferred from computer 20 to facsimile machine 24 by way of data transfer session object 20 c at step 56.
  • Referring to FIG. 7, [0051] computer 20, printer 21 and server 23 are coupled to each other as described above in connection with FIG. 1. In this embodiment, printer 21 is associated with a set of universal interfaces 21 a comprising a data source interface, a data sink interface and a contextual interface. Server 23 is associated with a set of universal interfaces 23 a comprising a data source interface, a data sink interface and a contextual interface. Each of the interfaces mentioned above are the same as those described above in connection with FIGS. 3 and 5, except that each interface in this embodiment includes instructions that are specific to the particular device they are associated with (i.e., printer 21 or server 23). Moreover, the data transfer session object 25 associated with printer 21 includes the same instructions, data and operations as data transfer session objects 20 c and 22 c as described above, except that the instructions, data and operations included therein are particular to printer 21.
  • Referring to FIG. 8, at [0052] step 60 computer 20 performs the discovery process and determines by introspecting data objects 21 b and 23 b, as described above in connection with one or more embodiments, that printer 21 and server 23 can transfer data between each other because printer 21 is associated with a data source interface and server 23 is associated with a data sink interface. Computer 20 invokes the data source interface associated with printer 21 and performs the getSourceDataFlavors( ) operation included in data object 21 b to access printer 21 to determine the types of data supported by printer 21, as described above.
  • Next, at [0053] step 62 computer 20 performs the beginTransferSession( ) operation included in the data source interface. In addition, the beginTransferSession( ) operation may be passed the context parameter associated with computer 20 or server 23. For instance, computer 20 may invoke the contextual interface associated with server 23 and accessible through data object 23 b. In this example, computer 20 would receive the contextual information from server 23 but in turn provide it to printer 21 through the beginTransferSession( ) operation. This enables printer 21 to decide whether it would like to transfer the data with server 23. Alternatively, computer 20 may provide its own contextual information to printer 21 for the same reasons as well as the initial lease duration parameter when invoked as described above. Computer 20 invokes the data sink interface associated with server 23 and included in data object 23 b, which includes instructions that instruct computer 20 to perform the getSinkDataFlavor( ) operation. The getSinkDataFlavor( ) operation in turn includes instructions for accessing server 23 to provide computer 20 with the types of data supported by server 23. In addition, if server 23 supports one or more types of data, as determined by performing the getSinkDataFlavor( ) operation, a data flavor parameter may be passed into the Transfer( ) operation to inform server 23 the type of data that will be transmitted to it. Moreover, computer 20 may provide a preferred data type value to the data flavor parameter for a number of reasons, such as in the event printer 21 and server 23 support multiple, compatible data types where computer 20 specifies, using the parameter, a preferred data type for the data transfer between printer 21 and server 23. Printer 21 returns the data source object 25 to computer 20 through data object 21 b.
  • Next, at [0054] step 64 computer 20 performs the Transfer( ) operation included in the data sink interface associated with server 23 and included in data object 23 b. The Transfer( ) operation may also be passed parameters when invoked, including the data source object 25 received by computer 20 from printer 21, a context parameter and/or the data flavor parameter associated with printer 21. Computer 20 provides to server 23 the context parameter associated with computer 20 and/or printer 21 so that server 23 may decide whether it would like to participate in the data transfer for a number of reasons, such as for security purposes. Computer 20 is able to provide server 23 with its own contextual information by performing its own instructions to obtain its contextual information and passing the information into the Transfer( ) operation via the context parameter. Server 23 may receive data from printer 21 by way of the data transfer session object 25 received from computer 20 from printer 21 and transferred to server 23 from computer 20 through the Transfer( ) operation.
  • Next, at [0055] step 66 server 23 performs the getTransferData( ) operation included in data transfer session object 25 to retrieve data from printer 21. The data is transferred from printer 21 to server 23 through data transfer session object 25 at step 68. In this embodiment, one or more of computer 20, printer 21 or server 23 may access and perform the abort( ) operation, fail( ) operation or the complete( ) operation described above and included in the data transfer session object 25. Also, one or more of computer 20, printer 21 or server 23 may be held responsible for renewing the leased data transfer session. In another embodiment, one or more of computer 20, printer 21 or server 23 may register as a listener with each other by invoking the notification interface (not illustrated) associated with computer 20, printer 21 or server 23 to receive event notifications, as described above. In this example, computer 20 may invoke the notification interface associated with printer 21 and/or server 22 to register as a listener to monitor the progress of the data transfer. During the data transfer session between printer 21 and server 22 the participation of computer 20 is not required. Whether or not computer 20 continues to participate in the data transfer session depends upon several factors, such as whether computer 20 would like to receive event notifications associated with the data transfer sessions and whether computer 20 is responsible for renewing the leased data transfer session, as described above.
  • In another embodiment, any one of [0056] computer 20, printer 21 or server 23 may serve as data sources and data sinks between each other employing one or more of the above-described embodiments. For instance, computer 20 may initiate a data transfer where server 23 serves as a data source and thus transmits data to printer 21 via data object transfer session 25 following the same steps as described above with respect to printer 21 transmitting data to server 23.
  • While devices such as [0057] computer 20, printer 21, PDA 22, server 23 and facsimile machine 24 (i.e., components 20-24) have been used as examples in one or more embodiments described above, a number of other systems may be used as components 20-24 such as software services, applications or portions thereof including language translation services, data format converters, e-mail applications, calendar applications, or a spell checking routine executing within a word processing application. For instance, a word processor could make currently selected text available as a data source component so that it could be sent to PDA 22, which is a data sink component.
  • Other modifications of the present invention may occur to those skilled in the art subsequent to a review of the present application, and these modifications, including equivalents thereof, are intended to be included within the scope of the present invention. Further, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefor, is not intended to limit the claimed processes to any order except as may be specified in the claims. [0058]

Claims (33)

What is claimed is:
1. A system for enabling components to transfer data between each other, the system comprising:
a first component having a universal data transfer interface; and
a second component invoking the universal data transfer interface to use a data transfer session object to transfer data between the first component and at least one of the components.
2. The system as set forth in claim 1 wherein the at least one of the components comprises the second component or a third component.
3. The system as set forth in claim 1 wherein the at least one of the components sends the data transfer session object to the first component to be used by the first component for receiving data transmitted from the at least one of the components.
4. The system as set forth in claim 1 wherein the at least one of the components receives the data transfer session object from the first component to be used by the at least one of the components for receiving data transmitted from the first component.
5. The system as set forth in claim 1 wherein the universal data transfer interface and the data transfer session object have source-specific object-oriented mobile code that can be interpreted and performed by the first component or the at least one of the components to receive data.
6. The system as set forth in claim 1 wherein the data transfer session object comprises instructions for enabling the first component or the at least one of the components to negotiate with each other to transfer data, for selecting a communications protocol to use to transfer data between each other based upon a type of data being transferred or for selecting a transfer medium to use to transfer data based upon the type of data.
7. The system as set forth in claim 1 wherein data transfer ceases upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
8. A system for enabling components to transfer data between each other, the system comprising:
a first component having a first universal data transfer interface;
a second component having a second universal data transfer interface; and
a third component invoking the first universal data transfer interface and the second universal data transfer interface to use a data transfer session object to transfer data between the first component and the second component.
9. The system as set forth in claim 8 wherein the third component sends the data transfer session object to the first component to be used by the first component for receiving data transmitted from the second component.
10. The system as set forth in claim 8 wherein the third component sends the data transfer session object to the second component to be used by the second component for receiving data transmitted from the third component.
11. The system as set forth in claim 8 wherein data transfer ceases upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
12. A method for enabling components to transfer data between each other, the method comprising:
invoking a universal data transfer interface to obtain a data transfer session object; and
using the data transfer session object to transfer data between a first component and at least one of the components.
13. The method as set forth in claim 12 wherein the at least one of the components comprises the second component or a third component.
14. The method as set forth in claim 12 further comprising sending the data transfer session object to the first component to be used by the first component for receiving data transmitted from the at least one of the components.
15. The method as set forth in claim 12 further comprising receiving the data transfer session object from the first component to be used by the at least one of the components for receiving data transmitted from the first component.
16. The method as set forth in claim 12 wherein the universal data transfer interface and the data transfer session object have source-specific object-oriented mobile code that can be interpreted and performed by the first component or the at least one of the components to receive data.
17. The method as set forth in claim 12 wherein the data transfer session object comprises instructions for enabling the first component or the at least one of the components to negotiate with each other to transfer data, for selecting a communications protocol to use to transfer data between each other based upon a type of data being transferred or for selecting a transfer medium to use to transfer data based upon the type of data.
18. The method as set forth in claim 12 further comprising ceasing data transfer upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
19. A method for enabling components to transfer data between each other, the method comprising:
invoking a first universal data transfer interface and a second universal data transfer interface;
obtaining a data transfer session object from one of the invoked first universal data transfer interface or the second universal data transfer interface; and
using the data transfer session object to transfer data between a first component and a second component.
20. The method as set forth in claim 19 further comprising sending the data transfer session object to the first component to be used by the first component for receiving data transmitted from the second component.
21. The method as set forth in claim 19 further comprising sending the data transfer session object to the second component to be used by the second component for receiving data transmitted from a third component.
22. The method as set forth in claim 19 further comprising ceasing data transfer upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
23. A computer readable medium having stored thereon instructions for enabling components to transfer data between each other, which when executed by one or more processors, causes the processors to perform:
invoking a universal data transfer interface to obtain a data transfer session object; and
using the data transfer session object to transfer data between a first component and at least one of the components.
24. The medium as set forth in claim 23 wherein the at least one of the components comprises the second component or a third component.
25. The medium as set forth in claim 23 further comprising sending the data transfer session object to the first component to be used by the first component for receiving data transmitted from the at least one of the components.
26. The medium as set forth in claim 23 further comprising receiving the data transfer session object from the first component to be used by the at least one of the components for receiving data transmitted from the first component.
27. The medium as set forth in claim 23 wherein the universal data transfer interface and the data transfer session object have source-specific object-oriented mobile code that can be interpreted and performed by the first component or the at least one of the components to receive data.
28. The medium as set forth in claim 23 wherein the data transfer session object comprises instructions for enabling the first component or the at least one of the components to negotiate with each other to transfer data, for selecting a communications protocol to use to transfer data between each other based upon a type of data being transferred or for selecting a transfer medium to use to transfer data based upon the type of data.
29. The medium as set forth in claim 23 further comprising ceasing data transfer upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
30. A computer readable medium having stored thereon instructions for enabling components to transfer data between each other, which when executed by one or more processors, causes the processors to perform:
invoking a first universal data transfer interface and a second universal data transfer interface;
obtaining a data transfer session object from one of the invoked first universal data transfer interface or the second universal data transfer interface; and
using the data transfer session object to transfer data between a first component and a second component.
31. The medium as set forth in claim 30 further comprising sending the data transfer session object to the first component to be used by the first component for receiving data transmitted from the second component.
32. The medium as set forth in claim 30 further comprising sending the data transfer session object to the second component to be used by the second component for receiving data transmitted from a third component.
33. The medium as set forth in claim 30 further comprising ceasing data transfer upon the first component or the at least one of the components failing to renew a data transfer lease or indicating that the data transfer has completed or failed.
US10/058,268 2002-01-29 2002-01-29 System and method for enabling arbitrary components to transfer data between each other Abandoned US20030145089A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US10/058,268 US20030145089A1 (en) 2002-01-29 2002-01-29 System and method for enabling arbitrary components to transfer data between each other
JP2003018254A JP4424910B2 (en) 2002-01-29 2003-01-28 System that allows arbitrary components to transfer data to each other
EP03002068A EP1331571B1 (en) 2002-01-29 2003-01-29 System and method for enabling arbitrary components to transfer data between each other
DE60302368T DE60302368T2 (en) 2002-01-29 2003-01-29 System and method to allow the transfer of data between any components with each other
US10/732,700 US7421494B2 (en) 2002-01-29 2003-12-09 Method and apparatus for facilitating data transfers between arbitrary components

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/058,268 US20030145089A1 (en) 2002-01-29 2002-01-29 System and method for enabling arbitrary components to transfer data between each other

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/732,700 Continuation-In-Part US7421494B2 (en) 2002-01-29 2003-12-09 Method and apparatus for facilitating data transfers between arbitrary components

Publications (1)

Publication Number Publication Date
US20030145089A1 true US20030145089A1 (en) 2003-07-31

Family

ID=22015738

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/058,268 Abandoned US20030145089A1 (en) 2002-01-29 2002-01-29 System and method for enabling arbitrary components to transfer data between each other
US10/732,700 Active 2024-11-13 US7421494B2 (en) 2002-01-29 2003-12-09 Method and apparatus for facilitating data transfers between arbitrary components

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/732,700 Active 2024-11-13 US7421494B2 (en) 2002-01-29 2003-12-09 Method and apparatus for facilitating data transfers between arbitrary components

Country Status (4)

Country Link
US (2) US20030145089A1 (en)
EP (1) EP1331571B1 (en)
JP (1) JP4424910B2 (en)
DE (1) DE60302368T2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040025168A1 (en) * 2002-08-01 2004-02-05 Xerox Corporation Method and system for handling data
US20060004834A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Dynamic shortcuts
US20060004685A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Automated grouping of image and other user data
US20070070392A1 (en) * 2005-09-16 2007-03-29 Harrison Karen L Processing requests for data sinks in a logical printer
US20100174991A1 (en) * 2009-01-02 2010-07-08 International Business Machines Corporation Maintaining data coherency within related multi-perspective user interfaces via session-less queries
US20100228820A1 (en) * 2009-03-04 2010-09-09 Canon Kabushiki Kaisha Image processing apparatus, control method, and storage medium
US20110106877A1 (en) * 2009-10-30 2011-05-05 Askey Computer Corporation System and method for transferring files by exclusive-line connection
US9135227B2 (en) 2002-09-10 2015-09-15 SQGo, LLC Methods and systems for enabling the provisioning and execution of a platform-independent application
US9342684B2 (en) 2005-04-21 2016-05-17 Seven Networks Flexible real-time inbox access
CN107786556A (en) * 2017-10-24 2018-03-09 江苏神州信源系统工程有限公司 A kind of port fast scanning method and device

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8285860B2 (en) 2009-03-16 2012-10-09 Apple Inc. Efficient service discovery for peer-to-peer networking devices
US20100233960A1 (en) * 2009-03-16 2010-09-16 Brian Tucker Service discovery functionality utilizing personal area network protocols
US20100235523A1 (en) * 2009-03-16 2010-09-16 Robert Garcia Framework for supporting multi-device collaboration
US10277683B2 (en) 2009-03-16 2019-04-30 Apple Inc. Multifunctional devices as virtual accessories
CN108337320B (en) * 2012-04-13 2020-09-01 高盛有限责任公司 System and method for scalable structured data distribution
US9270929B2 (en) * 2013-12-19 2016-02-23 Lattice Semiconductor Corporation Formatting audio-video information compliant with first transmission format to second transmission format in integrated circuit for offloading physical layer logic for first transmission format to separate integrated circuit

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5475836A (en) * 1987-04-01 1995-12-12 Lotus Development Corporation Interface for providing access to external data sources/sinks
US5621894A (en) * 1993-11-05 1997-04-15 Microsoft Corporation System and method for exchanging computer data processing capabilites
US5664102A (en) * 1995-02-07 1997-09-02 At&T Intelligent network internetworking access arrangement
US5915252A (en) * 1996-09-30 1999-06-22 International Business Machines Corporation Object oriented framework mechanism for data transfer between a data source and a data target
US6148346A (en) * 1996-06-20 2000-11-14 Peerless Systems Imaging Products, Inc. Dynamic device driver
US6345288B1 (en) * 1989-08-31 2002-02-05 Onename Corporation Computer-based communication system and method using metadata defining a control-structure
US20020022453A1 (en) * 2000-03-31 2002-02-21 Horia Balog Dynamic protocol selection and routing of content to mobile devices
US20020099562A1 (en) * 1999-10-29 2002-07-25 Bruce Michael George System and method of data exchange for electronic transactions with multiple sources
US6591312B1 (en) * 2000-05-23 2003-07-08 Hewlett-Packard Development Company, L.P. Digital communication devices and digital communication methods
US6643650B1 (en) * 2000-05-09 2003-11-04 Sun Microsystems, Inc. Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US6675196B1 (en) * 1999-01-08 2004-01-06 Amazon.Com, Inc. Universal protocol for enabling a device to discover and utilize the services of another device
US6718377B1 (en) * 1999-08-13 2004-04-06 Lucent Technologies Inc. Telecommunications network management system interface
US6751647B1 (en) * 1998-06-19 2004-06-15 Intel Corporation Method and apparatus for automated data exchange between a user computer and a provider computer using improved object-oriented programming components
US6779004B1 (en) * 1999-06-11 2004-08-17 Microsoft Corporation Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
US6831908B2 (en) * 1999-12-03 2004-12-14 Nec Corporation Data communication system and method
US6938087B1 (en) * 2000-09-12 2005-08-30 Hewlett-Packard Development Company, L.P. Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities
US7031945B1 (en) * 2000-07-24 2006-04-18 Donner Irah H System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4106793A1 (en) * 1991-03-04 1992-09-17 Licentia Gmbh Communications interface for open communications between users and layered system - is based on macro library and contains four groups of procedures for session, link, data processing and user coded procedures
US5546549A (en) * 1994-06-01 1996-08-13 International Business Machines Corporation Multi-path channel (MPC) interface with user transparent, unbalanced, dynamically alterable computer input/output channels
GB2342196A (en) * 1998-09-30 2000-04-05 Xerox Corp System for generating context-sensitive hierarchically-ordered document service menus
US20010033554A1 (en) * 2000-02-18 2001-10-25 Arun Ayyagari Proxy-bridge connecting remote users to a limited connectivity network
US7152110B2 (en) * 2001-04-18 2006-12-19 Microsoft Corporation Information exchange between non-networked devices through an intermediary device via a piconet
US6842460B1 (en) * 2001-06-27 2005-01-11 Nokia Corporation Ad hoc network discovery menu

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5475836A (en) * 1987-04-01 1995-12-12 Lotus Development Corporation Interface for providing access to external data sources/sinks
US6345288B1 (en) * 1989-08-31 2002-02-05 Onename Corporation Computer-based communication system and method using metadata defining a control-structure
US5621894A (en) * 1993-11-05 1997-04-15 Microsoft Corporation System and method for exchanging computer data processing capabilites
US5664102A (en) * 1995-02-07 1997-09-02 At&T Intelligent network internetworking access arrangement
US6148346A (en) * 1996-06-20 2000-11-14 Peerless Systems Imaging Products, Inc. Dynamic device driver
US5915252A (en) * 1996-09-30 1999-06-22 International Business Machines Corporation Object oriented framework mechanism for data transfer between a data source and a data target
US6751647B1 (en) * 1998-06-19 2004-06-15 Intel Corporation Method and apparatus for automated data exchange between a user computer and a provider computer using improved object-oriented programming components
US6675196B1 (en) * 1999-01-08 2004-01-06 Amazon.Com, Inc. Universal protocol for enabling a device to discover and utilize the services of another device
US6779004B1 (en) * 1999-06-11 2004-08-17 Microsoft Corporation Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
US6718377B1 (en) * 1999-08-13 2004-04-06 Lucent Technologies Inc. Telecommunications network management system interface
US20020099562A1 (en) * 1999-10-29 2002-07-25 Bruce Michael George System and method of data exchange for electronic transactions with multiple sources
US6831908B2 (en) * 1999-12-03 2004-12-14 Nec Corporation Data communication system and method
US20020022453A1 (en) * 2000-03-31 2002-02-21 Horia Balog Dynamic protocol selection and routing of content to mobile devices
US6643650B1 (en) * 2000-05-09 2003-11-04 Sun Microsystems, Inc. Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US6591312B1 (en) * 2000-05-23 2003-07-08 Hewlett-Packard Development Company, L.P. Digital communication devices and digital communication methods
US7031945B1 (en) * 2000-07-24 2006-04-18 Donner Irah H System and method for reallocating and/or upgrading and/or rewarding tickets, other event admittance means, goods and/or services
US6938087B1 (en) * 2000-09-12 2005-08-30 Hewlett-Packard Development Company, L.P. Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7367029B2 (en) * 2002-08-01 2008-04-29 Xerox Corporation Method and system for handling data
US20040025168A1 (en) * 2002-08-01 2004-02-05 Xerox Corporation Method and system for handling data
US9135227B2 (en) 2002-09-10 2015-09-15 SQGo, LLC Methods and systems for enabling the provisioning and execution of a platform-independent application
US10839141B2 (en) 2002-09-10 2020-11-17 Sqgo Innovations, Llc System and method for provisioning a mobile software application to a mobile device
US10831987B2 (en) 2002-09-10 2020-11-10 Sqgo Innovations, Llc Computer program product provisioned to non-transitory computer storage of a wireless mobile device
US10810359B2 (en) 2002-09-10 2020-10-20 Sqgo Innovations, Llc System and method for provisioning a mobile software application to a mobile device
US10552520B2 (en) 2002-09-10 2020-02-04 Sqgo Innovations, Llc System and method for provisioning a mobile software application to a mobile device
US10372796B2 (en) 2002-09-10 2019-08-06 Sqgo Innovations, Llc Methods and systems for the provisioning and execution of a mobile software application
US9390191B2 (en) 2002-09-10 2016-07-12 SQGo, LLC Methods and systems for the provisioning and execution of a mobile software application
US9342492B1 (en) 2002-09-10 2016-05-17 SQGo, LLC Methods and systems for the provisioning and execution of a mobile software application
US9311284B2 (en) 2002-09-10 2016-04-12 SQGo, LLC Methods and systems for enabling the provisioning and execution of a platform-independent application
US7464110B2 (en) 2004-06-30 2008-12-09 Nokia Corporation Automated grouping of image and other user data
US20090064044A1 (en) * 2004-06-30 2009-03-05 Nokia Corporation Automated Grouping of Image and Other User Data
US20060004685A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Automated grouping of image and other user data
US20060004834A1 (en) * 2004-06-30 2006-01-05 Nokia Corporation Dynamic shortcuts
US9342684B2 (en) 2005-04-21 2016-05-17 Seven Networks Flexible real-time inbox access
US20070070392A1 (en) * 2005-09-16 2007-03-29 Harrison Karen L Processing requests for data sinks in a logical printer
US8176097B2 (en) * 2009-01-02 2012-05-08 International Business Machines Corporation Maintaining data coherency within related multi-perspective user interfaces via session-less queries
US20100174991A1 (en) * 2009-01-02 2010-07-08 International Business Machines Corporation Maintaining data coherency within related multi-perspective user interfaces via session-less queries
US9270844B2 (en) * 2009-03-04 2016-02-23 Canon Kabushiki Kaisha Image processing apparatus, control method, and storage medium that complement a domain to an address data item with no domain name
US20100228820A1 (en) * 2009-03-04 2010-09-09 Canon Kabushiki Kaisha Image processing apparatus, control method, and storage medium
US20110106877A1 (en) * 2009-10-30 2011-05-05 Askey Computer Corporation System and method for transferring files by exclusive-line connection
CN107786556A (en) * 2017-10-24 2018-03-09 江苏神州信源系统工程有限公司 A kind of port fast scanning method and device

Also Published As

Publication number Publication date
US7421494B2 (en) 2008-09-02
EP1331571B1 (en) 2005-11-23
US20040122957A1 (en) 2004-06-24
DE60302368D1 (en) 2005-12-29
DE60302368T2 (en) 2006-06-08
JP4424910B2 (en) 2010-03-03
EP1331571A1 (en) 2003-07-30
JP2003223336A (en) 2003-08-08

Similar Documents

Publication Publication Date Title
US7552265B2 (en) System and method for providing context information
US7296042B2 (en) System and method for enabling communication among arbitrary components
EP1331571B1 (en) System and method for enabling arbitrary components to transfer data between each other
US7433915B2 (en) System and method for controlling communication
US7526482B2 (en) System and method for enabling components on arbitrary networks to communicate
US10419535B2 (en) Preconfigured syncML profile categories
US6430596B1 (en) Managing networked directory services with auto field population
EP1872523B1 (en) System and method of device-to-server registration
US7590661B2 (en) Advanced Web Services on a legacy platform
US7277915B2 (en) Application-based protocol and proxy selection by a mobile device in a multi-protocol network environment
US7284060B2 (en) Method for transferring data in a system having multiple transports
US20080294778A1 (en) Network connection manager
Lohse et al. An open middleware architecture for network-integrated multimedia
US20020046304A1 (en) Dynamic class loading
EP1198102A1 (en) Extendable provisioning mechanism for a service gateway
US20030023577A1 (en) Method and apparatus for handling the registration of multiple and diverse communication protocols for use in an object request broker (ORB)
US7367029B2 (en) Method and system for handling data
US7685303B2 (en) Object-oriented discovery framework
Bissyandé et al. Ubigate: A gateway to transform discovery information into presence information
CN117155904A (en) Service registration method
Babin et al. Application programming interface for WOSP/WOSRP
Holmström End-to-end monitoring of mobile services
JPH10326231A (en) Distributed network computing system and information exchanging device used for the same system and method therefor and storage medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: XEROX CORPORATION, CONNECTICUT

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:EDWARDS, WARREN K.;NEWMAN, MARK W.;SEDIVY, JANA Z.;REEL/FRAME:012553/0638

Effective date: 20011120

AS Assignment

Owner name: BANK ONE, NA, AS ADMINISTRATIVE AGENT, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:013111/0001

Effective date: 20020621

Owner name: BANK ONE, NA, AS ADMINISTRATIVE AGENT,ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:013111/0001

Effective date: 20020621

AS Assignment

Owner name: JPMORGAN CHASE BANK, AS COLLATERAL AGENT, TEXAS

Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:015134/0476

Effective date: 20030625

Owner name: JPMORGAN CHASE BANK, AS COLLATERAL AGENT,TEXAS

Free format text: SECURITY AGREEMENT;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:015134/0476

Effective date: 20030625

AS Assignment

Owner name: XEROX CORPORATION, NEW YORK

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:BANK ONE, NA;REEL/FRAME:025461/0930

Effective date: 20030625

Owner name: XEROX CORPORATION, NEW YORK

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JP MORGAN CHASE BANK, NA;REEL/FRAME:025461/0807

Effective date: 20061204

AS Assignment

Owner name: YORANSO CONSULTING LIMITED LIABILITY COMPANY, DELA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:025845/0123

Effective date: 20101230

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: XEROX CORPORATION, CONNECTICUT

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JPMORGAN CHASE BANK, N.A. AS SUCCESSOR-IN-INTEREST ADMINISTRATIVE AGENT AND COLLATERAL AGENT TO BANK ONE, N.A.;REEL/FRAME:061388/0388

Effective date: 20220822