JP6295643B2 - Managing the scope of network services - Google Patents

Description

  The present invention relates generally to network services, and more particularly to an approach that allows source devices to use network services that are in different networks.

  The approaches described in this chapter are approaches that may have been attempted, but not necessarily approaches that have been previously devised or achieved. Accordingly, unless otherwise indicated, the approaches described in this section are not prior art to the claims of this application and are not to be considered prior art by inclusion in this section.

  Network services and discovery systems (such as AirPrint) are becoming popular. Many users connect to network services and network applications from their mobile devices. Typically, a discovery system assists in the discovery of network services that reside in the same network segment or subnet as the device that requests the network service. However, one of two approaches can be implemented to assist in the discovery of network services that reside in a different network segment or subnet than the requesting device.

  In one approach, multicast routing is performed at a router connecting two networks or subnets. Multicast routing allows multicast traffic to pass between subnets. However, some routers or wireless access points do not support the multicast routing function.

  In another approach, a server with dedicated software is placed in each network or subnet. These servers send packets from the network or subnet to other networks or subnets. However, it is troublesome to arrange such servers or software for each network or subnet.

Techniques are provided for managing the scope of and access to one or more network services.

  According to a technique, a service manager receives first service information indicating a first service provided by a target device from a target device that exists in a first subnet via a network. In response to receiving the first service information, the service manager stores the first service information. The service manager receives a first request for service information from a source device that resides in a second subnet that is different from the first subnet. In response to receiving the first request, the service manager identifies the first service information, generates a response with the first service information, and sends the response to the source device.

  According to another technique, the service manager stores service data identifying a plurality of services including a first service located in a first subnet. The service manager stores one or more rules associated with service data. After storing the service data and one or more rules, the service manager receives a request for available services from a source device in the first subnet. In response to receiving the request, the service manager identifies a subset of the plurality of services based on at least one rule of the one or more rules, the subset having no first service. The service manager identifies a subset of the plurality of services and generates a response having a list of available services that do not have the first service. The service manager sends a response to the source device.

  Embodiments may be implemented by instructions processed by one or more processors, one or more computer-implemented methods, or correspondingly configured apparatus or equipment.

Like reference symbols in the accompanying drawings indicate like elements.
1 is a block diagram illustrating an example network architecture. FIG. FIG. 6 is a block diagram illustrating an exemplary screen that allows a user to select a print service option. FIG. 3 is a block diagram illustrating an example screen showing available network services. It is a sequence diagram which shows the network service registration sequence in the same subnet. It is a sequence diagram which shows a network service discovery sequence and a network service execution sequence. FIG. 2 is a block diagram illustrating an example network architecture that uses a server application in each subnet to allow network services to be discovered in different network subnets. FIG. 2 is a block diagram illustrating an example network architecture that allows devices in one subnet to discover network services in another subnet in one embodiment. It is a block diagram which shows the network service information table hold | maintained by the service manager in one Embodiment. FIG. 6 is a sequence diagram illustrating how a network service registers with a service manager in one embodiment. FIG. 6 is a sequence diagram illustrating how to discover network services in one embodiment. It is a block diagram which shows the network service information table hold | maintained at the source device in one Embodiment. FIG. 3 is a block diagram illustrating an example screen showing available network services in one embodiment. It is a block diagram which shows the network service information table hold | maintained by the service connector in the source device in one Embodiment. FIG. 6 is a sequence diagram illustrating how network services in another subnet are accessed from a source device in one embodiment. FIG. 2 is a block diagram illustrating an example architecture for managing the use of one or more network resources in one embodiment. In one embodiment, it is a sequence diagram showing how to discover network services that the source device is registered with one or more rules. FIG. 6 is a block diagram illustrating an association between actions, users, locations, device attributes, and specific rules, according to one embodiment. FIG. 6 is a block diagram illustrating an association between actions, users, locations, device attributes, and specific rules, according to one embodiment. And FIG. 7 is a block diagram of a computer system in which embodiments of the present invention may be implemented.

  In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of embodiments of the present invention. However, one skilled in the art will understand that the invention may be practiced regardless of such specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

<Overview>
This specification describes techniques for managing the scope of and access to one or more network services. A target device that hosts a network service executes a service connector configured to communicate with a service manager executing on a different device. The service manager stores service information regarding the network service and zero or more other network services. The service manager provides service information to source devices that may request use of network services. The service manager may provide service information in response to a request from the source device for available services. Therefore, the source device can discover the target device even if the target device and the source device are in different subnets.

  In related technology, a source device executing a service connector requests a service available from a service manager executing on a different device. The service manager determines a list of network services that the source device can discover. The list of network services is determined based on one or more criteria such as the current location of the source device, whether the source device is associated with authentication information, whether the source device has certain attributes, etc. . Thus, even if the network service exists in the same subnet as the source device, the service manager can limit the network services that the source device can find.

<Scope-limited approach for network service discovery>
As mentioned above, multiple approaches can be used to discover network services. FIG. 1 is a block diagram illustrating an example network architecture 100 in which a source device can only discover services that are in the same subnet as the source device. Network architecture 100 has two subnets: subnet 180 and subnet 190. Subnets 180 and 190 are communicatively coupled by router 170. The subnet 180 includes source devices 110 and 120 and target devices 130 and 140. The subnet 190 includes a source device 150 and a target device 160. Source devices 110, 130, and 150 have applications 112, 122, and 152, respectively. Applications 112, 122, and 152 may request one or more services 132, 142, and 162 hosted by target devices 130, 140, and 160, respectively.

  Each apparatus shown in FIG. 1 has a service platform. Through the service platform, an application (in the case of a source device) or a service (in the case of a target device) sends or requests information.

  FIG. 2 is a block diagram illustrating an exemplary screen 200 that allows a user to select print service options. The screen 200 may be generated on the source device 110 by the application 112. The screen 200 has a button 210 that allows the user to select a service. For example, selection of the screen 200 causes the screen 300 shown in FIG.

  The screen 300 has a list 310 of print services registered in the source device 110. List 310 identifies service 122 of target device 120 and service 132 of target device 130. In particular, the list 310 does not include the service 152 of the target device 150 because the target device 150 is in a different subnet than the source device 110.

  Returning to the screen 200 of FIG. 2, the screen 200 has a list 220 of print options that the user can select. The screen 200 also has an execution button 230. The execute button 230, when selected, causes a print job indicating the selected option to be submitted to the selected service. Again, the services that are selected are limited to those that are found within subnet 180.

  FIG. 4 is a sequence diagram showing a network service registration sequence 400 within the same subnet. In step 410, the service 132 sends a registration request to the service platform 134. In steps 420-440, the service platform 134 notifies each service platform of the devices in the subnet 180 including the source device 110, the source device 120, and the target device 140 in the illustrated example.

  FIG. 5 is a sequence diagram showing a network service discovery sequence and a network service execution sequence 500. In step 505, the user provides input to the application 112 to initiate discovery of the print service. In step 510, in response, application 112 sends a request to service platform 114. The request is for an available print service. In response, at step 515, the service platform 114 returns a list of one or more print services. In step 520, in response, the application 112 generates a screen showing the list and causes the source device 110 to display the screen. At step 525, the user provides input to application 112 indicating selection of one of the print services listed in the displayed list. In step 530, in response, the application 112 selects a user selected print service. At step 535, the user provides input to application 112 indicating selection of one or more print options. In step 540, in response, application 112 selects a user-selected print option. At step 545, the user provides input to the application 112 indicating execution of the print job. In step 550, in response, application 112 submits a print job (identifying the selected print service and selected print options) to service 132 hosted by target device 130. In step 555, the service 132 executes the print job and generates a result. At step 560, service 132 sends the result to application 112. The application 112 may display information regarding the result.

<Service discovery using specially configured servers in each subnet>
FIG. 6 is a block diagram illustrating an example network architecture 600 that uses server applications in each subnet to allow discovery of network services in different network subnets. Network architecture 600 is similar to network architecture 100 in several respects. Network architecture 600 has two subnets: subnet 680 and subnet 690. Subnets 680 and 690 are communicatively coupled to router 670. The subnet 680 includes a source device 610 and a target device 630. The subnet 690 includes a source device 650 and a target device 660. The source devices 610 and 650 have applications 612 and 652, respectively. Applications 612 and 652 may request one or more services 632 and 662 hosted by target devices 630 and 660, respectively.

  Each source device and target device shown in FIG. 6 has a service platform. Through the service platform, an application (in the case of a source device) or a service (in the case of a target device) sends or requests information.

  Network architecture 600 also includes a server 620 located in subnet 680 and a server 640 located in subnet 690. Server 620 has a tunnel service application 622, and server 640 has a tunnel service application 642. Tunnel service applications 622 and 642 are used to discover network services in both subnets. Accordingly, source device 610 can discover service 662 hosted by target device 660 and source device 650 can discover service 632 hosted by target device 630.

<Service discovery using service connectors>
FIG. 7 is a block diagram illustrating an example network architecture 700 that allows devices in one subnet to discover network services in another subnet in one embodiment. The network architecture 700 has a service manager 760, a network 770, and two subnets: subnet 780 and subnet 790. Service manager 760 and network 770 are communicatively coupled by subnets 780 and 790.

  The subnet 780 includes a source device 710 and target devices 720 and 750. The subnet 790 includes target devices 730 and 740. The source device 710 has an application 712. Application 712 may request one or more services 722, 732, 742, 752 hosted by target devices 720-750, respectively. Examples of services 722, 732, 742, 752 include printing services, fax services, scanning services, and archiving services. Examples of the application 712 include a document processing application and an image processing application. Each of these applications may request a print service that prints one or more documents or images, for example.

  Network 770 may be implemented by any medium or mechanism that provides data exchange between source device 710 and target devices 720-750. Examples of the network 770 include a network such as a local area network (LAN), a wide area network (WAN), an Ethernet, or the Internet, or one or more terrestrial, satellite, or wireless links. It is not limited.

  Each apparatus shown in FIG. 1 has a service platform. In particular, the source device 710 has a service platform 714 and the target devices 720-750 have service platforms 724-754, respectively. The service platform stores information about services that are “known” to the service platform. The service platform shares / advertises service information with other service platforms in the same subnet. The service information may include an IP address of each service, a port number of each service, a name of each service, a device identifier of a device that hosts each service, and the like. An application executing on a device (eg, application 712) can query a service platform (eg, service platform 714) on the device to retrieve information about known services.

  Source device 710 also has a service connector 716. The service connector 716 communicates with the service manager 760 to read information about the network service regardless of whether the network service is in the same or different subnet as the source device 710. The target devices 720 and 740 have service connectors 726 and 746, respectively. Service connectors 726, 746 communicate with service manager 760 to notify service manager 760 regarding the service connector's individual hosted services (ie, services 722, 742). The service manager 760 stores service information for identifying the services 722 and 742, and causes the source device from any subnet to inquire the service manager 760 regarding network services available in any subnet. In this way, two specially configured servers are not required in each subnet to allow discovery of network services within each subnet.

  In one embodiment, when one or more service connectors 716, 726, 746 are notified of services hosted on their individual devices, one or more service connectors 716, 726, 746 Configured to communicate with the service platform. In this way, these service connectors can retrieve information about services from their individual service platforms and inform the service manager 760 of their hosted services.

  Service connectors 716, 726, 746 may be implemented in software, hardware, or any combination of software and hardware. Service connectors 716, 726, 746 may be hard-coded to have service manager 760 identifiers. Alternatively, the service connectors 716, 726, 746 may be configured to automatically find the address of the service manager 760. For example, when a new network is detected, the service connector 716 may send a discovery message that conforms to a general format recognizable by the service manager 760 over the network. Service manager 760 responds with a discovery response that includes address information that service connector 716 uses to communicate with service manager 760.

<Service information held by the service manager>
FIG. 8 is a block diagram illustrating a table 800 of network service information held by the service manager 760 in one embodiment. Table 800 has six columns for six different types of information: service type, device identifier, service name, IP address and port number, protocol access type, and service range. In the illustrated example, the table 800 has three rows or entries. Each entry corresponds to a different service. In the example shown, each service is a kind of printing. In other embodiments, examples of service types may include fax, scan, and archive. The three entries identify the target device 720, the target device 730, and the target device 740, respectively. The table 800 does not have an entry for the target device 750. This is because the target device 750 does not have a service connector that automatically registers the target device 750 with the service manager 760. The target device 730 also has no service connector, but the table 800 has an entry for the target device 730. This situation can occur, for example, when an administrator manually registers the target service 732 with the service manager 760.

  With respect to the protocol access type, TCP is identified in the illustrated example. Another example of the protocol access type is UDP. Some target services may support both TCP and UDP.

  Regarding the service range, in the illustrated example, “multiple segments” are identified. Another example of service coverage is “single segment”. When a target service is associated with a “single segment”, it indicates that a source device in a different segment or subnet from the target service is not allowed to access the target service. Another example of “service range” is a specific IP address. If the target service is associated with a specific IP address, only the source device associated with the specific IP address is allowed access to the target service. The service manager 760 and / or the service connector may perform access control using the “service range” value.

<Network service registration>
FIG. 9 is a sequence diagram illustrating how a network service registers with the service manager 700 in one embodiment. Although FIG. 9 shows a target device 740, other target devices shown in FIG. 7 may be involved instead. Alternatively, FIG. 9 is applicable to each target device shown in FIG.

  In step 910, the service 742 sends a registration request message to the service platform 744. Service 742 may be configured to communicate with its associated service platform when service 742 begins to execute on the device.

  In step 920, in response, the service platform 744 notifies the service connector 746 that the service 742 has been registered with the target device 740. Service platform 744 may be configured to communicate with service connector 716 each time service platform 744 is notified of another service hosted on target device 740.

  In response, at step 930, service connector 746 requests service information regarding service 742 from service platform 744. Examples of such service information are provided in the table 800, for example, IP address and port number, and service type.

  At step 940, service platform 744 sends service information regarding service 742 to service connector 746. At step 950, service connector 746 sends a registration message that includes the requested service information from service platform 744 to service manager 760. The service manager 760 stores service information in a table such as the table 800.

  In one embodiment, service connector 746 transmits service information to service manager 760 in response to receiving service information from service platform 740. Alternatively, service connector 746 sends service information to service manager 760 in response to a request from service manager 760. For example, the service manager 760 may poll (on a regular basis) target devices in the subnets 780, 790 for current service information.

<Discover network services>
FIG. 10 is a sequence diagram illustrating how a source device discovers a network service in one embodiment. Although FIG. 9 shows a target device 710, other source devices (not shown) may be involved instead.

  In step 1010, the service connector 716 in the source device 710 sends a service request to the service manager 760. Service connector 716 may send service requests periodically or in response to certain internal events. Alternatively, the service request may be generated in response to a message from service manager 760 (eg, an event notification reserved by service connector 716).

  In step 1020, in response to the service request, service manager 760 identifies one or more registered services (eg, in table 800) and sends a response to service connector 716. In one embodiment, the response has a service type, device identifier, service name, IP address and port number, protocol access type, service range for the registered service.

In step 1030, the service connector 716, the service platform 714 transmits the service information for each registered service identified in the response from the service manager 760. In one embodiment, the service information (for a specific service) that the service connector 716 sends to the service platform is different from the service information (for the specific service) received from the service manager 760. For example, step 1030 includes a step in which the service connector 716 generates a dummy IP address for the registered service (identified in the service information from the service manager 760) and replaces the actual IP address with the dummy IP address. You may have. The process of replacing the actual IP address of the network service with a dummy IP address may be performed for each registered service outside the subnet of the requesting source device (that is, the source device 710 in this example). Thus, if the source device is source device 710, the replacing step may be performed for services 732, 734 (which are in a different subnet 790 than subnet 780) rather than for services 722, 752. good. The dummy IP address stored in the source device 710 points to or refers to the source device 710.

<Service information held by the service platform>
FIG. 11 is a block diagram illustrating a table 1100 of network service information held in the source device according to an embodiment. The service platform 714 may be responsible for storing and holding the table 1100. Later, the application 712 may query the service platform 714 for available services.

  Table 1100 has six columns for six different types of information: service type, device identifier, service name, IP address and port number, protocol access type, and service range. In this example, the source device 110 stores the table 1100 in the local storage device. Each row in table 1100 corresponds to a different service that service connector 716 discovers using service manager 760. The third row corresponds to service 752 hosted by target device 750. The fourth row corresponds to service 722 hosted by target device 720. As shown in FIG. 7, the target devices 720 and 750 exist in the same subnet as the source device 710.

  However, service information regarding services 732 and 742 has been changed (eg, by service connector 716) prior to storing the service information in table 1100. The first row of table 1100 corresponds to service 732 hosted by target device 730, but the device identifier column identifies source device 710, not source device 730. Similarly, the second row of table 1100 corresponds to service 742 hosted by target device 740, but the device identifier column identifies source device 710, not source device 740.

  Further, the IP address column of the table 1100 does not have the actual IP address and port number of the services 732 and 742. The actual IP addresses of services 732 and 742 are 10.10.10.123 and 10.10.10.24, respectively. Instead, the dummy IP address and port number are found in the IP address column of table 1100 for services 732, 742. The disadvantages of using the actual IP address and port number of table 1100 for services 732, 742 are (1) the fact that current existing service registry systems do not allow such scenarios, and (2) access control, including. Regarding the latter drawback, if the service connector 716 registers a service with the actual service address with the service platform 714 in block 1030 of FIG. 10, the service platform 714 will send this service registration information to the same segment as the source device 710. Or automatically share with other service platforms (eg 724, 754) in the subnet. It is difficult to perform access control by using an existing service platform.

  FIG. 12 is a block diagram illustrating an exemplary screen 1200 that shows available network services in one embodiment. In this example, the source device 710 displays a screen 1200. Screen 1200 has a list of four services 732, 742, 752, 722. Even if services 732, 742 appear in a different subnet than source device 710, services 732, 742 are listed. A user selection of one of the listed services indicates that the user wants the selected service to perform one or more functions such as a print function, a scan function, etc.

<Service information held by service connector>
FIG. 13 is a block diagram illustrating a network service information table 1300 held by a service connector at the source device in one embodiment. In this example, the source device is a source device 710 and the service connector is a service connector 716.

  Table 1300 includes six columns for six different types of information: service type, target device identifier, service name, service connector IP address and port number, target service IP address and port number, and protocol access type. Have. In this example, table 1300 has only two rows or entries, one for each service that is on a different subnet than source device 710.

  In one embodiment, if the service connector receives a request identifying a service identified in the service connector IP address column of the table 1300, the service connector may use that address as the corresponding address in the target service IP address column. Replace with. For example, service connector 716 receives a service request having an IP address and port number 127.0.0.1/122 and determines that 127.0.0.1/122 is in the first entry of table 1300. In the service request, 127.0.0.1/122 is replaced with 10.10.10.23/631, and the changed service request is sent to the destination associated with 10.10.10.123/3631 To do.

<Access to services in another subnet>
FIG. 14 is a sequence diagram 1400 illustrating how network services in another subnet are accessed from a source device in one embodiment. In this example, the network service is service 742 and the source device is source device 710.

  In step 1405, the user provides input to application 712 indicating a request to display a print screen at source device 710. In step 1410, in response, application 712 sends a request to service platform 714 for a list of currently available print services.

  In step 1415, in response, the service platform 714 returns a list of currently available print services to the application 712. Step 1415 may comprise the service platform identifying table 700 and reading an entry or row of table 700.

  In step 1420, in response to receiving the list, application 712 displays a print screen. The print screen may be the screen 1200 shown in FIG.

  At step 1425, the user “selects” one of the listed services. In other words, the user provides an input indicating selection of service display data that identifies one of the services listed on the print screen. In step 1430, the application 712 stores service selection data indicating the service selected by the user.

  At step 1435, the user selects one or more options. This step may include selecting printing options such as print media (eg, paper) size, orientation, duplex printing, color or gray scale, and the like.

  In step 1440, in response, application 712 stores option selection data indicating the option selected by the user.

  In step 1445, the user selects an “execute” or “print” button, such as the execute button 230 shown in FIG.

  In step 1450, in response, application 712 submits a print job based on the selected service and the selected option. In this example, the selected service is service 742. Service 742 is hosted on a target device 740 that is in a different subnet than the subnet in which source device 710 is located. Thus, the IP address associated with service 742 is a dummy IP address such as 127.0.0.2 shown in table 1300. Such a dummy address indicates that a corresponding service is available on the device in which the dummy IP address is stored. In step 1450, the service connector 716 receives the print job transmitted from the application 712.

  At step 1455, service connector 716 submits the print job to service 742. Step 1455 may include determining whether the destination IP address (of the target device) indicated in the print job is a dummy IP address. Service connector 716 may make this determination, for example, by comparing the destination IP address with the service connector IP address shown in table 1300. In this example, the destination IP address and port number are 127.0.0.2/222, and the service connector 716 replaces the destination IP address and port number with 10.10.10.23/631.

  For example, if the target service is service 752, service connector 716 will not find a match with the destination IP address (shown in the print job) in table 1300. This is because the IP address associated with service 752 in table 1100 is the actual IP address of service 752 and not a dummy IP address.

  In step 1460, the service 742 receives a print job from the source device 710 and executes the print job. The execution of the print job may include a step in which the service 742 prints one or more documents with information reflected in the print data of the print job.

  In step 1465, the service 742 generates a result of executing the print job, and transmits the result to the service connector 716. The result may be an indicator of whether or not the print job has been successfully executed.

  At step 1455, service connector 716 may record service request history data indicating which service connector 716 expects the result. Next, at step 1465, the service connector 716 determines that the result data received from the service 742 corresponds to the print job submitted by the application 712 based on the service request history data.

  Alternatively, in response to receiving the result at step 1465, service connector 716 identifies the sender's IP address, in this example 10.10.10.124, and the IP address is shown in table 1300. Compare to the target IP address. If the sender's IP address is found in the table 1300, step 1465 may include the service connector 716 replacing the IP address with the corresponding service connector (or dummy) IP address. In this example, the dummy IP address is 127.0.0.2.

  In step 1470, the service connector 716 sends the result data to the application 712. The result data may have a dummy IP address shown in the table 1300.

  In step 1475, the application 712 causes the user to display the result (eg, success or failure) indicated in the result data.

  In a related embodiment, instead of the service connector 716 submitting the print job directly to the service 742 at step 1455, the service connector 716 sends the print job to the service manager 760. The service manager 760 examines the print job and determines to which target device the print job should be transferred. In response to determining that the target service 742 is the intended destination for the print job, the service manager 760 sends the print job to the target service 742. After executing the print job, the target service sends a result (eg, a success or failure indication) to (a) the service manager 760, which forwards the result to the service connector 716, or (B) It may be transmitted to the service connector 716 and the service manager 760 may be efficiently skipped. This embodiment in which service connector 716 submits a print job through service manager 760 is useful when source device 710 cannot directly access target device 740 due to some network configuration.

<Management of access to network services>
As mentioned above, mobile devices and network applications are widely used. However, currently there is no authentication and authorization mechanism when using network services (such as “Airprint”) from mobile devices. As a result, any mobile or other device in the subnet can use any network service in the same subnet.

  FIG. 15 is a block diagram illustrating an example architecture 1500 for managing access to one or more network services in one embodiment. The architecture 1500 includes a source device 1510, a target device 1520, a network service 1530, and a network service 1550. A source device 1510, a target device 1520, and a network service 1530 are communicatively coupled to a network 1550. Network 1550 may be implemented by any medium or mechanism that provides data exchange between source device 1510, target device 1520, and network service 1530. Examples of network 1550 include, but are not limited to, a local area network (LAN), a wide area network (WAN), a network such as Ethernet or the Internet, or one or more terrestrial, satellite, or wireless links.

  Source device 1510 and target device 1520 may be in the same subnet, different subnets, or entirely different networks.

  The source device 1510 includes an application 1512, a service platform 1514, and a service connector 1516. The source device 1510 may be a client device such as a desktop computer, laptop computer, tablet computer, or smartphone.

  The target device 1520 includes a service 1522 and a service platform 1524. Examples of services 1522 include printing services, fax services, scanning services, and archiving services. Examples of target device 1520 include a printer, fax machine, scanner, or multifunction peripheral that performs one or more of these functions.

  The network service 1530 may include one or a plurality of devices. The network service 1530 has five elements: an application 1532, a user equipment manager 1534, a service manager 1536, a location manager 1538, and a policy manager 1540. Each of the five elements may be implemented in software, hardware or a combination thereof. Although shown as separate elements, applications 150, 160, user device manager 170, location manager 180, and policy manager 190 are implemented on a single computer device or two or more computer devices communicatively coupled to each other. Also good.

Figure 16 shows, in an embodiment, a sequence diagram 1600 showing how to discover network services that the source device is registered with one or more rules. At step 1610, service connector 1516 sends a request for a currently available (eg, registered) service. The request may include (1) login information indicating a user name and password, and (2) position information indicating the current position of the source device 1510 such as GPS information. One or more parameters of the request may be fixed, while one or more other parameters may be dynamic.

  In one embodiment, before sending the request, the service connector 1516 may query a component (not shown) of the source device 1510 for current location information and / or login information. If the request from the service connector 1516 to the service manager 1536 does not have login information, the corresponding value of the login information may be “Unknown”. If the service connector 1516 does not have access to the current location of the source device 1510 on Saturday, a request from the service connector 1516 to the service manager 1536 may indicate “unknown” for the location information. The request may specify the service type that the source device 1510 is looking for. For example, the request may indicate printing, scanning, faxing, archiving, etc. If the service type is not specified, the default service type may be “Any”.

  Service connector 1516 may initiate a request when service connector 1516 (or another component of service device 1510) detects a new network. A “new” network may be a network that service connector 1516 has never detected before. Alternatively, a “new” network may be a network that service connector 1516 has just detected (eg, in response to a network change) that it has not previously detected.

  Additionally or alternatively, service connector 1516 may initiate requests periodically (eg, every 10 minutes or every hour) regardless of whether a new network is detected.

  The request may be part of a multicast message sent to all devices present in the network. The multicast message notifies the device that the source device 1510 is looking for available services.

  Additionally or alternatively, service connector 1516 initiates a request in response to receiving a HELLO message from a network service 1530 or a component of network service 1530 such as service manager 1536.

  In one embodiment, the network service 1530 listener process may receive the request from the service connector 1516 and determine which component to forward the request to. In one such embodiment, the listener process forwards the request to service manager 1536.

  In step 1620, in response to receiving the request, service manager 1536 sends a location determination request to location manager 1538.

  In step 1630, in response to receiving the position determination request, the position manager 1538 determines the position of the source device 1510 and returns position data indicating the position to the service manager 1536. The current location of the source device 1510 may be determined based on the location information indicated in the original request from the service connector 1516.

  Alternatively, step 1630 may include the location manager 1538 communicating with the source device 1510 (or more specifically, the service connector 1516) regarding its current location. For example, step 1630 may include transmitting GPS or other location related information to location manager 1538.

  Regardless of how location manager 1538 determines the current location of source device 1510, location manager 1538 uses the location information received from source device 1510 to identify the region containing the location of source device 1510. For example, the location information from the source device 1510 may be specific geographic coordinates. On the other hand, the area identified by the position manager 1538 may have an approximately defined geographic area that includes square miles. Accordingly, the location manager 1538 can identify the geographic location (eg, “IN_RANGE ('NEW_YORK_STATE')” and “AROUND ('43 .43669965252182 ','-75.9044541015625 ', 30)” as a location identifier (eg, “US / May hold a mapping that is assigned to “NY” or “US / NY / office02”). The functions “IN_RANGE” and “AROUND” are either labels (in the case of “IN_RANGE” or geography in the case of “AROUND”). Takes input (such as coordinates and radius) and returns a Boolean value, true or false, so that the region identified by location manager 1538 is mapped to a label recognizable by policy manager 1540. If the region cannot be identified, the location of the source device 1510 may be considered “unknown”.

  In step 1640, in response to receiving location data from location manager 1538, service manager 1536 sends source device related data to policy manager 1540. The source device related data may indicate a service type identifier, an operation identifier, and a location of a requesting device (that is, the source device 1510 in this example). In this example, the service type identifier is “print”. The operation identifier may identify the type of operation that the service connector 1516 is requesting. In this example, the operation is serviceDiscovery (). Another example of the operation may include an operation of executing a printing function, displaying an image / moving image file on a display device, and displaying a document list. Further, in this example, the source device related data does not have a user or group identifier. This occurs when the source device 1510 is a mobile device (such as a laptop, tablet computer or smartphone) and the source device 1510 detects a network that has not been previously detected or registered. obtain.

  For example, a business traveler with a tablet computer enters an office building that has never been entered before and starts one or more documents from his / her tablet computer before starting a meeting in a meeting room in the office building. You may want to print. Business travelers find a printing device that can be used to operate a tablet computer and perform printing. A network service (such as network service 1530) causes the tablet computer to print (or identify) a limited set of printers. For example, some printers may be in the same subnet as the tablet computer, but for various reasons, for example, the network administrator does not know the printers or wants them to be used by temporary users.

  In step 1650, in response to receiving the source device related data, the policy manager 1540 uses the source device related data to identify rules that determine what information should be provided to the source device 1510. The explanation of the rule information is as follows.

<Rule information>
17 and 18 are block diagrams illustrating exemplary associations between actions, users, locations, device attributes, and specific rules, according to one embodiment. A “rule” is an association between one or more sets of conditions and one or more sets of actions. The set of one or more actions of the rule is executed only after all the conditions in the corresponding set of one or more conditions are met. Thus, for example, in the table 1700, the action of the (first) entry or row associated with the rule ID “App1_login_rule_ok” is (1) the action “login ()” is requested, and the action is (2) the application “ Supported by (Application 1) that the user requesting the action is (3) from Group 1 and the user's device is in (4) location US / NY / office 1 or US / NY / office 2 Only executed later. Other rules may have more or less conditions that must be met for the associated action to be performed.

  Alternatively, a rule may be associated with multiple conditions if only one condition (or a narrow subset of conditions) must be met to trigger the execution of the associated action.

  A table 1700 shown in FIG. 17 includes eight fields or columns, that is, an application / service type field, an operation field, a user / group field, an operation device position field, an operation device attribute field, an associated device position field, an associated device attribute field, And a rule ID field. In some embodiments, table 1700 has additional fields. In other embodiments, the table 1700 has fewer fields. For example, if the network service 1530 provides only a single application, or if the rule relates only to a single application hosted by the network service 1530, the application / service type field is optional. As another example, the operating device location field is optional if the location of the user's device is not relevant or important to any rule. As another example, the operating device attribute field is optional if no rule requires that the user's device be authenticated or meet certain criteria.

  The action field of table 1700 contains the name of the action that can be performed by the corresponding application or service. For example, many rules are associated with one or more of the following three operations supported by Application1, namely login (), listDocument (), and print (). A rule is associated with each of the following two operations supported by Application2, namely operation1 () and operation2 (). Application 1 and Application 2 may support other operations that are not associated with any rule. A rule is associated with each of the following three operations supported by the print service: serviceDiscovery (), submitPrintJob (), and cancelPrintJob ().

  Some rules are limited to specific users or user groups. The user / group field specifies a particular user or user group for a given set of one or more rules. However, in some rules, a particular user or group is irrelevant. In such a rule, the user / group field specifies a generic “ANY”.

  The operating device location field indicates the label of the geographic region. The label in the actuator position field may correspond to a position identifier in a position ID field of a different table (not shown). Alternatively, the range definition may be specified in the motion unit location field of table 1700. In such an embodiment, a separate data structure containing location information may not be necessary.

  In one embodiment, instead of a single table 1700, the information contained in the table 1700 is partitioned or divided into multiple tables (or other storage objects). For example, given the information in table 1700, three tables, one for each application or service (ie, Application1, Application2, and Print) may be generated. In these tables, the application / service type field is not required. As another example, a different table is generated for each operation. Therefore, when information in the table 1700 is given, eight tables may be generated in this example. That is, there is one table for each of login (), listDocument (), print (), operation1 (), operation2 (), serviceDiscovery (), submitPrintJob (), and cancelPrintJob ().

  A table 1800 shown in FIG. 18 has two fields or columns, that is, a rule ID field and a rule field. The rule ID field in FIG. 18 corresponds to the rule ID field in FIG. Each rule indicates a set of one or more actions that application1, application2, or service 1522 should perform. For example, the first rule in table 1800 indicates one action or action: “Verify username and password”. The rules in table 1800 may further specify conditions that must be met for the corresponding action to be performed. For example, the rule in table 1800 has an effect of “Show the error message” when the level of the target document is level 1 and an action “when the level of the target document is not level 1”. “Print the document to the printer” may be executed.

  In one embodiment, tables 1700 and 1800 are joined such that table 1700 includes the rule fields of table 1800. In the present embodiment, the rule ID field becomes unnecessary and may be excluded from such a combined table.

  Embodiments are not limited to the method in which rule information is stored. For example, instead of one or more tables, the above-described rule information may be stored in a linked list, a non-relational object set, or a multidimensional array.

  In tables 1700 and 1800, the administrator can define rules that restrict which source devices are allowed access to which network services. For example, a visitor to an office is only allowed to use one specific printer service, while an employee in that office can use all printer services in that office.

<Access management to network service (CONT.)>
In step 1670, service manager 1536 sends the filtered service list to service connector 1516.

  In step 1680, in response to receiving the filtered list, service connector 1516 registers the services in the list by sending the service list to service platform 1514.

  In one embodiment, if any service in the list is in a different subnet than the subnet in which source device 1510 is located, service connector 1516 will provide the service's IP address and the service is hosted on source device 1510. It may be replaced with a dummy address indicating this.

  Thus, in the sequence diagram 1600, even if one or more network services are not hosted by the network service 1530, the source device 1510 is one or more network services (which may or may not be in the same subnet as the source device 1510). Is discovered through the network service 1530. In other words, the source device 1510 does not discover the network service (eg, service 1522) by communicating directly with the target device hosting the network service.

  In a related embodiment, instead of sending a filtered list of currently available services in response to an initial request from service connector 1516, network service 1530 may provide a list of all currently available services. Send to service connector 1516. Accordingly, the service manager 1536 does not request location information from the location manager 1538 or send source device related data to the policy manager 1540. In this way, the application 1512 can “see” all currently available services. This is referred to herein as the “filter second” approach. In contrast, the approach in which source device 1510 receives a filtered list of services in response to an initial request for services is referred to herein as a “filter first” approach.

  In the filter second approach, if the application 1512 requests a service (eg, service 1522) that the administrator of the network service 1530 does not want the source device 1510 (or other “unknown” device) to use, the application 1512 The service request is sent (by service connector 1516) to service manager 1536. The service manager 1536 (1) determines the current location of the source device 1510 (by communicating with the location manager 1538), and (2) sends source device related data to the policy manager 1540. Upon receiving a list of services (eg, printing) from the policy manager 1540 (or identifying the list of print services based on the rule action received from the policy manager 1540), the service manager 1536 may request that the requested service be a service. Determine if it is in the list. In some cases, service manager 1536 causes a service request to be sent to the requested service (eg, service 1522). For example, the service manager 1536 forwards the service request (sent from the service connector 1516) to the service 1522. Service manager 1536 may modify the service request such that service 1522 responds to the service request by addressing source device 1510 (or application 1512).

  If the service manager 1536 determines that the requested service does not exist in the service list, the service manager 1536 does not cause the service request to be sent to the requested service. Alternatively, service manager 1536 may send a response message to source device 1510 indicating that the requested service is not available.

  In the filter second approach, service manager 1536 may act as an intermediary when source device 1510 sends a service request for service 1522 hosted by target device 1520. Accordingly, a service request from source device 1510 is directed (via service connector 1516) to service manager 1536, which forwards the service request to service 1522.

  In the filter first approach, if the target device 1520 is in the same subnet as the source device 1510, a service request from the application 1512 may be sent to the service 1522 without going through the network service 1530. Alternatively, even if the target device 1520 and the source device 1510 are in the same subnet, the network service 1530 may be forced to mediate by changing the service discovery scope of the service platform 1514. Changing the service discovery range includes changing one or more configurations of the service platform discovery operation. The service platform has a service discovery function, and the default service discovery range may be a local subnet. Thus, the service platform automatically discovers services that operate on the same subnet. If the service discovery range is changed from the local subnet to the local device, the service platform 1514 cannot discover the service 1522 in the local subnet. However, the service platform 1514 can discover services that run on the same device.

  If the target device 1520 is in a different subnet than the source device 1510, the network service 1530 acts as an intermediary, the service request from the application 1512 is directed to the service manager 1536, and the service manager 1536 forwards the service request to the service 1522. You may make it do.

<Implementation mechanism>
According to one embodiment of the present invention, the techniques described herein are implemented by one or more special purpose computing devices. A special purpose computing device may be incorporated into the hardware to perform this technology, and one or more application specific integrated circuits (ASICs) or field programmable gates permanently programmed to perform this technology You may have a digital electronic device such as an array (FPGA) with one or more general purpose hardware processors programmed in firmware, memory, other storage or combination according to program instructions to implement this technique. You may do it. Such special purpose computing devices may combine custom hardwired logic, ASIC, or FPGA with custom programming to accomplish this technique. The special purpose computing device may be a desktop computer system, a portable computer system, a handheld device, a network device, or any other device that incorporates hardwired logic and / or program logic to implement this technology.

  FIG. 19 is a block diagram that illustrates an example computer system 1900 upon which an embodiment of the invention may be implemented. Computer system 1900 includes a bus 1902 or other communication mechanism for communicating information, and a processor 1904 coupled with bus 1902 for processing information. Computer system 1900 also has a main memory 1906 that couples to bus 1902 and stores information and instructions to be executed by processor 1904, such as random access memory (RAM) or other dynamic storage elements. Main memory 1906 may be used to store temporary variables or other intermediate information during execution of information to be executed by processor 1904. Computer system 1900 further includes a read only memory (ROM) 1908 or other static storage device coupled to bus 1902 for storing static information and instructions for processor 1904. A storage device 1910, such as a magnetic disk or optical disk, is provided and coupled to the bus 1902 for storing information and instructions.

  Computer system 1900 may be coupled via bus 1902 to a display 1912 that displays information to a computer user, such as a cathode ray tube (CRT). Although the bus 1902 is illustrated as a single bus, the bus 1902 may include one or more buses. For example, bus 1902 may be a control bus where processor 1904 controls other devices in computer system 1900, an address bus where processor 1904 specifies memory locations for instructions for execution, Any other type of bus for transferring signals may be included, but is not limited to these.

  Input device 1914 has alphanumeric and other keys and is coupled to bus 1902 for communicating information and command selections to processor 1904. Another type of user input device is a cursor control 1916, such as a mouse, trackball, or cursor direction key, that communicates direction information and command selections to the processor 1904 and controls the movement of the cursor on the display 1912. This input device typically has two degrees of freedom in two axes, a first axis (eg, X) and a second axis (eg, Y), and allows the device to specify a position in the plane.

  The computer system 1900 combines the techniques described herein with customized hardwired logic, one or more ASICs or FPGAs, a computer system, firmware and / or to make the computer system 1900 an application-specific machine and / or You may implement using program logic or computer software. According to one embodiment of the invention, these techniques are performed by computer system 1900 in response to processor 1904 executing one or more sequences of one or more instructions contained in main memory 1906. . Such instructions may be read into main memory 1906 from another computer readable medium, such as storage device 1910. Execution of the instruction sequence contained in main memory 1906 causes processor 1904 to execute the processing steps described herein. In alternative embodiments, hardwired circuitry may be used instead of or in combination with software instructions that implement the present invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

  The term “computer-readable medium” as used herein refers to any medium that participates in providing data that causes a computer to operation in a specific fashion. In embodiments implemented using computer system 1900, various computer readable media are involved, for example, in providing instructions to processor 1904 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1910. Volatile media includes dynamic storage, such as main memory 1906. Common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, or any other magnetic medium, CD-ROM, any other optical medium, RAM, PROM and EPROM, FLASH-EPROM, It includes any other memory chip or memory cartridge, or any other medium that can be read by a computer.

  Various forms of computer readable media may be involved in communicating one or more sequences of one or more instructions to processor 1904 for execution. For example, the instructions may initially be carried on a remote computer magnetic disk. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 1900 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. The infrared detector receives the data transmitted in the infrared signal and appropriate circuitry can place the data on the bus 1902. The bus 1902 transmits data to the main memory 1906. Instructions received by main memory 1906 from which processor 1904 reads and executes instructions from main memory 1906 may optionally be stored in storage device 1910 either before or after execution by processor 1904.

  Computer system 1900 also includes a communication interface 1918 coupled to bus 1902. Communication interface 1918 provides a two-way data communication coupled to a network link 1922 that is connected to a local network 1920. For example, the communication interface 1918 may be an Integrated Services Digital Network (ISDN) card or modem that provides a data communication connection to a corresponding type of telephone line. As another example, the communication interface 1918 may be a local area network (LAN) card that provides a data communication connection to a compatible LAN. A wireless link may also be implemented. In any such implementation, communication interface 1918 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

  Network link 1920 typically provides data communication through one or more networks to other data devices. For example, the network link 1920 may provide a connection to a host computer 1924 through a local network 1922 or to a data device operated by an Internet Service Provider (ISP) 1926. ISP 1926 also provides data communication services through a worldwide packet data communication network now commonly referred to as the “Internet” 1928. Both the local network 1922 and the Internet 1928 use electrical, electromagnetic or optical signals that carry digital data streams.

  Computer system 1900 can send messages and receive data, including program code, through the network, network link 1920 and communication interface 1918. In the Internet example, the server 1930 may send the requested code for the application program over the Internet 1928, ISP 1926, local network 1922 and communication interface 1918. The received code may be executed by processor 1904 when received by processor 1904 and / or stored in storage device 1910 or other non-volatile storage for later execution.

  In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from embodiment to embodiment. Accordingly, the only indication of the present invention and what is intended to be an invention by the applicant is the set of patents derived from this application, including any future amendments, in the specific form from which the claims are derived It is a claim. Accordingly, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. Accordingly, the specification and accompanying drawings are to be construed as illustrative rather than limiting.

[Related applications]
This application is related to US patent application Ser. Nos. 13 / 467,349 and 13 / 467,356, filed May 5, 2012. The entire contents of these US patent applications are hereby incorporated by reference as if fully set forth herein.

  This application is related to U.S. Patent Application No. xx / xxx, xxx (Attorney Administration No. 49986-0766), named “Managing Access of Network Services”, filed on the same day as this application. The entire contents of this US patent application are hereby incorporated by reference as if fully set forth herein.

110, 120, 150, 610, 650, 710, 1510 Source device 112, 122, 152, 612, 652, 712 Application (App)
114, 124, 134, 144, 154, 164, 614, 654, 634, 664, 714, 724, 734, 744, 754, 1524 Service platform (service PF)
130, 140, 160, 630, 660, 720, 730, 740, 750, 1520 Target device 132, 142, 162, 632, 662, 722, 732, 742, 752, 1522 Service 170, 670 Router 180, 190, 680 , 690, 780, 790 Subnet 200, 300, 1200 Screen 620, 640 Server 716, 726, 746 Service connector 760 Service manager 770, 1550 Network 1530 Network service 1532 Application 1534 User equipment manager 1536 Service manager 1538 Location manager 1540 Policy manager 1902 Bus 1904 Processor 1906 Main memory 1908 ROM
1910 storage device 1912 display 1914 input device 1916 cursor control 1918 communication interface 1920 network link 1922 local network 1924 host 1926 ISP
1928 Internet 1930 server

Claims (4)

Sending a request for service information from a service connector running on a source device to a service manager running on a device different from the source device;
After transmitting the request for service information, a first at the service connector is placed from a service manager on a second subnet different from a first subnet hosted by a target device and on which the source device is located. Receiving first service information indicating a first address of the service;
In response to receiving the first service information, the service connector is
Storing the first service information, the storing step comprising storing an association associating a second address with the first address ;
Transmitting a portion of the first service information to a service platform of the source device;
After transmitting said portion to said service platform of the source device, the service connector,
Receiving a first request to use the first service from an application running on the source device, unlike the service platform , wherein the first request includes the second address; Steps ,
Replacing the second address with the first address by the service connector of the source device;
Sending the first request including the first address to the target device;
And a method executed by one or more computing devices. The first request has an address associated with the target device;
The method of claim 1, wherein the first request is sent to the target device without first being sent to the service manager. One or more storage media carrying instructions, said instructions being executed by one or more processors;
Sending a request for service information from a service connector running on a source device to a service manager running on a device different from the source device;
After transmitting the request for service information, a first at the service connector is placed from a service manager on a second subnet different from a first subnet hosted by a target device and on which the source device is located. Receiving first service information indicating a first address of the service;
In response to receiving the first service information, the service connector
Storing the first service information, the storing step comprising storing an association associating a second address with the first address ;
Transmitting a portion of the first service information to a service platform of the source device;
After transmitting said portion to said service platform of the source device, the service connector,
Receiving a first request to use the first service from an application running on the source device, unlike the service platform , wherein the first request includes the second address; Steps ,
Replacing the second address with the first address by the service connector of the source device;
Sending the first request including the first address to the target device;
One or more storage media that produce The first request has an address associated with the target device;
The one or more storage media of claim 3 , wherein the first request is sent to the target device without first being sent to the service manager.

Images