Service framework with local proxy for representing remote services

• US 7,315,885 B2
• Filed: 03/22/2004
• Issued: 01/01/2008
• Est. Priority Date: 09/15/2000
• Status: Expired due to Term

• Current Assignee: Google Technology Holdings LLC (Alphabet Inc.)
• Original Assignee: Motorola, Inc. (Motorola Solutions, Inc.)
• Inventors: Clayton, Mark, Bhaskaran, Parvathy, Liu, Kungwel Mike, Smith, Merlin, Weisshaar, Bernhard
• Primary Examiner(s): Donaghue; Larry D.
• Application Number:
  US10/805,878
• Publication Number:
  US 20040187133A1
• Time in Patent Office: 1,380 Days
• Field of Search: 709/203, 709/217, 709/250
• US Class Current: 709/217
• CPC Class Codes: H04L 63/0281 Proxies
• CPC Class Codes: H04L 67/04 specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• CPC Class Codes: H04L 67/303 Terminal profiles
• CPC Class Codes: H04L 67/306 User profiles
• CPC Class Codes: H04L 67/51 Discovery or management thereof, e.g. service location protocol [SLP] or web services
• CPC Class Codes: H04L 67/53 using third party service providers
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]
• CPC Class Codes: H04L 9/40 Network security protocols
• CPC Class Codes: H04W 28/06 Optimizing the usage of the radio link, e.g. header compression, information sizing , discarding information system modifying transmission characteristic according to link quality by modifying frame length H04L1/0007; dynamic adaptation of the packet size for flow control or congestion control H04L47/365
• CPC Class Codes: H04W 4/00 Services specially adapted for wireless communication networks; Facilities therefor
• CPC Class Codes: H04W 74/00 Wireless channel access

Abstract

In an information appliance system 100, a user device 108 comprises a client platform (200, FIG. 5) that includes a service framework (235, FIG. 5) to discover and connect with a variety of services, both remote and local, transient and persistent, and to disconnect from them when they are no longer of interest or become unavailable. The service framework 235 provides a standard, consistent, simplified way for services to make themselves available and for service-using entities to locate and connect with the services of interest to them. From the perspective of the client platform 200, all services, whether local or remote, are presented as local services to the application. Each remote service is represented as a local service through the use of a local proxy that insulates the service user from the complexities of communicating with a remote server. Various methods of operating a service framework are also described.

Claims

1. A communications platform comprising:

a processor;

a wireless interface coupled to the processor to enable the communications platform to communicate with a remote node; and

a memory coupled to the processor and comprising;

a service-requesting entity;

a service framework that represents a service residing on the remote node solely as a proxy on the communications platform, wherein the proxy comprises a remote service frontend and wherein the service framework comprises the remote service frontend residing on the communications platform, a remote service backend residing on the remote node, a remote service event notification registry into which the remote service frontend can register a notification request for the remote service backend and a remote lookup daemon to notify the remote service frontend that the remote service backend is on the remote node; and

a connection manager service to notify the service framework when the communications platform is in proximity to the remote node.

2. The communications platform recited in claim 1 wherein the service framework further comprises a service registry into which the remote service frontend can register the service.

3. The communications platform recited in claim 2 wherein the service framework further comprises an event delivery daemon to notify the service-requesting entity when the service is registered in the service registry.

4. The communications platform recited in claim 3 wherein the memory further comprises:

a program module, responsive to the event delivery daemon, to cause the service-requesting entity to invoke the service.

5. The communications platform recited in claim 4 wherein the service frontend communicates with the service backend to implement the service invoked by the service-requesting entity.

6. The communications platform recited in claim 4 wherein the memory further comprises:

at least one local service that can be requested and invoked by the service-requesting entity, the service and the at least one local service appearing indistinguishable to the service-requesting entity regarding the manner in which they can be requested and invoked by the service-requesting entity.

7. A communications system comprising:

at least one remote node; and

at least one communications node comprising;

a processor;

a wireless interface coupled to the processor to enable the at least one communications node to communicate with the at least one remote node; and

a memory coupled to the processor and comprising;

a service-requesting entity;

a service framework that represents a service residing on the at least one remote node solely as a proxy on the at least one communications node, wherein the proxy comprises a remote service frontend and wherein the service framework comprises the remote service frontend residing on the communications platform, a remote service backend residing on the remote node, a remote service event notification registry into which the remote service frontend can register a notification request for the remote service backend and a remote lookup daemon to notify the remote service frontend that the remote service backend is on the remote node; and

a connection manager service to notify the service framework when the communications platform is in proximity to the remote node.

8. The communications system recited in claim 7 wherein the service framework further comprises a service registry into which the remote service frontend can register the service.

9. The communications system recited in claim 8 wherein the service framework further comprises an event delivery daemon to notify the service-requesting entity when the service is registered in the service registry.

10. The communications system recited in claim 9 wherein the memory further comprises:

a program module, responsive to the event delivery daemon, to cause the service-requesting entity to invoke the service.

11. The communications system recited in claim 10 wherein the service frontend communicates with the service backend to implement the service invoked by the service-requesting entity.

12. The communications system recited in claim 10 wherein the memory further comprises:

at least one local service that can be requested and invoked by the service-requesting entity, the service and the at least one local service appearing indistinguishable to the service-requesting entity regarding the manner in which they can be requested and invoked by the service-requesting entity.