JP2004252954A - Device, method and program for providing merge information, device, method and program for providing information, device, method and program for management; and recording medium - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To obtain user information on same users who are registered with a provider other than providers to which authentication and/or use are (is) permitted and/or group information on groups which the users belong to without discriminating the users in accordance with the providers to which the authentication and/or the use are (is) permitted. <P>SOLUTION: This merge information providing device has a merged user-information providing means 13 which has a plurality of user information providing means for providing user related information as low-order user information providing means 14. In addition, the users are not discriminated in accordance with the user information providing means to which the use is permitted, and the information is obtained on the users who are registered with other user information providing means as well as the user information providing means to which the use is permitted, and then the information on the users thus obtained is merged and provided to solve the above problem. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

  The present invention relates to a combined information providing device, an information providing device, a management device, a combined information providing method, an information providing method, a managing method, a combined information providing program, an information providing program, a management program, and a recording medium.

  A conventional example in which a user is authenticated by using an authentication provider and a service provided by an application is used will be described with reference to FIG. FIG. 1 is a diagram for explaining an example in which a user is authenticated using an authentication provider and a service provided by an application is used.

  The system shown in FIG. 1 includes a web browser 1, a web portal 2, an application 3, and an authentication directory provider 4.

  The Web browser 1 is software for browsing Web pages.

  The Web portal 2 is a Web site serving as an entrance to the Internet, and is a Web site that provides various Web services that can be used from the Web browser 1.

  The application 3 is one of the services provided by the web portal 2 to the web browser 1.

  The authentication directory provider 4 is a provider that provides authentication of a registered user and information on a group to which the user belongs.

  In step S1, the Web browser 1 transmits the login name and the password input by the user to the Web portal 2.

  Proceeding to step S2 following step S1, the Web portal 2 transmits to the authentication directory provider 4 an authentication ticket creation request described below including the login name and password received in step S1.

  The authentication directory provider 4 determines whether the combination of the registered login name and the password of the registered user is correct based on the login name and the password included in the received authentication ticket creation request, and If it is determined that the combination is correct, an authentication ticket for authenticating this is created.

  Proceeding to step S3 following step S2, the authentication directory provider 4 transmits an authentication ticket creation response including the ID of the created authentication ticket to the Web portal 2.

  Proceeding to step S4 following step S3, the web portal 2 transmits information to the effect that authentication has been successful to the web browser 1.

  Proceeding to step S5 following step S4, the web browser 1 notifies the web portal 2 that the use of the service provided by the application 3 is started.

  Proceeding to step S6 following step S5, the Web portal 2 transmits to the application 3 a request for creating a session ticket permitting use of the service including the ID of the authentication ticket acquired in step S3.

  Proceeding to step S7 following step S6, the application 3 includes the ID of the authentication ticket in order to confirm whether or not the request is a request for creating a session ticket from a valid user who may permit use of the application. An ID confirmation request is transmitted to the directory provider 4.

  Proceeding to step S8 following step S7, the authentication directory provider 4 determines whether the passed authentication ticket ID is a valid authentication ticket ID, and if it determines that the ID is a valid authentication ticket ID, An ID confirmation response including information on the user who created the ID of the authentication ticket is transmitted to the application 3.

  Proceeding to step S9 following step S8, the application 3 determines from the user information acquired in step S8 that the request for creating the session ticket acquired in step S6 is a valid user who may permit use of the application. If the request is determined to be a request from the web portal 2, a session ticket is created, and a session ticket creation response including the session ticket ID is transmitted to the Web portal 2.

  Proceeding to step S10 following step S9, the web portal 2 notifies the web browser 1 that the use of the service is permitted.

  Proceeding to step S11 following step S10, the web browser 1 notifies the web portal 2 that the service provided by the application 3 will be used.

  Proceeding to step S12 following step S11, the Web portal 2 transmits to the application 3 a service use request including the ID of the session ticket acquired in step S9.

  Proceeding to step S13 following step S12, the application 3 determines the validity of the ID of the session ticket included in the service use request, and if it determines that the ID is a valid session ticket, the application 3 displays the specified service on the Web. Send to portal 2.

  Proceeding to step S14 following step S13, the web portal 2 provides the service received in step S13 to the web browser 1.

  As described with reference to FIG. 1, the authentication directory provider 4 creates an authentication ticket for authenticating a registered user based on the user name and the password included in the authentication ticket creation request received from the web portal 2. Then, a response to create an authentication ticket including the ID of the authentication ticket is transmitted to the Web portal 2. Further, the authentication directory provider 4 transmits an authentication ticket ID confirmation response including user information to the application 3 based on the authentication ticket ID included in the authentication ticket ID confirmation request received from the application 3. .

  However, in general, the web portal 2 supports a plurality of applications and a plurality of authentication providers that authenticate users of the applications in order to provide a plurality of web services.

  FIG. 2 is a diagram illustrating an example in which one Web portal supports a plurality of applications and a plurality of authentication directory providers.

  The system shown in FIG. 2 includes a Web browser 1, a Web portal 2, a Windows (registered trademark) application 5, a Notes (registered trademark) application 6, a Windows (registered trademark) authentication directory provider 7, and a Notes (registered trademark). And an authentication directory provider 8.

  2 includes a plurality of applications provided by the Web portal 2 and a plurality of authentication providers for performing authentication of a user of the application as compared with FIG.

  With the configuration shown in FIG. 2, when the user inputs the user name and password registered in the Windows (registered trademark) authentication directory provider 7 into the Web browser 1, the user can enter the Windows (registered trademark) authentication directory. The provider 7 is authenticated as a Windows (registered trademark) user and can use the Windows (registered trademark) application 5.

  When the user inputs the user name and password of the user registered in the Notes (registered trademark) authentication directory provider 8 to the web browser 1, the Notes (registered trademark) authentication directory provider 8 executes the Notes (registered trademark). And is able to use the Notes (registered trademark) application 6.

However, the structure shown in FIG. 2, the Web portal 2, an access module 10 ₁ to access the Windows (registered trademark) authentication directory provider 7, Notes (TM) access module 10 ₂ to access the authentication directory provider 8 and Had to be developed separately, and there was an inefficient problem.

  To solve this problem, a configuration as shown in FIG. 3 is conceivable. FIG. 3 is a diagram for explaining an example in which access modules in a Web portal are integrated into one.

  The system shown in FIG. 3 includes a Web browser 1, a Web portal 2, a Windows (registered trademark) application 5, a Notes (registered trademark) application 6, a Windows (registered trademark) authentication directory provider 7, and a Notes (registered trademark). It comprises an authentication directory provider 8 and a provider 9.

  FIG. 3 is different from FIG. 2 in that a provider 9 is newly provided in order to integrate the access module 10 in the Web portal 2 into one.

  The provider 9 transmits the user name and the password acquired via the web browser 1 and the web portal 2 to the Windows (registered trademark) authentication directory provider 7 and the Notes (registered trademark) authentication directory provider 8, respectively, and authenticates each of them. Request a ticket creation.

  When the provider 9 receives an authentication ticket creation response including the authentication ticket ID from one of the providers, the provider 9 transmits the authentication ticket ID to the Web portal 2.

  With the configuration shown in FIG. 3, the number of access modules 10 of the Web portal 2 can be reduced to one.

  However, when a new application is added to the Web portal 2 in the configuration shown in FIG. 3, for example, Windows (registered trademark) registered in the Windows (registered trademark) authentication directory provider 7 in the newly added application. There is a problem that the user must be distinguished from the Notes (registered trademark) user registered in the Notes (registered trademark) authentication directory provider 8.

  An example in which a new application is added to the configuration of FIG. 3 will be described with reference to FIG.

  FIG. 4 is a diagram for explaining an example in which a new application is added to the configuration of FIG.

  The system in FIG. 4 includes a Web browser 1, a Web portal 2, a Windows (registered trademark) authentication directory provider 7, a Notes (registered trademark) authentication directory provider 8, a provider 9, and an application 11.

  FIG. 4 is different from FIG. 3 in that an application 11 is newly added to the Web portal 2 instead of the Windows (registered trademark) application 5 and the Notes (registered trademark) application 6.

  In such a configuration, for example, a Windows (registered trademark) user whose application 11 is authenticated by the Windows (registered trademark) authentication directory provider 7 is also a Notes (registered trademark) that is authenticated by the Notes (registered trademark) authentication directory provider 8. If it is assumed that both users can be used, the application 11 has to register a user ID for identifying each user and manage two users, which has a problem that management becomes complicated.

  For example, even if a Windows (registered trademark) user and a Notes (registered trademark) user are the same person, and the user uses the same user ID in both Windows (registered trademark) and Notes (registered trademark), In the application 11, there is a problem that the user ID as a Windows (registered trademark) user and the user ID as a Notes (registered trademark) user must be managed separately.

  On the other hand, a configuration in which a Local authentication directory provider 12 is newly introduced in addition to the Windows (registered trademark) authentication directory provider 7 and the Notes (registered trademark) authentication directory provider 8 is also conceivable.

  FIG. 5 is a diagram for explaining an example in which a local authentication directory provider is introduced.

  The system of FIG. 5 includes a Web browser 1, a Web portal 2, a Windows (registered trademark) authentication directory provider 7, a Notes (registered trademark) authentication directory provider 8, a provider 9, an application 11, a Local authentication directory provider. And 12.

  FIG. 5 is different from FIG. 4 in that a local authentication directory provider 12 is newly introduced.

  As shown in FIG. 5, users kana, kurose, maeda, aitoh, ikegami, and rdhguest are registered in the Windows (registered trademark) authentication directory provider 7, and users are registered in the Notes (registered trademark) authentication directory provider 8. kana, kurose, maeda, aitoh, and ikegami are registered.

  In the newly introduced Local authentication directory provider 12, users kana, kurose, maeda, and groups 1 and 2 are registered.

  Hereinafter, an example of the members of the group registered in the local authentication directory provider 12 shown in FIG. 5 will be described with reference to FIG. FIG. 6 is a diagram for explaining an example of a member of a group registered in the local authentication directory provider 12 shown in FIG.

  As shown in FIG. 6, the local authentication directory provider 12 in FIG. 5 holds users and groups in the provider itself as members of the group.

  However, even if the local provider 12 that retains the user or group in the own provider as a member of the group is introduced, the application 11 in FIG. 5 can use the user or group of the local provider 12 or the user of another provider. And groups had to be managed separately.

  Further, in the system shown in the conventional example, for example, when a user inputs a login name and a password via the Web browser 1 and requests authentication, when a user registered with a provider other than the provider that has performed authentication is requested. There was a problem that user information and / or group information to which the user belongs could not be obtained.

  FIG. 7 is a diagram for explaining a problem of a conventional provider. For example, when authentication is performed by the Windows (registered trademark) authentication directory provider 7, information on the user kana registered in the Windows (registered trademark) authentication directory provider 7 and information on the group to which the user kana belongs can be obtained. However, there is a problem that information of the user kana registered in the Notes (registered trademark) authentication directory provider 8 and information of the group to which the user kana belongs cannot be obtained.

  In the conventional example, if authentication is performed by the Windows (registered trademark) authentication directory provider 7, a user of Windows (registered trademark) is authenticated. If authentication is performed by the local authentication directory provider 12, a user of Locals is registered as Notes (registered trademark). If the authentication is performed by the authentication directory provider 8, the user is distinguished by the authentication directory provider that is authenticated even if the user is the same, for example, the user is authenticated as a Notes (registered trademark) user. .

  Further, in the conventional example, an authentication directory in which a Windows (registered trademark), Notes (registered trademark), or Local provider connected to the provider 9 performs both authentication and provision of user information and / or group information to which the user belongs. Although the provider has been described, even if these providers are directory providers that provide user information and / or group information to which the user belongs, usage is based on the login name and password input by the user as described above. There was a problem that the user information of the same user registered in a directory provider other than the permitted directory provider and / or the group information to which the user belongs could not be obtained.

  The present invention has been made in view of the above points, and does not distinguish users by providers who are authorized and / or used, and are registered with providers other than those authorized and / or used. It is also intended to obtain user information of the same user and / or group information to which the user belongs.

  Therefore, in order to solve the above problem, the present invention is a merged information providing apparatus having a merged user information providing means that sets a plurality of user information providing means for providing information about a user as lower order user information providing means, The user information providing means whose use is permitted does not distinguish between users, and information on the user of the same user registered in another user information providing means together with the user information providing means whose use is permitted is obtained. The information related to the acquired user is provided in combination.

  According to the present invention, there is provided a merged information providing apparatus including a merged user information providing unit having a plurality of user information providing units for providing information about a user as lower order user information providing units, wherein the user whose use is permitted is provided. The information providing means does not distinguish the user, and obtains information on the user of the same user registered in the other user information providing means together with the user information providing means permitted to use, and By providing the information in combination, the user is not distinguished by the sub-provider permitted to use, and the user information of the same user registered in a sub-provider other than the sub-provider permitted to use and / or Alternatively, group information to which the user belongs can be obtained.

  The present invention also provides a merged information providing apparatus having merged user information providing means for providing information about a user and providing a plurality of user information providing means for providing an authentication service for the user as lower order user information providing means. The user is not distinguished by the user information providing means for which use is permitted and / or authenticated, and the other user is used together with the user information providing means for which use is permitted and / or authenticated. It is characterized in that information on the user of the same user registered in the information providing means is obtained, and the obtained information on the user is combined and provided.

  According to the present invention, there is provided a merged information providing apparatus having merged user information providing means for providing a plurality of user information providing means for providing information relating to a user and providing an authentication service relating to the user as lower order user information providing means. The user is not distinguished by the user information providing means for which use is permitted and / or authenticated, and the other user is used together with the user information providing means for which use is permitted and / or authenticated. By acquiring the information on the user of the same user registered in the information providing means and providing the acquired information on the user in a merged manner, the user is authorized and / or authenticated by the sub-provider. No distinction, and the user information of the same user registered in a sub-provider other than the sub-provider whose use is permitted and / or authenticated And / or belonging to the group information of the user can also be obtained.

  Also, the present invention provides a merging user information providing unit for providing information about a user and providing an authentication service for the user with a main user information providing unit and a sub user information providing unit as lower order user information providing units. The information providing apparatus, wherein the user information providing means whose use is permitted and / or authenticated is performed without distinguishing a user by the user information providing means whose use is permitted and / or authenticated. And acquiring information on the user of the same user registered in the other user information providing means, and combining and providing the acquired information on the user.

  ADVANTAGE OF THE INVENTION According to this invention, the merging which has the merging user information providing means which makes the main user information providing means and the sub-user information providing means which provide the information about the user and provides the authentication service concerning the user lower order user information providing means The information providing apparatus, wherein the user information providing means whose use is permitted and / or authenticated is performed without distinguishing a user by the user information providing means whose use is permitted and / or authenticated. Together with the information of the same user registered in the other user information providing means, and the combined information on the obtained user is provided, whereby the provider whose use is permitted and / or authenticated is obtained. Is not distinguished between users, and the use of the same user registered with a provider other than the provider whose use is permitted and / or authorized Member information of over The information and / or the user can also be obtained.

  Further, the present invention is an information providing apparatus having a user information providing unit for providing information on a user, wherein the user information providing unit is configured to provide the user information providing unit and other user information providing units with lower user information. In response to a request from the combined user information providing means serving as the providing means, information relating to a user corresponding to identification information for identifying a user registered in the user information providing means and / or another user information providing means is provided. The apparatus further comprises a user information providing unit for providing the combined user information providing unit.

  According to the present invention, there is provided an information providing apparatus having a user information providing unit for providing information about a user, wherein the user information providing unit is configured to set the user information providing unit and other user information providing units to lower-level user information. In response to a request from the combined user information providing means serving as the providing means, information relating to a user corresponding to identification information for identifying a user registered in the user information providing means and / or another user information providing means is provided. By having the user information providing means for providing the combined user information providing means, it is possible to provide the information on the user of the corresponding identification information to the combined user information providing means in response to a request.

  Further, the present invention is an information providing apparatus having user information providing means for providing information about a user and providing an authentication service for the user, wherein the user information providing means comprises the user information providing means and another In response to a request from the merged user information providing means, wherein the user information providing means is a lower-level user information providing means, identification information for identifying a user registered in the user information providing means and / or another user information providing means. And a user information providing means for providing information on a user corresponding to the above to the combined user information providing means.

  According to the present invention, there is provided an information providing apparatus having user information providing means for providing information about a user and providing an authentication service for the user, wherein the user information providing means includes the user information providing means and another In response to a request from the merged user information providing means, wherein the user information providing means is a lower-level user information providing means, identification information for identifying a user registered in the user information providing means and / or another user information providing means. Having the user information providing means for providing the information relating to the user corresponding to the above to the combined user information providing means, providing the information relating to the user of the corresponding identification information to the combined user information providing means in response to a request can do.

  Further, the present invention is characterized in that the merged information providing device includes a setting request transmitting unit that transmits a request related to setting of the lower-level user information providing unit.

  According to the present invention, the setting of the lower-level user information providing means is provided by having the setting information transmitting means for transmitting the request relating to the setting of the lower-level user information providing means to the merged information providing apparatus. Can be changed or newly added.

  The usage permission information described in the claims corresponds to, for example, the session ticket 300 of the sub-provider 14 or the session ticket ID 310 of the session ticket 300.

  The first authentication information described in the claims corresponds to, for example, the authentication ticket 600 of the main sub-provider or the authentication ticket ID 610 of the authentication ticket 600.

  The second authentication information described in the claims corresponds to, for example, the authentication ticket 500 of the Join merge provider 13 or the authentication ticket ID 510 of the authentication ticket 500.

  Further, as other means, a combined information providing method, an information providing method, a managing method, a combined information providing program, an information providing program, a management program, and a recording medium may be used.

  According to the present invention, the user is not distinguished by the provider permitted to be authenticated and / or used, and the user information of the same user registered in a provider other than the provider permitted to be authenticated and / or used, and And / or group information to which the user belongs can also be obtained.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 8 is a diagram for explaining an example in which a Join merge provider according to the present invention is introduced.

  The system of FIG. 8 includes a Web browser 1, a Web portal 2, a Windows (registered trademark) authentication directory provider 7 as a sub-sub-provider, a Notes (registered trademark) authentication directory provider 8 as a sub-sub-provider, and an application 11 , A local authentication directory provider 12 as a main sub-provider, and a join merge provider 13.

  In FIG. 8, a Join merge provider 13 is newly introduced instead of the provider 9 of FIG. 5 described in the related art.

  As shown in FIG. 8, the Join merge provider 13 includes an integrated directory 180 described later.

  In the following, for the sake of simplicity, the main sub-provider and the sub-sub-provider are also simply referred to as sub-providers.

  Hereinafter, an example of the members of the group registered in the local authentication directory provider 12 shown in FIG. 8 will be described with reference to FIG. FIG. 9 is a diagram for explaining an example of members of a group registered in the local authentication directory provider shown in FIG.

  As shown in FIG. 9, the local authentication directory provider 12 of FIG. 8 holds users and groups of other providers as members of the group of the local authentication directory provider 12.

  Therefore, the group group 1 of the local authentication directory provider 12 illustrated in FIG. 8 includes, for example, the user kana of the Windows (registered trademark) authentication directory provider 7, the user maeda of the Windows (registered trademark) authentication directory provider 7, and Notes (registered). (Trademark) The user kana of the authentication directory provider 8 is a member.

  Further, the local authentication directory provider 12 shown in FIG. 8 holds user information of another provider as a user ID.

  Hereinafter, an example of the structure of the user ID of the local authentication directory provider 12 shown in FIG. 8 will be described with reference to FIG. FIG. 10 is a diagram for explaining an example of the structure of the user ID of the local authentication directory provider shown in FIG.

  As shown in FIG. 10A, the user ID of the local authentication directory provider 12 in FIG. 8 includes an ID type, an identifier of the authenticated provider, and an identifier of the user in the authenticated provider.

  The ID type indicates a user or a group, and the identifier of the provider that has performed authentication indicates, for example, Windows (registered trademark), Notes (registered trademark), or the like. Further, the identifier of the user in the provider that has performed the authentication represents, for example, kana, kurose, or maeda.

  FIG. 10B is an example of the user ID in FIG. The local authentication directory provider 12 holds a user ID as shown in FIG. 10 (B) so that, for example, a user of the Windows (registered trademark) authentication directory provider 7 and a user of the Notes (registered trademark) authentication directory provider 8 can communicate with each other. Can be registered in a distinguished form.

  As described later, the Join merge provider 13 according to the present invention distinguishes users according to sub-providers permitted to use, when users registered as users of different sub-providers are the same user. Instead, the user information of the user and / or the group information to which the user belongs can be obtained, merged and provided to the client.

  In addition, the Join merge provider 13 according to the present invention, when the sub-provider is a provider that provides registered user information and / or group information to which the user belongs and provides an authentication service for the user, Even if the authenticated sub-provider is the sub-sub-provider, the user can be authenticated as a user of the main sub-provider by the login name and the password input by the user.

  Therefore, by responding to the user ID of the main sub-provider, the application 11 can handle users of other sub-providers in an integrated manner without separately managing them.

  Hereinafter, an example of an apparatus that implements the Join merge provider 13 and / or sub-provider shown in FIG. 8 will be described with reference to FIG.

  FIG. 11 is a configuration diagram of an embodiment of the multifunction peripheral according to the present invention. The multifunction peripheral 120 is configured to include a monochrome line printer 15, a color line printer 16, hardware resources 17 such as a scanner and a facsimile, a software group 20, and a multifunction peripheral starting unit 50. Further, the software group 20 is configured to include the application 30 and the platform 40.

  The platform 40 interprets a processing request from the application 30 to generate a hardware resource acquisition request, and a system resource that manages one or more hardware resources and arbitrates the acquisition request from the control service. It is configured to have a manager (hereinafter, referred to as SRM) 43 and an operating system (hereinafter, referred to as OS) 41.

  The control services include a system control service (hereinafter, referred to as SCS) 42, an engine control service (hereinafter, referred to as ECS) 44, a memory control service (hereinafter, referred to as MCS) 45, an operation panel control service (hereinafter, referred to as OCS) 46, and a fax machine. It is configured to have one or more service modules such as a control service (hereinafter, referred to as FCS) 47, a network control service (hereinafter, referred to as NCS) 48, and a user information management service (hereinafter, referred to as UCS) 49.

  Note that the platform 40 is configured to have an application program interface (hereinafter, referred to as an API) that enables a processing request from the application 30 to be received by a predefined function.

  The OS 41 is an operating system such as UNIX (registered trademark), and executes each software of the platform 40 and the application 30 in parallel as a process.

  The process of the SRM 43 controls the system and manages resources together with the SCS 42. For example, the process of the SRM 43 uses an engine such as a scanner unit and a printer unit, a memory, a hard disk device (HDD) file, and a host I / O (centro interface, network interface, IEEE 1394 interface, RS232C interface, etc.) that uses hardware resources. Arbitration is performed according to a request from the layer, and execution control is performed.

  For example, the SRM 43 determines whether the requested hardware resource is available (whether the requested hardware resource is not used by another request), and if it is available, the fact that the requested hardware resource is available. To the upper layer. The SRM 43 also schedules the use of hardware resources in response to requests from upper layers, and directly implements, for example, paper transport and image forming operations by a printer engine, memory reservation, and file generation.

  The process of the SCS 42 performs application management, operation unit control, system screen display, LED display, resource management, and interrupt application control. The process of the ECS 44 controls the engines of the monochrome line printer 15, the color line printer 16, and the hardware resources 17.

  The process of the MCS 45 performs acquisition and release of an image memory, use of a hard disk device (HDD), compression and decompression of image data, and the like. The process of the OCS 46 controls an operation panel serving as information transmission means between the operator and the main body control.

  The FCS 47 process includes facsimile transmission / reception using PSTN or ISDN from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, fusion transmission / reception. Provide an application to do.

  The process of the NCS 48 provides a service that can be used in common to applications that require network I / O, and distributes data received from the network by each protocol to each application, and distributes data from the application. Intermediary when sending to the network side.

  The process of the UCS 49 manages the user information and / or the group information to which the user belongs, and stores the user information and / or the group information to which the user belongs according to the request. Of other devices connected via the network, and obtains user information and / or group information to which the user belongs from the determined storage device and / or other devices connected via the network, and supplies them to each application. I do.

  Further, the process of the UCS 49 may manage user information and / or group information to which the user belongs, and may provide an authentication service for the user.

  The Join merge provider 13 and / or other sub-providers (for example, the Local authentication directory provider 12) described in FIG.

  The application 30 performs processing unique to a user service related to image forming processing such as printer, copy, facsimile, and scanner. The application 30 includes a printer application 31 that is a printer application having a page description language (PDL, PCL) and PostScript (PS), a copy application 32 that is a copy application, and a fax application 33 that is a facsimile application. , A scanner application 34 as a scanner application, a network file application 35 as a network file application, and a process inspection application 36 as a process inspection application.

  The multifunction peripheral activation unit 50 is first executed when the power of the multifunction peripheral 120 is turned on, and activates the application 30 and the platform 40. For example, the multifunction peripheral starting unit 50 reads a program of a control service or an application from a flash memory to be described later, and transfers each read program to a memory area secured in an SRAM or an SDRAM to be started.

  FIG. 12 shows a hardware configuration diagram of an embodiment of the multifunction peripheral according to the present invention. 12 includes a controller board 60, an operation panel 70, a fax control unit (hereinafter, referred to as FCU) 80, a USB device 90, an IEEE 1394 device 100, a driver I / F 101, and an engine unit 110. It is comprised so that it may have.

  Here, the driver I / F 101 corresponds to the Join merge provider 13 and / or the sub-provider 14 from a recording medium in which the inserted program corresponding to the Join merge provider 13 and / or the sub-provider 14 is stored. This is an I / F used to read a program or the like and mount it on the MFP 120. In addition, as a recording medium, there are an SD memory card, a smart media, a multimedia card, a compact flash (registered trademark), and the like.

  The operation panel 70 is directly connected to the ASIC 62 of the controller board 60. The FCU 80, the USB device 90, the IEEE 1394 device 100, the driver I / F 101, and the engine unit 110 are connected to the ASIC 62 of the controller board 60 by a PCI (Peripheral Component Interconnect bus) or the like.

  Further, the controller board 60 is configured to include a CPU 61, an ASIC 62, an SRAM (Static RAM) 63, an SDRAM (Synchronous DRAM) 64, a flash memory 65, and an HDD 66. The controller board 60 is configured to connect the CPU 61, the SRAM 63, the SDRAM 64, the flash memory 65, the HDD 66, and the like to the ASIC 62.

  The CPU 61 controls the entire MFP 120. The CPU 61 activates and executes the SCS 42, the SRM 43, the ECS 44, the MCS 45, the OCS 46, the FCS 47, and the NCS 48 that form the platform 40 on the OS 41 as processes, and executes the printer application 31, the copy application 32, and the fax application that form the application 30. 33, the scanner application 34, the net file application 35, and the process inspection application 36 are activated and executed.

  The ASIC 62 is an IC for image processing that has a hardware element for image processing. A virtual memory area such as a kernel or a process is mapped to a physical memory area of the SRAM 63 and the SDRAM 64.

  Hereinafter, a configuration example of the UCS 49 will be described with reference to FIGS. FIG. 13 is a diagram (part 1) for explaining the configuration of the UCS.

  As shown in FIG. 13, the UCS 49 includes the Join merge provider 13 shown in FIG.

  With the configuration shown in FIG. 13, the UCS 49 integrates the user information of the same user provided by the sub-provider 14 and / or the group information to which the same user belongs in the Join merge provider 13, as described later, The merged user information and / or the group information to which the user belongs can be provided to the application 30 of the multifunction peripheral 120 or the like.

  FIG. 14 is a diagram (part 2) for describing the configuration of the UCS. As shown in FIG. 14, the UCS 49 does not include the sub-provider 14 and includes only the Join merge provider 13 of FIG. 8.

  By adopting the configuration shown in FIG. 14, for example, the merge information of the same user and / or the group information to which the same user belongs provided by the sub-provider 14 mounted on another device is merged by the Join merge provider 13, For example, the merged user information of the same user and / or the group information to which the same user belongs can be provided to the application 30 of the multifunction peripheral 120 or the like.

  FIG. 15 is a diagram (part 3) for explaining the configuration of the UCS. As shown in FIG. 15, the UCS 49 does not include the Join merge provider 13 of FIG. 8 and includes at least one or more sub-providers 14.

  With the configuration shown in FIG. 15, for example, it is possible to provide the user information of the same user and / or the group information to which the same user belongs in response to a request from the Join merge provider 13 mounted on another device. it can.

  Hereinafter, for simplification of the description, the description will be made using the Join merge provider 13 and the sub-provider 14.

  FIG. 16 is a functional block diagram of the Join merge provider and the sub provider in the first embodiment of the present invention.

  In the first embodiment, for simplification of description, the Join merge provider 13 and the sub-provider 14 provide user information and / or group information to which the user belongs, and do not authenticate the user. I do.

  As shown in FIG. 16, the Join merge provider 13 includes a provider I / F 130, a merge processing unit 133, a sub-provider calling unit 134, a merge provider XML processing unit 135, a sub-provider registration unit 136, and a session management unit 137. And an integrated directory 180.

  The provider I / F 130 includes an XML processing unit 131 and a UID conversion unit 132.

  The provider I / F 130 is an interface that connects the Join merge provider 13 with another provider and / or another application. As will be described later, the sub-provider 14 also has a similar provider I / F 130.

  The XML processing unit 131 analyzes an XML message transmitted from another application, a Web portal, or the like, and processes the XML message so that the program can be used in the Join merge provider 13.

  Conversely, it creates an XML message based on the data passed from the UID conversion unit 132 and sends it to an application or a Web portal.

  The application or the Web portal may be the application 30 described with reference to FIG. 11, or may be an application of another MFP 120 or another device connected to the MFP 120 via a network. Good.

  The UID conversion unit 132 converts the UID included in the XML message if necessary.

  For example, if the UID included in the XML message has the configuration of U: Windows (registered trademark): kana described in FIG. 7 of the related art, and the configuration of the UID inside the provider is kana, the UID conversion is performed. The unit 132 converts the UID from U: Windows (registered trademark): kana to kana. Similarly, in the case where an XML message is transmitted from a provider, if necessary, conversion of UID from kana to U: Windows (registered trademark): kana is also performed.

  The merge processing unit 133 merges the user information of the user registered in the sub-provider 14 and / or the group information to which the user belongs, as described later.

  The sub-provider calling unit 134 passes data necessary for creating an XML message to be transmitted to the sub-provider 14 to a merge provider XML processing unit 135 described later. For example, the sub-provider calling unit 134 specifies the UID, acquires the UID of the same user from the integrated directory 180 described later, and passes the information of the acquired UID to the merge provider XML processing unit 135 described later.

  Further, the sub-provider calling unit 134 passes the user information and / or the group information to which the user belongs from the sub-provider 14 to the merge processing unit 133 via a merge provider XML processing unit 135 described later.

  The merge provider XML processing unit 135 creates an XML message based on the data passed from the sub-provider calling unit 134 and transmits the XML message to the specified sub-provider 14.

  Further, the merge provider XML processing unit 135 receives the XML message transmitted from the sub provider 14 and passes the data included in the XML message to the sub provider calling unit 134.

  In the sub-provider registration unit 136, data on the sub-provider 14 to be managed is registered. In the sub-provider registration unit 136, for example, the identifier of the sub-provider 14, the name of the sub-provider 14, the management ID of the sub-provider 14, the management password of the sub-provider 14, and the like are registered for each sub-provider 14.

  For example, when registering a new sub-provider 14 in the Join merge provider 13, the identifier of the sub-provider 14, the name of the sub-provider 14, the management ID of the sub-provider 14, and the management password of the sub-provider 14 are respectively registered in the sub-provider. Register in the registration unit 136.

  The session management unit 137 manages a session between the Join merge provider 13 and other sub-providers 14, other applications, a Web portal, and the like.

  For example, it analyzes whether or not the XML message acquired by the XML processing unit 131 includes the session ticket ID 210 of the valid session ticket 200 permitted to use the Join provider 13.

  In addition, the session management unit 137 uses the management ID of the sub-provider 14 registered in the sub-provider registration unit 136 and the management password of the sub-provider 14 to send a session ticket of the anonymous session ticket 300 from the sub-provider 14. The ID 310 is obtained.

  Using the acquired session ticket ID 310 of the sub-provider 14 and the like, the session management unit 137 creates a session ticket 200 of the Join merge provider 13 described later.

  The integrated directory 180 integrates and manages user IDs (hereinafter referred to as UIDs) of the sub-providers 14. As described above, in response to the request from the sub-provider calling unit 134, the integrated directory 180 provides the UID of the same user as the designated user to the sub-provider calling unit 134.

  The session management unit 137 can also obtain the session ticket ID 310 of the anonymous session ticket 300 from a sub-provider 14 other than the sub-provider 14 from which the user has requested the creation of the session ticket 400 using the user name and the password.

  Further, the integrated directory 180 can provide the same UID as the designated user.

  Therefore, the Join merge provider 13 can acquire user information of the same user and / or group information to which the user belongs from different sub-providers 14 using the UID.

  FIG. 17 is a conceptual diagram illustrating the structure of a session ticket of a Join merge provider.

  As shown in FIG. 17, the session ticket 200 of the Join merge provider 13 includes a session ticket ID 210, a provider type, a provider name to be published, one or more sub-provider names, and a session ticket of one or more sub-providers. 300 and / or a session ticket 400 as a structure.

  The session ticket ID 210 is an identifier for identifying the session ticket. The provider type is a type of the provider such as “Join Merge”.

  The provider name to be published is the name of the Join merge provider 13 to be published, such as “Join Merge 1”.

  The sub-provider name is the name of one or more registered sub-providers 14. In the session ticket of the sub-provider, the session ticket 300 and / or the session ticket 400 between the registered one or more sub-providers 14 and the Join merge provider 13 are stored.

  Also, the session ticket 400 is a session ticket of the sub-provider 14 created based on the user name and the password input by the user, and the session ticket 300 is the administrator authority stored in the sub-provider registration unit 136. Is a session ticket of the sub-provider 14 created based on the management ID and the management password.

  In the following, for simplification of the description, the description will be made assuming that the session ticket of the sub-provider 14 included in the session ticket 200 of the Join merge provider 13 is only the anonymous session ticket 300.

  By having a hierarchical structure as shown in FIG. 17, the sub-provider 14 can also become the Join merge provider 13.

  In FIG. 17, an example in which the session ticket 300 of the registered one or more sub-providers 14 and / or the session ticket 400 of the Join merge provider 13 is stored in the session ticket of the sub-provider is shown. Although the description has been made with reference to the above, the decoded session ticket 300 and / or session ticket 400 may be stored.

  16 includes a provider I / F 130, a directory operation wrapper 141, and a session management unit 142.

  The directory operation wrapper 141 stores data in the sub-provider 14 into user information stored in the user information storage unit 152 of the directory 150 and data that can be operated on group information to which the user belongs stored in the group information storage unit 153. To obtain the user information and the group information to which the user belongs from the directory 150.

  In addition, the acquired user information and group information are transformed into data that can be processed in the sub-provider 14.

  An example of a modification of the data of the directory operation wrapper 141 will be described with reference to FIG.

  The session management unit 142 manages a session between the sub provider 14 and the Join merge provider 13.

  For example, the session management unit 142 analyzes whether or not the XML message acquired by the XML processing unit 131 includes the session ticket ID 310 of the valid session ticket 300 for which use of the sub provider 14 is permitted.

  Further, when the session management unit 142 acquires a request for creating an anonymous session ticket 300 including a management ID and a management password from the Join merge provider 13 via the provider I / F 130, the session management unit 142 creates the anonymous session ticket 300. .

  In addition, the session management unit 142 passes the session ticket ID 310 of the created anonymous session ticket 300 to the provider I / F 130, and transmits a creation response of the anonymous session ticket 300 including the session ticket ID 310 to the Join merge provider 13.

  The directory 150 in FIG. 16 includes a user information storage unit 152 and a group information storage unit 153.

  The user information storage unit 152 stores user information of users registered in the sub-provider 14. For example, a UID, a user name, a user password, and the like are stored.

  Further, the group information storage unit 153 stores group information to which a user registered with the sub-provider 14 belongs. For example, a group ID, a group name, a group member, and the like are stored.

  FIG. 18 is a diagram illustrating an example of a modification of data of the directory operation wrapper.

  FIG. 18A shows that the data in the sub-provider 14 can be operated by the user information stored in the user information storage unit 152 of the directory 150 and the group information to which the user belongs stored in the group information storage unit 153. It is an example transformed into data.

  FIG. 18B shows that the data of the user information stored in the user information storage unit 152 of the directory 150 and the data of the group to which the user belongs stored in the group information storage unit 153 can be processed in the sub provider 14. It is an example transformed into data.

  FIG. 19 is a flowchart of an example of a process of acquiring a group to which a user belongs in a Join merge provider.

  In the following, for the sake of simplicity, an application or a Web portal that transmits a request for acquiring group information to which a user belongs to the Join merge provider 13 is simply referred to as a client.

  In step S20, the XML processing unit 131 of the Join merge provider 13 receives a request to acquire the group to which the user belongs from the client.

  An example of a group acquisition request from the client to the Join merge provider 13 will be described with reference to FIG. 21 described later.

  Proceeding to step S21 following step S20, the session management unit 137 determines that the session ticket ID 210 of the session ticket 200 of the join merge provider 13 included in the acquisition request of the group to which the user belongs received in step S20 is a valid session ticket ID 210. Determine if there is.

  If it is determined that it is the session ticket ID 210 of the valid session ticket 200 (YES in step S21), the process proceeds to step S22, and if it is determined that it is the session ticket ID 210 of the invalid session ticket 200 (NO in step S21), the process proceeds to step S27. move on.

  In step S22, the sub-provider calling unit 134 acquires, from the integrated directory 180, the UID in the sub-provider 14 of the same user as the UID included in the acquisition request of the belonging group of the user received in step S20.

  Proceeding to step S23 following step S22, the sub-provider calling unit 134 manages the session ticket IDs 310 and the sub-provider names of the session tickets 300 of all the sub-providers 14 included in the session ticket 200 of the Join merge provider 13. It is obtained from the unit 137.

  Proceeding to step S24 following step S23, the merge provider XML processing unit 135 includes the UID of the sub provider 14 and the session ticket ID 310 of the session ticket 300 of the sub provider 14 acquired through the sub provider calling unit 134. A request to acquire the group to which the user belongs to the sub-provider 14 is created and transmitted to each sub-provider 14.

  An example of a group acquisition request from the join merge provider 13 to each sub provider 14 will be described with reference to FIGS.

  Proceeding to step S25 following step S24, the sub-provider calling unit 134 receives a belonging group acquisition response to the user's belonging group acquisition request from each sub-provider 14 via the merge provider XML processing unit 135.

  An example of a group acquisition response from each sub provider 14 to the Join merge provider 13 will be described with reference to FIGS. 25 to 27 described later.

  Proceeding to step S26 following step S25, the sub-provider calling unit 134 determines whether the belonging group acquisition response from each sub-provider 14 received in step S24 includes the belonging group information of the user of the specified UID. judge.

  If it is determined that at least one user's belonging group information is included (YES in step S26), the process proceeds to step S28, and if it is determined that no user's belonging group is included (NO in step S26), the process proceeds to step S28. Proceed to S27.

  In step S27, the XML processing unit 131 of the Join merge provider 13 creates a response indicating that acquisition of the group to which the user belongs has failed, and transmits the response to the client.

  In step S28, the merge processing unit 133 merges the belonging groups of the same user included in the belonging group acquisition response from each sub provider 14 acquired in step S25.

  Proceeding to step S29 following step S28, the XML processing unit 131 of the Join merge provider 13 creates a belonging group acquisition response including the information of the belonging group of the same user merged in step S28, and transmits it to the client.

  An example of the group acquisition response from the Join merge provider 13 to the client will be described with reference to FIG. 28 described later.

  FIG. 20 is a flowchart of an example of a process of acquiring a group to which a user belongs in a sub provider.

  When the Join merge provider 13 transmits a request to acquire a group to which a user belongs to each sub-provider 14 in step S24 of FIG. 19, the sub-provider 14 starts processing from step S30 described below.

  In step S30, the XML processing unit 131 of the sub provider 14 receives a request to acquire the group to which the user belongs from the join merge provider 13.

  As described above, an example of a group acquisition request from the join merge provider 13 to each sub provider 14 will be described with reference to FIGS.

  Proceeding to step S31 following step S30, the UID conversion unit 132 of the sub-provider 14 converts the UID included in the user's belonging group acquisition request received in step S30 into a UID unique to the directory 150.

  Proceeding to step S32 following step S31, the session management unit 142 checks the session of the session ticket 300 in which the session ticket ID 310 of the session ticket 300 of the sub-provider 14 included in the request to acquire the group to which the user belongs received in step S30. It is determined whether the ticket ID is 310.

  If it is determined that the session ticket ID is 310 for the valid session ticket 300 (YES in step S32), the process proceeds to step S34. If it is determined that the session ticket ID 310 is for the invalid session ticket 300 (NO in step S32), the process proceeds to step S33. move on.

  In step S33, the XML processing unit 131 of the sub-provider 14 creates a belonging group acquisition response indicating that acquisition of the belonging group of the user has failed, and transmits the response to the Join merge provider 13.

  In step S34, the sub provider 14 acquires the group information to which the user corresponding to the UID converted in step S31 belongs from the directory 150 via the directory operation wrapper 141.

  Proceeding to step S35 following step S34, the UID conversion unit 132 of the sub provider 14 converts the UID unique to the directory 150 into a UID that can be used by the join merge provider 13.

  Proceeding to step S36 following step S35, the XML processing unit 131 of the sub provider 14 creates a belonging group acquisition response including the information of the belonging group of the user, and transmits the response to the Join merge provider 13.

  As described above, an example of the group acquisition response from each sub provider 14 to the Join merge provider 13 will be described with reference to FIGS. 25 to 27 described later.

  Step S25 in FIG. 19 receives the belonging group acquisition response transmitted in step S33 or step S36 in FIG.

  FIG. 21 is an XML message as an example of a group acquisition request from a client to a Join merge provider.

  As shown in FIG. 21, in the request to obtain the group to which the user belongs from the client to the Join merge provider 13, the <sessionTicket> <// sessionTicket> tag includes the session ticket ID 210 of the session ticket 200 of the Join merge provider 13. include.

  The tag of <id> </ id> includes a UID for specifying the user.

  The Join merge provider 13 receives, from the client, a group acquisition request to which the user belongs, including the UID of the user and the session ticket ID 210 of the session ticket 200 of the Join merge provider 13.

  FIG. 22 is an XML message as an example of a group acquisition request from the Join merge provider to the Local directory provider, which is one of the sub-providers.

  FIG. 22A is an XML message (part 1) of a group acquisition request from the Join merge provider 13 to the Local directory provider 160, which is one of the sub-providers 14.

  As shown in FIG. 22A, a request to acquire a group to which a user belongs from the join merge provider 13 to the local directory provider 160 includes a <sessionTicket> <// sessionTicket> tag and a session ticket of the local directory provider 160. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is the same as the UID included in the XML message in FIG.

  FIG. 22B is an XML message (No. 2) of the group acquisition request from the Join merge provider 13 to the Local directory provider 160 which is one of the sub-providers 14.

  As shown in FIG. 22B, a request to obtain a group to which a user belongs from the join merge provider 13 to the local directory provider 160 includes a <sessionTicket> <// sessionTicket> tag and a session ticket of the local directory provider 160. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  FIG. 22C is an XML message (part 3) of a group acquisition request from the Join merge provider 13 to the Local directory provider 160, which is one of the sub-providers 14.

  As shown in FIG. 22C, a request to acquire a group to which a user belongs from the join merge provider 13 to the local directory provider 160 includes a tag <sessionTicket> </ sessionTicket> with a session ticket of the local directory provider 160. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  As described with reference to FIG. 17, the join merge provider 13 manages the session ticket in a hierarchical structure, and therefore, the session ticket 200 of the join merge provider 13 included in the user group acquisition request transmitted from the client. , The session ticket ID 310 of the session ticket 300 of the local directory provider 160, which is the sub-provider 14, can be acquired, and the session ticket ID 310 can be included in the XML message for each.

  Also, since the Join merge provider 13 integrates and manages the UIDs of the users in the sub-provider 14 in the integrated directory 180, the Join merge provider 13 assigns the UIDs of the same user based on the UIDs included in the user group acquisition request. The UID can be obtained from the integrated directory 180 and included in the XML message for each.

  FIG. 23 shows an XML message as an example of a group acquisition request from a Join merge provider to a WinNT4 directory provider, which is one of the sub-providers.

  FIG. 23A is an XML message (part 1) of a group acquisition request from the Join merge provider 13 to the WinNT4 directory provider 161 which is one of the sub-providers 14.

  As shown in FIG. 23A, the acquisition request of the group to which the user belongs from the Join merge provider 13 to the WinNT4 directory provider 161 includes a <sessionTicket> <// sessionTicket> tag and a session ticket of the WinNT4 directory provider 161. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is the same as the UID included in the XML message in FIG.

  FIG. 23B is an XML message (No. 2) of the group acquisition request from the Join merge provider 13 to the WinNT4 directory provider 161 which is one of the sub-providers 14.

  As shown in FIG. 23B, in the request for acquiring the group to which the user belongs from the Join merge provider 13 to the WinNT4 directory provider 161, the tag of <sessionTicket> <// sessionTicket> includes the session ticket of the WinNT4 directory provider 161. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  FIG. 23C is an XML message (part 3) of a group acquisition request from the Join merge provider 13 to the WinNT4 directory provider 161 which is one of the sub-providers 14.

  As shown in FIG. 23C, a request to acquire a group to which a user belongs from the Join merge provider 13 to the WinNT4 directory provider 161 includes a <sessionTicket> </ </ sessionTicket> tag and a session ticket of the WinNT4 directory provider 161. 300 session ticket IDs 310 are included.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  As described with reference to FIG. 17, the join merge provider 13 manages the session ticket in a hierarchical structure, and therefore, the session ticket 200 of the join merge provider 13 included in the user group acquisition request transmitted from the client. , The session ticket ID 310 of the session ticket 300 of the WinNT4 directory provider 161 as the sub-provider 14 can be acquired, and the session ticket ID 310 can be included in the XML message for each.

  Also, since the Join merge provider 13 integrates and manages the UIDs of the users in the sub-provider 14 in the integrated directory 180, the Join merge provider 13 assigns the UIDs of the same user based on the UIDs included in the user group acquisition request. The UID can be obtained from the integrated directory 180 and included in the XML message for each.

  FIG. 24 shows an XML message as an example of a group acquisition request from the Join merge provider to the Notes (registered trademark) R5 directory provider, which is one of the sub-providers.

  FIG. 24A is an XML message (part 1) of a group acquisition request from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162 which is one of the sub-providers 14.

  As shown in FIG. 24 (A), in the request to obtain the group to which the user belongs from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162, the <sessionTicket> <// sessionTicket> tag includes a Notes ( (Registered trademark) R5 directory provider 162 includes the session ticket ID 310 of the session ticket 300.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is the same as the UID included in the XML message in FIG.

  FIG. 24B is an XML message (No. 2) of the group acquisition request from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162 which is one of the sub-providers 14.

  As shown in FIG. 24B, in the request to acquire the group to which the user belongs from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162, the tag <sessionTicket> </ sessionTicket> includes (Registered trademark) R5 directory provider 162 includes the session ticket ID 310 of the session ticket 300.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  FIG. 24C is an XML message (part 3) of the group acquisition request from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162 which is one of the sub-providers 14.

  As shown in FIG. 24C, in the request to obtain the group to which the user belongs from the Join merge provider 13 to the Notes (registered trademark) R5 directory provider 162, the <sessionTicket> </ sessionTicket> tag includes (Registered trademark) R5 directory provider 162 includes the session ticket ID 310 of the session ticket 300.

  The tag of <id> </ id> includes a UID for specifying the user. This UID is one of the UIDs of the same user acquired from the integrated directory 180 by the Join merge provider 13 based on the UID included in the XML message of FIG.

  As described with reference to FIG. 17, the join merge provider 13 manages the session tickets in a hierarchical structure. Therefore, the join merge provider 13 includes the session ticket 200 of the join merge provider 13 included in the user group acquisition request transmitted from the client. , The session ticket ID 310 of the session ticket 300 of the Notes (R) R5 directory provider 162 which is the sub-provider 14 can be acquired, and the session ticket ID 310 can be included in the XML message to each.

  Also, since the Join merge provider 13 integrates and manages the UIDs of the users in the sub-provider 14 in the integrated directory 180, the Join merge provider 13 assigns the UIDs of the same user based on the UIDs included in the user group acquisition request. The UID can be obtained from the integrated directory 180 and included in the XML message for each.

  FIG. 25 shows an XML message as an example of a group acquisition response from a Local directory provider, which is one of the sub-providers, to a Join merge provider.

  FIG. 25A is an XML message of a group acquisition response to the request of FIG.

  If the user corresponding to the specified UID has not been registered in the local directory provider 160, the local directory provider 160 does not include the tag of <item> </ item>, as shown in FIG. An acquisition response is transmitted to the Join merge provider 13.

  FIG. 25B is an XML message of a group acquisition response to the request of FIG.

  As shown in FIG. 25B, when the user corresponding to the designated UID is registered in the local directory provider 160, the local directory provider 160 is included in the tag of <groupList> </ groupList>. The group information to which the user belongs is stored in each <item> </ item>, and transmitted to the Join merge provider 13.

  FIG. 25C is an XML message of a group acquisition response to the request of FIG. 22C.

  As in FIG. 25A, if the user corresponding to the specified UID is not registered in the local directory provider 160, the local directory provider 160 does not include the tag of <item> </ item>. The acquisition response shown in FIG. 25C is transmitted to the Join merge provider 13.

  FIG. 26 shows an XML message as an example of a group acquisition response from a WinNT4 directory provider, which is one of the sub-providers, to a Join merge provider.

  FIG. 26A is an XML message of a group acquisition response to the request of FIG.

  As shown in FIG. 26A, when the user corresponding to the specified UID is registered in the WinNT4 directory provider 161, the WinNT4 directory provider 161 is included in the tag of <groupList> </ groupList>. The group information to which the user belongs is stored in each <item> </ item>, and transmitted to the Join merge provider 13.

  FIG. 26B is an XML message of a group acquisition response to the request of FIG.

  If the user corresponding to the specified UID is not registered in the WinNT4 directory provider 161, the WinNT4 directory provider 161 does not include the tag of <item> </ item>, as shown in FIG. An acquisition response is transmitted to the Join merge provider 13.

  FIG. 26C is an XML message of a group acquisition response to the request of FIG.

  26B, when the user corresponding to the specified UID is not registered in the WinNT4 directory provider 161, the WinNT4 directory provider 161 does not include the tag of <item> </ item>. The acquisition response shown in FIG. 26C is transmitted to the Join merge provider 13.

  FIG. 27 is an XML message as an example of a group acquisition response from the Notes (registered trademark) R5 directory provider, which is one of the sub-providers, to the Join merge provider.

  FIG. 27A is an XML message of a group acquisition response to the request of FIG.

  FIG. 27B is an XML message of a group acquisition response to the request of FIG.

  FIG. 27C is an XML message of a group acquisition response to the request of FIG.

  If the user corresponding to the specified UID has not been registered in the Notes (R) R5 directory provider 162, the Notes (R) R5 directory provider 162 includes a tag of <item> </ item>. No, the acquisition response shown in FIGS. 27A to 27C is transmitted to the Join merge provider 13.

  Each sub-provider 14 creates a group acquisition response including group information to which the user belongs when the user corresponding to the specified UID is registered in the sub-provider 14 as a user of the sub-provider 14. It is transmitted to the Join merge provider 13.

  FIG. 28 is an example of an XML message of a group acquisition response from the Join merge provider to the client.

  As shown in FIG. 28, the Join merge provider 13 adds a <item> </ item> tag including group information acquired from each sub-provider 14 to one <groupList> </ groupList> tag. Merge and store and send to client.

  The client sends the acquisition request of the group to which the user belongs including the session ticket ID 210 of the session ticket 200 of the join merge provider 13 and the UID specifying the user to the join merge provider 13 so that the merge merge provider 13 manages the request. The information of the group to which the same user belongs registered in each sub-provider 14 can be acquired from the Join merge provider 13.

  For example, <item> G: Local: group1 </ item> and <item> G: Local: group2 </ item> in FIG. 28 are users registered in the local directory provider 160 as users of the local directory provider 160. <Item> G: WinNT4: group1 </ item> and <item> G: WinNT4: group2 </ item> in FIG. 28 are information of the group to which the 3238994209 belongs, and are the WinNT4 directory as a user of the WinNT4 directory provider 161. This is information on the group to which the user 3238994209 registered with the provider 161 belongs.

  The Join merge provider 13 can acquire the group information to which the same user belongs from each sub provider 14 and merge them.

  In the description of the first embodiment, a case where the session ticket ID 210 and / or the session ticket ID 310 is transmitted and received between the Join merge provider 13 and the sub provider 14 and between the Join merge provider 13 and the client. Although described by way of example, this is not a limitation of the present implementation, and the session ticket 200 and / or the session ticket 300 may be sent and received.

  As described above, the case where the sub-provider 14 does not require authentication has been described in the first embodiment. However, in the second embodiment described below, the case where the sub-provider 14 requires authentication is described. explain.

  FIG. 29 is a functional block diagram of a Join merge provider and a sub provider in the second embodiment of the present invention.

  As described above, in the second embodiment, the sub-provider 14 provides user information and / or group information to which the user belongs, and provides an authentication service for the user.

  As shown in FIG. 29, the Join merge provider 13 includes a provider I / F 130, a merge processing unit 133, a sub-provider calling unit 134, a merge provider XML processing unit 135, a sub-provider registration unit 136, and a session management unit. 137, an ID password analysis unit 138, an authentication ticket management unit 139, and an integrated directory 180.

  The provider I / F 130 includes an XML processing unit 131 and a UID conversion unit 132.

  The configuration of the Join merge provider 13 in the second embodiment in FIG. 29 is different from the configuration of the Join merge provider 13 in the first embodiment in FIG. 16 in that an ID password analysis unit 138 and an authentication ticket management unit 139 are newly added. Has been added.

  The ID password analysis unit 138 acquires the ID and the password included in the request for creating the authentication ticket 500 that authenticates the user in the Join merge provider 13 transmitted from the client (for example, the Web portal), and calls the sub-provider calling unit 134 Pass to.

  The sub-provider calling unit 134 passes the ID and the password passed from the ID / password analyzing unit 138 to a merge provider XML processing unit 135 described later.

  If the sub-provider 14 that has been successfully authenticated is a sub-sub-provider, the sub-provider calling unit 134 obtains the user in the sub-sub-provider obtained from the sub-sub-provider via the merge provider XML processing unit 135. A verification request for the authentication ticket ID 610 is transmitted to the sub-sub-provider using the authentication ticket ID 610 of the authentication ticket 600 that authenticates the user.

  When the sub-provider calling unit 134 obtains a confirmation response to the confirmation request from the sub-sub-provider via the merge provider XML processing unit 135, the sub-provider as a user of the sub-sub-provider included in the confirmation response The UID of the same user registered in the main sub-provider as a user of the main sub-provider is acquired from the integrated directory 180 by using the UID of the user registered in.

  The sub-provider calling unit 134 uses the management ID and the management password for acquiring the authentication ticket of the main sub-provider stored in the sub-provider registration unit 136, and the user corresponding to the acquired UID of the main sub-provider. The authentication ticket ID 610 of the authentication ticket 600 that authenticates the authentication ticket 600 is obtained from the main sub-provider via the merge provider XML processing unit 135, and the obtained authentication ticket 600 and / or authentication ticket ID 610 is provided to the authentication ticket management unit 139. I do.

  Here, as compared with the first embodiment, as described above, the management ID and the management password for acquiring the authentication ticket of the main sub-provider are registered in the sub-provider registration unit 136.

  As described later, the Join merge provider 13 can register the sub-provider 14 as a main sub-provider by registering the management ID and the management password for obtaining the authentication ticket in the sub-provider registration unit 136.

  The authentication ticket management unit 139 creates and manages an authentication ticket 500 for authenticating a user of the Join merge provider 13 based on the authentication ticket 600 and / or the authentication ticket ID 610 of the main sub provider obtained from the main sub provider.

  Further, the authentication ticket management unit 139 obtains the authentication ticket ID 510 of the authentication ticket 500 for authenticating the created user in the join merge provider 13 through the provider I / F 130 of the join merge provider 13 and the client that has issued the authentication request. (For example, a Web portal).

  For example, even if the client requests authentication using the user name and password of the user of the sub-sub-provider, the Join merge provider 13 authenticates as a user of the main sub-provider and authenticates the user at the main sub-provider. Based on the authentication ticket ID 610, the authentication ticket 500 for authenticating the user in the join merge provider 13 can be created, and the authentication ticket ID 510 of the authentication ticket 500 can be provided to the client.

  FIG. 30 is a conceptual diagram for explaining the structure of the authentication ticket of the Join merge provider.

  As shown in FIG. 30, the authentication ticket 500 of the Join merge provider 13 has an authentication ticket ID 510, a provider type, a provider name to be published, a sub-provider name, and a sub-provider authentication ticket 600 as a structure.

  The authentication ticket ID 510 is an identifier for identifying the authentication ticket. The provider type is a type of the provider such as “Join Merge”.

  The provider name to be published is the name of the Join merge provider 13 to be published, such as “Join Merge 1”.

  The sub-provider name is the name of the main sub-provider of the registered sub-providers 14 whose authentication has succeeded and whose authentication ticket 600 has been transmitted. The authentication ticket of the sub-provider is the authentication ticket 600 of the main sub-provider for which authentication was successful and the authentication ticket 600 was transmitted.

  Since the Join merge provider 13 has the structure of the authentication ticket as shown in FIG. 30, the user can complete the authentication at one time.

  It should be noted that the authentication ticket of the sub-provider 14 may include a decoded version of the authentication ticket 600 of the sub-provider 14 for which the authentication was successful and the authentication ticket 600 was transmitted.

  FIG. 31 is a conceptual diagram (part 1) of data managed in the integrated directory.

  As shown in FIG. 31, the integrated directory 180 integrates and manages the UID of the main sub-provider, the UID of one or more sub-sub-providers, and the authentication ticket of the main sub-provider.

  By integrating and managing the data as shown in FIG. 31, the integrated directory 180 can provide the UID of the same user.

  Hereinafter, the processing of creating an authentication ticket in the Join merge provider 13 when the authentication ticket creation request from the client includes a user name and a password registered in the sub-sub-provider as a user of the sub-sub-provider will be described with reference to FIG. This will be described with reference to FIG.

  FIG. 32 is a flowchart of an example of an authentication ticket creation process in the Join merge provider.

  In step S40, the XML processing unit 131 of the Join merge provider 13 receives a request for creating an authentication ticket 500 for authenticating a user in the Join merge provider 13 from a client (for example, a Web portal).

  An example of an authentication ticket creation request from a client (for example, a Web portal) to the Join merge provider 13 will be described with reference to FIG. 35 described later.

  Proceeding to step S41 following step S40, the ID password analysis unit 138 sends the user name and password included in the authentication ticket creation request received from the client (for example, a Web portal) in step S40 to the sub-provider calling unit 134. hand over.

  Proceeding to step S42 following step S41, the sub-provider calling unit 134 acquires a list of the sub-providers 14 registered in the sub-provider registration unit 136.

  Proceeding to step S43 following step S42, the merge provider XML processing unit 135 issues a request for creating an authentication ticket 600 for authenticating a user at the sub-provider 14 including the ID and the password acquired via the sub-provider calling unit 134. It is created and transmitted to each sub-provider 14 registered in the list of sub-providers 14.

  An example of an authentication ticket creation request from the Join merge provider 13 to the sub provider 14 will be described with reference to FIG. 36 described later.

  Proceeding to step S44 following step S43, the sub-provider calling unit 134 receives an authentication ticket creation response to the authentication ticket 600 creation request from the sub-sub-provider via the merge provider XML processing unit 135.

  An example of an authentication ticket creation response from the sub-sub-provider to the Join merge provider 13 will be described with reference to FIG. 37 described later.

  Proceeding to step S45 following step S44, the sub-provider calling unit 134 determines whether the authentication ticket creation response from the sub-sub-provider received in step S44 includes the authentication ticket ID 610 for identifying the authentication ticket 600. I do.

  If it is determined that the authentication ticket creation response includes the authentication ticket ID 610 for identifying the authentication ticket 600 (YES in step S45), the process proceeds to step S46, and the authentication ticket ID 610 for identifying the authentication ticket 600 is not included. If it is determined (NO in step S45), the process proceeds to step S54.

  In step S46, the merge provider XML processing unit 135 uses the authentication ticket ID 610 that identifies the authentication ticket 600 included in the authentication ticket creation response acquired via the sub-provider calling unit 134, and performs authentication including the authentication ticket ID 610. A ticket ID confirmation request is created and transmitted to the sub-sub-provider that has transmitted the authentication ticket creation response.

  An example of an authentication ticket ID confirmation request from the Join merge provider 13 to the sub provider 14 will be described with reference to FIG. 38 described later.

  Proceeding to step S47 following step S46, the sub-provider calling unit 134 receives, via the merge provider XML processing unit 135, a confirmation response of the authentication ticket ID 610 from the sub-sub-provider that transmitted the authentication ticket ID confirmation request. .

  An example of an authentication ticket ID confirmation response from the sub-sub provider to the Join merge provider 13 will be described with reference to FIG. 39 described later.

  Proceeding to step S48 following step S47, the sub-provider calling unit 134 determines whether the confirmation response of the authentication ticket ID 610 received in step S47 includes user information.

  If it is determined that user information is included (YES in step S48), the process proceeds to step S49. If it is determined that user information is not included (NO in step S48), the process proceeds to step S54.

  In step S49, the sub-provider calling unit 134 acquires the UID of the main sub-provider of the same user from the integrated directory 180 using the UID included in the authentication ticket ID confirmation response from the sub-sub-provider acquired in step S47.

  Proceeding to step S50 following step S49, the sub-provider calling unit 134 acquires the management ID and the management password for acquiring the authentication ticket of the main sub-provider from the sub-provider registration unit 136.

  Proceeding to step S51 following step S50, the merge provider XML processing unit 135 acquires the main ID including the management ID and the management password for obtaining the authentication ticket of the main sub-provider obtained through the sub-provider calling unit 134. A request for creating an authentication ticket 600 for authenticating the user corresponding to the UID in the sub provider is created and transmitted to the main sub provider.

  An example of an authentication ticket creation request from the Join merge provider 13 to the main sub provider will be described with reference to FIG. 40 described below.

  Proceeding to step S52 following step S51, the sub-provider calling unit 134 generates, via the merge provider XML processing unit 135, an authentication ticket creation request for the authentication ticket 600 creation request from the main sub-provider that has transmitted the authentication ticket creation request. Receive the response.

  An example of an authentication ticket creation response from the main sub provider to the Join merge provider 13 will be described with reference to FIG. 41 described below.

  Proceeding to step S53 following step S52, the sub-provider calling unit 134 determines whether the authentication ticket creation response from the main sub-provider received in step S52 includes the authentication ticket ID 610 identifying the authentication ticket 600. I do.

  If it is determined that the authentication ticket creation response includes the authentication ticket ID 610 for identifying the authentication ticket 600 (YES in step S53), the process proceeds to step S55, and the authentication ticket ID 610 for identifying the authentication ticket 600 is not included. If it is determined (NO in step S53), the process proceeds to step S54.

  In step S54, the XML processing unit 131 of the Join merge provider 13 creates a response indicating that the creation of the authentication ticket 500 has failed, and transmits the response to the client (for example, a Web portal).

  In step S55, the authentication ticket management unit 139 creates the authentication ticket 500 for authenticating the user in the Join merge provider 13 described in FIG. 30 using the authentication ticket ID 610 of the main sub provider.

  Proceeding to step S56 following step S55, the XML processing unit 131 of the Join merge provider 13 creates an authentication ticket creation response including the authentication ticket ID 510 of the authentication ticket 500 created in step S55, and sends the response to the client (for example, a Web portal). Send to

  An example of an authentication ticket creation response from the Join merge provider 13 to a client (for example, a Web portal) will be described with reference to FIG. 42 described later.

  FIG. 33 is a flowchart of an example of an authentication ticket creation process in the sub provider.

  When the Join merge provider 13 transmits a request for creating an authentication ticket 600 for authenticating a user in the sub provider 14 to the sub provider 14 in step S43 or step S51 in FIG. 32, the sub provider 14 performs the processing from step S60 described below. To start.

  In step S60, the XML processing unit 131 of the sub provider 14 receives a request for creating an authentication ticket 600 for authenticating a user in the sub provider 14 from the join merge provider 13.

  As described above, an example of an authentication ticket creation request from the join merge provider 13 to the sub-provider 14 will be described with reference to FIG. 36 described below, and an example of an authentication ticket creation request from the join merge provider 13 to the main sub-provider will be described below. This will be described with reference to FIG.

  Proceeding to step S61 following step S60, the ID password analysis unit 143 determines, via the directory operation wrapper 141, whether the user name and password included in the request for creating the authentication ticket 600 received in step S60 are correct. Check the directory 150 and make a determination.

  If it is determined that the combination is correct (YES in step S61), the process proceeds to step S63. If it is determined that the combination is not correct (NO in step S61), the process proceeds to step S62.

  In step S62, the XML processing unit 131 of the sub provider 14 creates an authentication ticket creation response indicating that the creation of the authentication ticket 600 has failed, and transmits the response to the Join merge provider 13.

  In step S63, the authentication ticket management unit 144 acquires the user information corresponding to the user name and the password from the directory 150 via the directory operation wrapper 141.

  Proceeding to step S64 following step S63, the authentication ticket management unit 144 creates an authentication ticket 600 for authenticating the user at the sub-provider 14.

  Proceeding to step S65 following step S64, the XML processing unit 131 of the sub provider 14 creates an authentication ticket creation response including the authentication ticket ID 610 of the authentication ticket 600 created in step S64, and transmits it to the Join merge provider 13.

  As described above, an example of an authentication ticket creation response from the sub-sub-provider to the Join merge provider 13 will be described with reference to FIG. 37 described below, and an example of an authentication ticket creation response from the main sub-provider to the Join merge provider 13 will be described below. This will be described with reference to FIG.

  Note that the step S44 and / or the step S52 in FIG. 32 receives the authentication ticket creation response transmitted in the step S62 or the step S65 in FIG.

  FIG. 34 is a flowchart of an example of the authentication ticket ID confirmation processing in the sub provider.

  When the Join merge provider 13 transmits a confirmation request for the authentication ticket ID 610 to the sub-provider 14 in step S46 of FIG. 32 and step S84 of FIG. 43 described later, the sub-provider 14 starts processing from step S70 described below. .

  In step S70, the XML processing unit 131 of the sub provider 14 receives a confirmation request for the authentication ticket ID 610 from the Join merge provider 13.

  An example of an authentication ticket ID confirmation request from the join merge provider 13 to the sub-sub-provider will be described later with reference to FIG. 38, and an example of an authentication ticket ID confirmation request from the join merge provider 13 to the main sub-provider will be described later. This will be described with reference to FIG.

  Proceeding to step S71 following step S70, the UID conversion unit 132 of the sub provider 14 converts the UID included in the confirmation request for the authentication ticket ID 610 received in step S70 into a UID unique to the directory 150.

  Proceeding to step S72 following step S71, the authentication ticket management unit 144 determines whether the authentication ticket ID 610 included in the confirmation request for the authentication ticket ID 610 received in step S70 is the authentication ticket ID 610 of the valid authentication ticket 600. I do.

  If it is determined that the authentication ticket ID is the authentication ticket ID 610 of the valid authentication ticket 600 (YES in step S72), the process proceeds to step S74. If it is determined that the authentication ticket ID is the authentication ticket ID 610 of the invalid authentication ticket 600 (NO in step S72), the process proceeds to step S73. move on.

  In step S73, the XML processing unit 131 of the sub provider 14 creates an authentication ticket ID confirmation response indicating that the confirmation of the authentication ticket ID 610 has failed, and transmits the response to the join merge provider 13.

  In step S74, the sub-provider 14 acquires user information from the directory 150 via the directory operation wrapper 141.

  Proceeding to step S75 following step S74, the UID conversion unit 132 of the sub provider 14 converts the UID unique to the directory 150 into a UID usable by the join merge provider 13.

  Proceeding to step S76 following step S75, the XML processing unit 131 of the sub-provider 14 creates an authentication ticket ID confirmation response including the user information acquired in step S74, and transmits it to the Join merge provider 13.

  An example of an authentication ticket ID confirmation response from the sub-sub-provider to the Join merge provider 13 will be described later with reference to FIG. 39, and an example of an authentication ticket ID confirmation response from the main sub-provider to the Join merge provider 13 will be described later. This will be described with reference to FIG.

  In step S47 of FIG. 32 and / or step S85 of FIG. 43 described below, the authentication ticket ID confirmation response transmitted in step S73 or step S76 of FIG. 34 is received.

  FIG. 35 shows an XML message as an example of an authentication ticket creation request from a client to a Join merge provider.

  As shown in FIG. 35, in a request to create an authentication ticket 500 from a client (for example, a Web portal) to the Join merge provider 13, a user name is added to a <Name> </ Name> tag, and <passwd> </ passwd. The password corresponding to the user name is included in the tag of>.

  The Join merge provider 13 receives a request for creating an authentication ticket 500 including a user name and a password from a client (for example, a Web portal).

  FIG. 36 shows an XML message as an example of an authentication ticket creation request from the Join merge provider to the sub provider.

  As illustrated in FIG. 36, the Join merge provider 13 performs authentication for authenticating a user in the sub-provider 14 including the user name and the password included in the request for creating the authentication ticket 500 transmitted from the client (for example, the Web portal). A request for creating a ticket 600 is transmitted to the sub provider 14.

  FIG. 37 shows an XML message as an example of an authentication ticket creation response from the sub-sub-provider to the Join merge provider.

  As shown in FIG. 37, the authentication ticket creation response from the sub-sub-provider to the Join merge provider 13 includes the <authTicket> </ authTicket> tag with the authentication ticket ID 610 of the authentication ticket 600 created by the sub-sub-provider. It is.

  When the authentication is successful, the sub-sub-provider creates an authentication ticket 600 for authenticating the user in the sub-sub-provider, and transmits an authentication ticket creation response including the authentication ticket ID 610 of the authentication ticket 600 to the Join merge provider 13.

  FIG. 38 shows an XML message as an example of an authentication ticket ID confirmation request from the Join merge provider to the sub-sub-provider.

  As shown in FIG. 38, the authentication ticket ID confirmation request from the Join merge provider 13 to the sub-sub-provider includes the <authTicket> </ authTicket> tag with the sub-sub-provider acquired from the sub-sub-provider shown in FIG. The authentication ticket ID 610 of the authentication ticket 600 that authenticates the user in is included.

  FIG. 39 is an example of an XML message of an authentication ticket ID confirmation response from the sub-sub-provider to the Join merge provider.

  As shown in FIG. 39, in the confirmation response of the authentication ticket ID 610 from the sub-sub-provider to the Join merge provider 13, the tag of <name> </ name> includes the name of the user, and <id> </ id> Tag includes a UID for identifying the user, and each <item> </ item> tag included in the <groupList> </ groupList> tag includes the <id> <// id> tag in the sub-sub-provider. Group information to which a user registered as a user included in the tag belongs is included.

  The sub-sub-provider acquires the user information and / or the group information to which the user belongs from the directory 150 and transmits the acquired information to the Join merge provider 13.

  FIG. 40 shows an XML message as an example of an authentication ticket creation request from the Join merge provider to the main sub provider.

  As shown in FIG. 40, in the request to create the authentication ticket 600 from the Join merge provider 13 to the main sub-provider, the <Name> </ Name> tag contains the management ID for acquiring the authentication ticket, and the <passwd> < / Passwd> includes a management password for obtaining a certificate ticket.

  The Join merge provider 13 authenticates the user corresponding to the UID of the main sub-provider, including the management ID and the management password for acquiring the authentication ticket of the main sub-provider stored in the sub-provider registration unit 136. Send 600 creation requests to the primary sub-provider.

  FIG. 41 shows an XML message as an example of an authentication ticket creation response from the main sub provider to the Join merge provider.

  As shown in FIG. 41, the authentication ticket creation response from the main sub-provider to the Join merge provider 13 includes an <authTicket> </ authTicket> tag including the authentication ticket ID 610 of the authentication ticket 600 created by the main sub-provider. It is.

  When the authentication is successful, the main sub-provider creates an authentication ticket 600 for authenticating the user in the sub-sub-provider, and sends an authentication ticket creation response including the authentication ticket ID 610 of the authentication ticket 600 to the Join merge provider 13.

  FIG. 42 shows an XML message as an example of an authentication ticket creation response from the Join merge provider to the client.

  As shown in FIG. 42, in the authentication ticket creation response from the join merge provider 13 to the client (for example, a Web portal), the tag of <authTicket> </ authTicket> includes the tag of the authentication ticket 500 created by the join merge provider 13. An authentication ticket ID 510 is included.

  When acquiring the authentication ticket ID 610 of the authentication ticket 600 created in the main sub-provider from the main sub-provider as described in FIG. 41, the Join merge provider 13 performs authentication for authenticating the user in the Join merge provider 13 described in FIG. A ticket 500 is created, and an authentication ticket creation response including the authentication ticket ID 510 of the authentication ticket 500 is transmitted to a client (for example, a Web portal).

  Hereinafter, processing of the Join merge provider 13 and the sub-provider 14 when a request for confirming the authentication ticket ID 510 transmitted in the authentication ticket creation response is transmitted from a client (for example, an application) will be described.

  FIG. 43 is a flowchart of an example of the authentication ticket ID confirmation processing in the Join merge provider.

  In step S80, the XML processing unit 131 of the Join merge provider 13 receives a confirmation request for the authentication ticket ID 510 from a client (for example, an application).

  An example of an authentication ticket ID confirmation request from a client (for example, an application) to the Join merge provider 13 will be described with reference to FIG.

  Proceeding to step S81 following step S80, the authentication ticket management unit 139 acquires the authentication ticket ID 510 included in the authentication ticket ID 510 confirmation request received in step S80.

  Proceeding to step S82 following step S81, the authentication ticket management unit 139 determines whether the authentication ticket ID 510 acquired in step S81 is the correct authentication ticket ID 510.

  If it is determined that the authentication ticket ID is correct (YES in step S82), the process proceeds to step S83. If it is determined that the authentication ticket ID is not correct (NO in step S82), the process proceeds to step S87.

  In step S83, the authentication ticket management unit 139 sends the authentication ticket ID 610 of the authentication ticket 600 of the main sub-provider included in the authentication ticket 500 of the Join merge provider 13 and the sub-provider name of the main sub-provider to the sub-provider calling unit 134. hand over.

  Proceeding to step S84 following step S83, the merge provider XML processing unit 135 uses the authentication ticket ID 610 of the authentication ticket 600 of the main sub-provider acquired via the sub-provider calling unit 134, and includes the authentication ticket ID 610. Create an authentication ticket ID confirmation request for the sub provider and send it to the main sub provider.

  An example of an authentication ticket ID confirmation request from the join merge provider 13 to the main sub provider will be described with reference to FIG. 45 described later.

  Proceeding to step S85 following step S84, the sub provider calling unit 134 receives a confirmation response of the authentication ticket ID 610 from the main sub provider via the merge provider XML processing unit 135.

  An example of the authentication ticket ID confirmation response from the main sub provider to the Join merge provider 13 will be described with reference to FIG. 46 described later.

  Proceeding to step S86 following step S85, the sub-provider calling unit 134 determines whether the confirmation response of the authentication ticket ID 610 received in step S85 includes the user information.

  If it is determined that user information is included (YES in step S86), the process proceeds to step S88, and if it is determined that user information is not included (NO in step S86), the process proceeds to step S87.

  In step S87, the XML processing unit 131 of the Join merge provider 13 creates a response indicating that the verification of the authentication ticket ID 510 has failed, and transmits the response to the client (for example, an application).

  In step S88, the sub-provider calling unit 134 acquires the UID of the same user from the integrated directory using the UID that is the identification information for identifying the user included in the user information acquired in step S86.

  Proceeding to step S89 following step S88, the sub-provider calling unit 134 acquires the session ticket ID 310 of the session ticket 300 of each sub-provider 14 managed by the session management unit 137 and the sub-provider name.

  Proceeding to step S90 following step S89, the merge provider XML processing unit 135 acquires the UID specifying the user and the session ticket ID 310 of the session ticket 300 of each subprovider 14 from the subprovider calling unit 134, and executes the first implementation. As described in the example, a request to acquire the group to which the user belongs is created and transmitted to each sub provider 14.

  Proceeding to step S91 following step S90, the sub-provider calling unit 134 receives a belonging group acquisition response to the belonging group acquisition request from each sub-provider 14 via the merge provider XML processing unit 135.

  Proceeding to step S92 following step S91, the merge processing unit 133 merges the user information acquired in step S85 with the group information to which the user belongs included in the belonging group acquisition response acquired in step S91.

  Proceeding to step S93 following step S92, the XML processing unit 131 of the Join merge provider 13 creates an authentication ticket ID confirmation response including the user information merged in step S92 and the group information to which the user belongs, and creates a client (eg, , Application) to send.

  An example of the authentication ticket ID confirmation response from the Join merge provider 13 to the client will be described with reference to FIG. 47 described later.

  FIG. 44 shows an XML message as an example of an authentication ticket ID confirmation request from a client to a Join merge provider.

  As shown in FIG. 44, the authentication ticket ID confirmation request from the client (for example, the application) to the Join merge provider 13 includes an authentication ticket for authenticating the user in the Join merge provider 13 in a tag of <authTicket> </ authTicket>. 500 authentication ticket IDs 510 are included.

  The Join merge provider 13 receives, from a client (for example, an application), a confirmation request for the authentication ticket ID 510 including the authentication ticket ID 510 of the authentication ticket 500 for authenticating the user in the Join merge provider 13.

  FIG. 45 shows an XML message as an example of an authentication ticket ID confirmation request from the Join merge provider to the main sub provider.

  As shown in FIG. 45, the authentication ticket ID confirmation request from the Join merge provider 13 to the main sub-provider includes an <authTicket> </ authTicket> tag with an authentication ticket of the authentication ticket 600 for authenticating a user in the main sub-provider. ID 610 is included.

  Since the Join merge provider 13 manages the authentication ticket 600 of the main sub-provider included in the authentication ticket 500 of the Join merge provider 13 as described with reference to FIG. 30, it is transmitted from the client (for example, an application). The authentication ticket ID 610 of the authentication ticket 600 of the main sub-provider is acquired based on the authentication ticket ID 510 of the authentication ticket 500 of the Join merge provider 13 included in the authentication ticket confirmation request, and the authentication ticket ID 610 can be included in the XML message. .

  FIG. 46 shows an XML message as an example of an authentication ticket ID confirmation response from the main sub provider to the Join merge provider.

  As shown in FIG. 46, the confirmation response of the authentication ticket ID 610 from the main sub-provider to the Join merge provider 13 includes the user name in the tag of <name> </ name>, and the <id> <// id> The UID of the user registered in the main sub-provider as a user of the main sub-provider is included in the tag of <groupList> </ groupList>, and the <item> </ item> tag included in the tag of <groupList> </ groupList> includes the user's Group information to which the main sub provider belongs is included.

  The main sub-provider acquires the user information and the group information to which the user belongs from the directory 150, and transmits the acquired information to the Join merge provider 13.

  FIG. 47 shows an XML message as an example of an authentication ticket ID confirmation response from the Join merge provider to the client.

  As shown in FIG. 47, the Join merge provider 13 sets the <name> </ name> tag to the user's name, the <id> </ id> tag to The group information to which the same user belongs obtained from each sub-provider 14 is stored in one or more <item> </ item> tags included in the <groupList> </ groupList> tag and transmitted to the client.

  As described in FIG. 46, the Join merge provider 13 can acquire the UID for identifying the user from the main sub-provider, and acquires the UID of the same user from the integrated directory 180 using the UID, and acquires the UID. Using the obtained UID and the session ID 310 of the session ticket 300 of the sub-provider 14, it is possible to obtain from the sub-providers 14 the group information to which the same user registered in each sub-provider as a user of each sub-provider belongs. it can.

  For example, G: WinNT4: group1 and G: WinNT4: group2 stored in the tag of <item> </ item> in FIG. 47 are the user 323994209 registered as the user of WinNT4 in the WinNT authentication directory provider 7. G: Local: group1 and G: Local: group2, which are group information to which (yamada) belongs and are stored in <item> </ item> tags in FIG. This is the group information to which the user 3238994209 (yamada) registered as the user belongs.

  The Join merge provider 13 can merge the group information and provide the merged group information to the client.

  As described in the second embodiment, even when the sub-provider 14 requires authentication, the user only needs to send the user name and password once to the Join merge provider 13 to perform authentication, and The group information to which the same user belongs can be acquired from all the registered sub-providers 14 by being authenticated as a user in the provider.

  In the description of the second embodiment, the case where the authentication ticket ID 510 and / or the authentication ticket ID 610 is transmitted and received between the Join merge provider 13 and the sub-provider 14 and between the Join merge provider 13 and the client. Although described by way of example, this is not a limitation of the present implementation, and the authentication ticket 500 and / or the authentication ticket 600 may be sent and received. This is the same in the following.

  Note that the Join merge provider 13 can also designate a plurality of main sub-providers.

  The Join merge provider 13 can specify the sub-sub-provider as a new main sub-provider by storing the management ID and the management password for obtaining the authentication ticket of the sub-sub-provider in the sub-provider registration unit 136. .

  For example, when the management ID and the management password of the sub-sub-provider are newly registered in the sub-provider registration unit 136, the Join merge provider 13 sets the sub-sub-provider as a new main sub-provider and sets the management ID. The authentication ticket 600 and / or the authentication ticket ID 610 for authenticating a user in the main sub-provider are obtained from the main sub-provider using the password and the management password.

  Using the acquired authentication ticket ID 610, the Join merge provider 13 transmits the authentication ticket ID confirmation request to the main sub provider, and acquires the UID of the main sub provider from the main sub provider.

  The Join merge provider 13 registers the acquired authentication ticket 600 for authenticating the user in the main sub-provider and the UID of the main sub-provider in the integrated directory 180.

  FIG. 48 is a conceptual diagram (part 2) of data managed in the integrated directory.

  As shown in FIG. 48, the integrated directory 180 integrates and manages one or more main sub-providers, UIDs of one or more sub-sub-providers, and authentication tickets of one or more main sub-providers.

  The Join merge provider 13 can designate and manage a plurality of main sub-providers.

  The difference between the main sub provider and the sub sub provider is whether the management ID and the management password are registered in the sub provider registration unit 136.

  For example, when a management ID and a management password are registered in the sub-provider registration unit 136 when a new sub-provider 14 is added to the Join merge provider 13, the new sub-provider 14 becomes a main sub-provider and a sub-provider. If the management ID and the management password are not registered in the registration unit 136, the new sub provider 14 becomes a sub sub provider.

  With this configuration, for example, the client can select which main sub-provider the user and / or the group to which the user belongs are permitted to use the service provided by the client. it can.

  Hereinafter, an example in which the Join merge provider 13 is introduced will be described with reference to FIG.

  FIG. 49 is a diagram illustrating an example of reading an IC card using a Join merge provider, authenticating a user, and acquiring a stored document stored in a repository service.

  In step S100, the IC card reading service 190 passes the user name and password read from the IC card to the Join merge provider 13.

  Proceeding to step S101 following step S100, the Join merge provider 13 issues a request for creating the authentication ticket 600 including the user name and password acquired in step S100 to the main sub-provider 220 and the IC card authentication local provider as the sub-sub-provider. 230.

  The IC card authentication local provider 230, which is a sub-sub-provider, performs authentication using the user name and the password, and if authentication is successful, creates an authentication ticket 600.

  Proceeding to step S102 following step S101, the IC card authentication local provider 230, which is the sub-sub-provider, creates an authentication ticket creation response including the authentication ticket ID 610 of the authentication ticket 600, and transmits the response to the join merge provider 13. In addition, the main sub-provider 220 creates an authentication ticket creation response indicating that the authentication has failed, and transmits the response to the Join merge provider 13.

  Proceeding to step S103 following step S102, the Join merge provider 13 transmits a confirmation request for the authentication ticket ID 610 to the IC card authentication local provider 230 using the authentication ticket ID 610 of the authentication ticket 600.

  In addition, the Join merge provider 13 may transmit a request for confirming the authentication ticket ID 610 to all registered sub-providers to be managed.

  Proceeding to step S104 following step S103, the IC card authentication local provider 230 transmits a confirmation response of the authentication ticket ID 610 including the UID of the successfully authenticated user to the join merge provider 13.

  The Join merge provider 13 acquires the UID of the main sub-provider of the same user from the integrated directory 180 based on the UID included in the acquired authentication ticket confirmation response.

  Proceeding to step S105 following step S104, the Join merge provider 13 uses the management ID and the management password of the main sub-provider for creating an authentication ticket to notify the main sub-provider 220 of the main sub-provider. A request for creating a user authentication ticket 600 corresponding to the UID is transmitted.

  The main sub-provider 220 authenticates the user corresponding to the UID using the management ID and the management password, and creates an authentication ticket 600 when the authentication is successful.

  Proceeding to step S106 following step 105, the main sub-provider 220 creates an authentication ticket creation response including the authentication ticket ID 610 of the authentication ticket 600, and sends it to the Join merge provider 13.

  Proceeding to step S107 following step S106, when the Join merge provider 13 obtains the authentication ticket creation response including the authentication ticket ID 610 from the main sub-provider 220, it creates the authentication ticket 500 for authenticating the user in the Join merge provider 13. Then, an authentication ticket creation response including the authentication ticket ID 510 of the created authentication ticket 500 is transmitted to the IC card reading service 190.

  Proceeding to step S108 following step S107, the IC card reading service 190 issues a request for creating a session ticket 700 that includes the authentication ticket ID 510 acquired in step S107 and permits use of the service provided by the repository service. Send to 170.

  Proceeding to step S109 following step S108, the repository service 170 determines whether the request for creating the session ticket 700 received in step S108 is a request from a valid user. By using the included authentication ticket ID 510, an authentication ticket ID confirmation request including the authentication ticket ID 510 is transmitted to the Join merge provider 13.

  Proceeding to step S110 following step S109, based on the authentication ticket ID 510 included in the authentication ticket ID confirmation request obtained in step S109, the Join merge provider 13 deletes the authentication ticket ID 610 obtained from the main sub provider 220 in step S106. A confirmation request is sent to the main sub-provider 220.

  Proceeding to step S111 following step S110, the main sub-provider 220 sends an authentication ticket confirmation response including the UID of the user corresponding to the authentication ticket ID 610 included in the confirmation request for the authentication ticket ID 610 to the Join merge provider 13.

  The Join merge provider 13 acquires the UID of the same user from the integrated directory 180 based on the UID included in the acquired authentication ticket confirmation response.

  Proceeding to step S112 following step S111, the Join merge provider 13 determines the UID of the user registered in the main sub-provider 220 as a user of the main sub-provider 220, the session ticket ID 310 of the session ticket 300 of the main sub-provider 220, and Is transmitted to the main sub-provider 220.

  In addition, the Join merge provider 13 includes a UID of a user registered in the IC card authentication local provider 230 as a user of the IC card authentication local provider 230, and a session ticket ID 310 of the session ticket 300 of the IC card authentication local provider 230. A request to acquire the group information to which the user corresponding to the UID belongs may be transmitted to the IC card authentication local provider 230.

  Proceeding to step S113 following step S112, the Join merge provider 13 and / or the IC card authentication local provider 230 retrieve the group information of the user corresponding to the UID included in the acquisition request of the acquired user's group information. An acquisition response including the request is created and transmitted to the Join merge provider 13.

  Proceeding to step S114 following step S113, the Join merge provider 13 merges the user information acquired in step S111 and / or the group information to which the user belongs in step S113, and an authentication ticket including the merged information. An ID confirmation response is created and transmitted to the repository service 170.

  Proceeding to step S115 following step S114, the repository service 170 determines that if the group obtained in step S114 permits use of the service provided by the repository service 170, the use of the service is determined. A permitted session ticket 700 is created, and a session ticket creation response including the session ticket ID 710 of the session ticket 700 is transmitted to the IC card reading service 190.

  Proceeding to step S116 following step S115, the IC card reading service 190 transmits an acquisition request for a stored document including the session ticket ID 710 of the acquired session ticket 700 to the repository service 170.

  Proceeding to step S117 following step S116, the repository service 170 determines whether the session ticket ID 710 included in the acquisition request for the stored document acquired in step S116 is the session ticket ID 710 of the valid session ticket 700, and If it is determined that the ticket ID is the ticket ID 710, a response to the stored document including the specified stored document is transmitted to the IC card reading service 190.

  By introducing the Join merge provider 13, the user only needs to pass through the IC card, for example, is authenticated by the IC card authentication local provider 230. The repository service 170 for which use is permitted can be used.

  Hereinafter, an example in which information (configuration information) related to the configuration of the Join merge provider 13 and the sub-provider 14 is taken out of the Join merge provider 13 and held and managed by the configuration manager 22 described later. This will be described in the following examples.

  FIG. 50 is a diagram (part 4) for describing the configuration of the UCS. In FIG. 50, for simplification of the description, as described in FIG. 13, the description will be made assuming that the UCS 49 includes both the Join merge provider 13 and the sub-provider 14. However, as described above, for example, a part or all of the sub-provider 14 may be included in another MFP 120 or the like.

UCS49 shown in FIG. 50 includes a dispatcher 21, a configuration manager 22, the Join merge provider 13, and 14 _n from the sub provider 14 _1, a.

  The dispatcher 21 receives the request from the client, distributes the request to the configuration manager 22, the join merge provider 13, and the like, and processes the processing result processed by the configuration manager 22 or the join merge provider 13 according to the distributed request. Or to the client.

Configuration manager 22, a Join merge provider 13, and the sub provider ₁₄ 1 to 14 _n, a management unit for managing the configuration of holding the configuration information and the like in the storage unit.

  Note that the Join merge provider 13 and the sub-provider 14 are the same as those described in the first or second embodiment.

  Hereinafter, an example of the provider list acquisition sequence will be described with reference to FIG. FIG. 51 is a diagram illustrating an example of a provider list acquisition sequence.

  As shown in FIG. 51, for example, when a new provider is added as a sub-provider 14 of the Join merge provider 13, the client sends a getProviderList of the dispatcher 21 to the dispatcher 21 in order to select the newly added provider. A provider list acquisition request including the method is transmitted (sequence SQ1). An example of the provider list acquisition request will be described with reference to FIG. 52 described later.

  The dispatcher 21 that has received the provider list acquisition request calls the enumerateProviderName method of the configuration manager 22 (sequence SQ2).

  The configuration manager 22, which has called the “enumerateProviderName” method, acquires the provider name and the like from the storage unit and returns the provider name and the like to the dispatcher 21 as a provider list.

  The dispatcher 21 creates a provider list acquisition response including the provider list and transmits the response to the requesting client. An example of the provider list acquisition response is shown using FIG. 53 described later.

  By performing the processing shown in FIG. 51, for example, the client displays a list of providers, and the user can select a provider to be newly added as the sub-provider 14 of the Join merge provider 13 from the list of providers. .

  Hereinafter, an example of the provider list acquisition request will be described with reference to FIG. FIG. 52 shows an XML message as an example of a provider list acquisition request from a client to a dispatcher.

  As shown in FIG. 52, the provider list acquisition request includes a getProviderList method.

  Hereinafter, an example of the provider list acquisition response will be described with reference to FIG. 53 described later. FIG. 53 shows an XML message as an example of a provider list acquisition response from the dispatcher to the client.

  As shown in FIG. 53, the tag of <item> </ item> stores the name of the provider (or an identifier for identifying the provider).

  Hereinafter, an example of the sub-provider addition sequence will be described with reference to FIG. FIG. 54 is a diagram for describing an example of a sub-provider addition sequence.

  As shown in FIG. 54, when the user selects a provider to be added from a provider list using, for example, a GUI (Graphical User Interface) described later, the client issues a createProvider method of the dispatcher 21 to the dispatcher 21. A sub provider addition request is transmitted (sequence SQ10). An example of the sub-provider addition request is shown using FIG. 55 described later. Although omitted in FIG. 54, the sub-provider addition request includes, for example, information such as which join provider 13 and which sub-provider 14 are to be added.

  The dispatcher 21 that has received the sub-provider addition request calls the createProviderConfiguration method of the configuration manager 22 (sequence SQ11).

  The configuration manager 22 that has called the createProviderConfiguration method secures a new area for storing configuration information in the storage unit, and stores storage area information (for example, the head address of the newly secured area) of the new area. Return to dispatcher 21.

  The dispatcher 21 that has acquired the storage area information calls the createProvider method of the sub-provider 14 to be added with the storage area information as an argument (sequence SQ12).

  The sub-provider 14 that has called the createProvider method uses the storage area information passed as an argument of the createProvider method and default configuration information such as the identifier of the sub-provider 14 and the name of the sub-provider 14 as arguments. Call the setAttribute method of the ration manager 22 (sequence SQ13).

  The configuration manager 22 that has called the setAttribute method converts the configuration information including the default configuration information of the sub-provider 14 passed as an argument of the setAttribute method based on the storage area information passed as an argument of the setAttribute method. In the storage area to be stored.

  The dispatcher 21 that has received the information indicating that the configuration information has been stored from the configuration manager 22 creates a sub-provider addition response including information indicating that the addition of the provider has been normally completed, and transmits the sub-provider addition response to the requesting client. An example of the sub-provider addition response is shown using FIG. 56 described later.

  By performing the processing shown in FIG. 54, a provider can be newly added as a sub-provider 14 of the Join merge provider 13.

  Hereinafter, an example of the sub-provider addition request will be described with reference to FIG. FIG. 55 shows an XML message as an example of a sub-provider addition request from the client to the dispatcher.

  As shown in FIG. 55, the sub-provider addition request includes a createProvider method. Also, as an argument of the createProvider method, the tag of <joinMergeproviderName> </ joinMergeproviderName> contains the identifier or name of the Join merge provider. Also, <subproviderName> </ </ subproviderName> of the tag of <item> </ item> contains the identifier or name of the sub-provider to be newly added.

  Hereinafter, an example of the sub-provider addition response will be described with reference to FIG. FIG. 56 shows an XML message as an example of a sub-provider addition response from the dispatcher to the client.

  As shown in FIG. 56, the <returnValue> </ returnValue> tag of the sub-provider addition response includes information (OK in the example of FIG. 56) indicating whether the sub-provider addition was successful. I have.

  Hereinafter, a hardware configuration of an example of the client will be described with reference to FIG. FIG. 57 is a hardware configuration diagram of an example of a client.

  The hardware configuration of the client shown in FIG. 57 includes an input device 51, a display device 52, a drive device 53, a recording medium 54, a ROM 55, a RAM 56, a CPU 57, which are mutually connected by a bus. An interface device 58 and an HDD 59 are provided.

  The input device 51 includes a keyboard and a mouse operated by a user of the client, and is used to input various operation signals to the client. The display device 52 includes a display or the like used by a user of the client, and displays various information. The interface device 58 is an interface for connecting a client to the network 5 or the like.

  An application program or the like that executes each process in the client is provided to the client by a recording medium 54 such as a CD-ROM, or downloaded through the network 5. The recording medium 54 is set in the drive device 53, and the application program is installed on the HDD 59 from the recording medium 54 via the drive device 53.

  The ROM 55 stores data and the like. The RAM 56 reads out and stores application programs and the like from the HDD 59 when the client is started. The CPU 57 executes processing according to an application program and the like read and stored in the RAM 56. The HDD 59 stores data, files, and the like.

  In the above-described embodiment, the MFP 120 has been described as an example of a device on which the Join merge provider 13 and / or the sub-provider 14 is mounted. However, a PC (personal computer) as shown in FIG. ) May be implemented.

  Hereinafter, an example of the function of the client will be described with reference to FIG. FIG. 58 is a functional block diagram of the client.

  As shown in FIG. 58, the client includes a GUI display unit 71, a control unit 72, a server calling unit 73, and an XML generation analysis unit 74.

  The GUI display unit 71 is a display unit that creates a GUI described later and displays the GUI on a display or the like of the client. The control unit 72 is a control unit that controls the processing of the entire client. The server calling unit 73 is a calling unit that calls a server including the Join merge provider 13 and the like. The XML generation / analysis unit 74 generates the XML, transmits the generated XML to the server, analyzes the XML message received from the server or the like, and acquires data and the like included in the XML message.

  FIG. 59 shows an example of the GUI related to the setting of the provider in the client. FIG. 59 is a diagram (part 1) illustrating a GUI related to the setting of the provider in the client.

  Upon receiving the provider list acquisition response as shown in FIG. 53, for example, the client drops the provider list based on the provider list included in the provider list acquisition response as shown in FIG. Create and display the user authentication provider setting screen included in the down menu.

  In the group box displayed below the drop-down menu on the user authentication provider setting screen shown in FIG. 59A, the user changes depending on the provider selected from the drop-down menu.

  For example, when the user selects “reference authentication service” in FIG. 59 (A) and clicks the “reference” button, the client displays a reference screen for external authentication as shown in FIG. 59 (B). Note that the external authentication is authentication in which an authentication engine (in the example of FIG. 25, for example, the ID password analysis unit 143 and the authentication ticket management unit 144) that performs actual authentication is performed by an external server or the like.

  When the user clicks the “Browse” button in FIG. 59B, the client displays a user authentication service management reference screen as shown in FIG. 59C.

  FIG. 60 shows another example of the GUI related to the provider setting in the client. FIG. 60 is a diagram (part 2) illustrating a GUI related to the setting of the provider in the client.

  FIG. 60 shows an example screen when the user selects Windows (registered trademark) NT authentication from the drop-down menu. The “Setting of domain controller” button in FIG. 60 is valid only when the user selects “Self-authentication setting”.

  FIG. 61 shows another example of the GUI related to the setting of the provider in the client. FIG. 61 is a diagram (part 3) illustrating the GUI related to the setting of the provider in the client.

  FIG. 61 illustrates an example screen when the user selects Active Directory (registered trademark) authentication from the drop-down menu. Note that the “domain controller setting” button in FIG. 61 is valid only when the user selects “self-authentication setting”.

  FIG. 62 shows another example of the GUI related to the setting of the provider in the client. FIG. 62 is a diagram (part 4) illustrating a GUI related to provider setting in the client.

  FIG. 62 shows an example screen when the user selects Notes (registered trademark) authentication from the drop-down menu.

  Hereinafter, an example of the remote provider will be described with reference to FIG. FIG. 63 is a diagram for describing an example of a remote provider.

  For example, if the is_exported attribute is set to true in the definition file or the like, the Join merge provider 13 and / or the sub-provider 14 may perform processing as a remote provider described later. Here, for example, when the provider is an authentication provider, as described above, the remote provider does not have the authentication engine itself, but uses the authentication engine included in another provider or the like to transmit the information from the client or the like. Is a provider that performs processing in response to a request. The definition file is included in, for example, the configuration manager 22 or the like.

For example, sub provider 14 _1, the service from the client or Join merge provider 13 or the like (e.g., authentication services, etc.) Upon receipt of the use request of the (sequence SQ20), for example with reference to the definition file and the like, Is_exported attribute whether true judge.

Sub provider 14 _1, when is_exported attribute is determined to be true, as the itself is remote provider, acquires connection destination information stored in the registry or the like, the service request with respect to the connection destination Transfer (sequence SQ21).

Sub provider 14 _n which has received the request for using the service, for example with reference to the definition file and the like, determines is_shared attribute whether true.

When determining that the is_shared attribute is true, the sub-provider 14 _n performs processing in response to a service use request and returns an execution result to the remote provider (sub-provider 14 ₁ ).

Upon receiving the execution result from the sub-provider 14 _n , the remote provider (sub-provider 14 ₁ ) adds necessary post-processing to the execution result, and sends the execution result obtained by adding the post-processing to the requesting client or the Join merge provider 13. And so on.

  Hereinafter, an example of the process related to the remote provider will be described with reference to FIG. FIG. 64 is a diagram illustrating an example of a process related to the remote provider.

In step S200, for example, sub provider 14 ₁ receives a service use request from the client or Join merge provider 13 or the like.

Proceeds following step S200 to step S201, the sub provider 14 ₁ refers to the definition file and the like, determines is_exported attribute whether true. Sub provider 14 _1, when is_exported attribute is determined to be true, the process proceeds to step S202, if it is determined that is_exported attribute is false, it is determined whether example is_shared attribute is true. Note that, for simplification of the description, the processing when it is determined that the is_exported attribute is false is omitted in FIG.

In step S202, the sub provider 14 _1, as a remote provider, acquires connection destination information that is stored in the registry or the like.

Proceeds following step S202 to step S203, the sub provider 14 ₁ transfers the service request received in step S200 to the connection destination acquired at step S202.

The process proceeds to step S204 following step S203, the sub-providers 14 _n of the destination, from the remote provider, receives a transfer service usage request.

The process proceeds to step S205 following step S204, the sub-providers 14 _n of the destination refers to the definition file and the like, determines is_shared attribute whether true. Sub provider 14 _n of the connection destination, the is_shared attribute is determined to be true, the process proceeds to step S206, if it is determined that is_shared attribute is false, return NG to remote providers.

In step S206, the sub-providers 14 _n of connection destination, from the configuration manager 22, reads the trust of the requesting remote provider.

Proceeds following step S206 to step S207, the sub-providers 14 _n of the destination determines the relevant sub provider 14 _n, and the requesting remote provider, whether trust is in the. Sub provider 14 _n of the connection destination, and the sub-providers 14 _n, and the requesting remote provider, to when it is determined that trust relationship exists, the flow proceeds to step S208, and the sub provider 14 _n, and the requesting remote provider , Return NG to the remote provider.

In step S208, the connection destination of the sub provider 14 _n is, executes processing in response to the request.

The process proceeds to step S209 following step S208, the sub-providers 14 _n of the connection destination returns the execution result to the requesting remote provider.

The process proceeds to step S210 following step S209, the remote provider, receives the execution result from the connection of the sub provider 14 _n.

  Proceeding to step S211 following step S210, the remote provider adds necessary post-processing to the execution result received in step S210.

  Proceeding to step S212 following step S211, the remote provider returns an execution result to which the necessary post-processing has been added in step S211 to the requesting client or the Join merge provider 13.

  In addition, in the third embodiment, the description has been made by taking the addition of the sub-provider 14 as an example, but the same applies to the registration of the sub-provider 14 when no sub-provider 14 is registered.

  Hereinafter, as shown in the third embodiment, information (configuration information) relating to the configuration of the Join merge provider 13 and the sub-provider 14 is taken out of the Join merge provider 13 and held by the configuration manager 22. Another example of the management will be described in the following embodiments.

  In the fourth embodiment, as described in the first and second embodiments, a description will be given using a Join merge provider (idJoin merge provider) having no integrated directory 180 in the Join merge provider 13.

  FIG. 65 is a diagram (part 5) for describing the configuration of the UCS. In FIG. 65, for simplicity of explanation, the description will be made assuming that the UCS49 includes all of the main sub-provider and the sub-sub-provider also in the idJoin merge provider. However, for example, a part or all of the main sub-provider and / or the sub-sub-provider may be included in another MFP 120 or the like.

  The UCS 49 shown in FIG. 65 includes a dispatcher 21, a configuration manager 22, an idJoin merge provider, a main sub-provider, and at least one or more sub-sub-providers.

  The dispatcher 21 receives the request from the client and distributes the request to the configuration manager 22 or the idJoin merge provider or the like, and sends the processing result processed by the configuration manager 22 or the idJoin merge provider or the like in response to the distributed request to the client. Or send.

  The configuration manager 22 is a management unit that manages the configuration of the idJoin merge provider, the main sub-provider, and at least one or more sub-sub-providers, and stores configuration information and the like in a storage unit.

  Hereinafter, an example of processing performed by the idJoin merge provider, the main sub-provider, and the sub-sub-provider will be described with reference to FIGS. FIG. 66 is a diagram for describing an example of a property addition sequence.

  As shown in FIG. 66, the client transmits a property addition request to the idJoin merge provider via the dispatcher 21 or the like (sequence SQ30).

  The idJoin merge provider that has received the property addition request acquires the session IDs of the main sub-provider and the sub-sub-provider from the session management unit 137 or the like in the idJoin merge provider (sequence SQ31).

  The idJoin merge provider sends a request for adding a property including the session ID of the main sub provider acquired in sequence SQ31 to the main sub provider (sequence SQ32).

  The main sub-provider adds a property value to the directory 150 based on the acquired property addition request (sequence SQ33).

  Further, the main sub-provider acquires all properties from the directory 150 and provides them to the idJoin merge provider (sequence SQ34).

  The idJoin merge provider acquires an entry ID for identifying a user or a group from all the properties of the acquired primary sub-provider (sequence SQ35), and acquires the session ID of the secondary sub-provider acquired in the sequence SQ31 and the sequence ID acquired in the sequence SQ35 A request for adding a property including the entry ID is transmitted to the sub-sub-provider (sequence SQ36).

  If the entry corresponding to the entry ID included in the acquired property addition request does not exist in the directory 150 of the sub-provider, the sub-sub provider newly adds the entry to the directory 150 (sequence SQ37), A property value is added to the entry, and if an entry corresponding to the entry ID exists in the directory 150 of the sub-sub-provider, the property value is added to the entry (sequence SQ38).

  By performing the processing shown in FIG. 66, it is possible to add a property to an entry having a matching entry ID, without the Join merge provider 13 holding the integrated directory 180.

  Hereinafter, an example of the property acquisition sequence will be described with reference to FIG. FIG. 67 is a diagram for describing an example of a property acquisition sequence.

  As shown in FIG. 67, the client transmits a property acquisition request to the idJoin merge provider via the dispatcher 21 or the like (sequence SQ40). An example of the property acquisition request is shown in FIG. 68 described later.

  The idJoin merge provider that has received the property acquisition request acquires the session IDs of the main sub-provider and the sub-sub-provider from the session management unit 137 or the like in the idJoin merge provider (sequence SQ41).

  The idJoin merge provider transmits a property acquisition request including the session ID of the main sub provider acquired in sequence SQ41 to the main sub provider (sequence SQ42).

  The main sub-provider acquires the value of the corresponding property from the directory 150 based on the acquired property acquisition request, and provides it to the idJoin merge provider (sequence SQ43).

  Further, the main sub-provider acquires all properties from the directory 150 and provides them to the idJoin merge provider (sequence SQ44).

  The idJoin merge provider acquires an entry ID for identifying a user or a group from all the properties of the acquired main sub-provider (sequence SQ45), and acquires the session ID of the sub-sub-provider acquired in sequence SQ41 and the sequence ID acquired in sequence SQ45. A property acquisition request including the entry ID is transmitted to the sub-sub-provider (sequence SQ46).

  The sub-sub-provider acquires the property value from the entry corresponding to the entry ID included in the acquired property acquisition request, and provides it to the idJoin merge provider (sequence SQ47).

  The idJoin merge provider merges the property of the main sub-provider acquired in sequence SQ43 with the property of each sub-sub-provider acquired in sequence SQ47, creates a property acquisition response including the resulting property, and dispatcher 21 etc. (SEQUENCE SQ48). An example of the property acquisition response is shown in FIG. 69 described later.

  By performing the processing as shown in FIG. 67, it is possible to acquire the properties of the entry with the matching entry ID without the Join merge provider 13 holding the integrated directory 180.

  Hereinafter, an example of the property acquisition request is shown in FIG. FIG. 68 is a diagram illustrating an example of the property acquisition request.

  FIG. 69 shows an example of the property acquisition response. FIG. 69 is a diagram illustrating an example of the property acquisition response.

  The <propVal> </ propVal> tag in FIG. 69 includes, for example, a user's mail address as a property value.

  Hereinafter, an example of the property update sequence will be described with reference to FIG. FIG. 70 is a diagram for describing an example of a property update sequence.

  As shown in FIG. 70, the client transmits a property update request to the idJoin merge provider via the dispatcher 21 or the like (sequence SQ50).

  The idJoin merge provider that has received the property update request acquires the session IDs of the main sub-provider and the sub-sub-provider from the session management unit 137 or the like in the idJoin merge provider (sequence SQ51).

  The idJoin merge provider transmits a property update request including the session ID of the main sub-provider acquired in sequence SQ51 to the main sub-provider (sequence SQ52).

  The main sub-provider updates the property value to the directory 150 based on the acquired property update request (sequence SQ53).

  Further, the main sub-provider acquires all properties from the directory 150 and provides them to the idJoin merge provider (sequence SQ54).

  The idJoin merge provider acquires the entry ID for identifying the user or group from all the properties of the acquired main sub-provider (sequence SQ55), and acquires the session ID of the sub-sub-provider acquired in sequence SQ51 and the sequence ID acquired in sequence SQ55. A request for updating the property including the entry ID is transmitted to the sub-sub-provider (sequence SQ56).

  If the entry corresponding to the entry ID included in the acquired property update request exists in the directory 150 of the sub-sub-provider, the sub-sub provider updates the property value of the entry (sequence SQ57).

  By performing the processing as shown in FIG. 70, it is possible to update the properties of the entry with the matching entry ID, without the Join merge provider 13 holding the integrated directory 180.

  Hereinafter, an example of the property deletion sequence will be described with reference to FIG. FIG. 71 is a diagram for describing an example of a property deletion sequence.

  As shown in FIG. 71, the client transmits a property deletion request to the idJoin merge provider via the dispatcher 21 or the like (sequence SQ60).

  The idJoin merge provider that has received the property deletion request acquires the session IDs of the main sub-provider and the sub-sub-provider from the session management unit 137 or the like in the idJoin merge provider (sequence SQ61).

  The idJoin merge provider transmits a property deletion request including the session ID of the main sub provider acquired in sequence SQ61 to the main sub provider (sequence SQ62).

  The main sub-provider deletes the value of the corresponding property in directory 150 based on the acquired property deletion request (sequence SQ63).

  Further, the main sub-provider acquires all properties from the directory 150 and provides them to the idJoin merge provider (sequence SQ64).

  The idJoin merge provider acquires an entry ID for identifying a user or a group from all the acquired properties of the main sub-provider (sequence SQ65), and acquires the session ID of the sub-sub-provider acquired in sequence SQ61 and the session ID of sequence SQ65. A property deletion request including the entry ID is transmitted to the sub-sub-provider (sequence SQ66).

  The sub-sub-provider deletes the property value of the entry corresponding to the entry ID included in the acquired property deletion request (sequence SQ67).

  By performing the processing as shown in FIG. 71, it is possible to delete the property of the entry with the matching entry ID without the Join merge provider 13 holding the integrated directory 180.

  FIG. 72 shows an example of a GUI in the client when the idJoin merge provider is applied to the MFP 120 or the like. FIG. 72 is a diagram illustrating an example of a GUI in a client when the idJoin merge provider is applied to a multifunction peripheral or the like.

  FIG. 72A is an example of a GUI in a client before applying the idJoin merge provider to the MFP 120 or the like. FIG. 72B is an example of a GUI on the client after the idJoin merge provider is applied to the MFP 120 or the like.

  In FIG. 72B, it is possible to add a value to the property of the entry whose entry ID matches.

  Although the preferred embodiments of the present invention have been described in detail, the present invention is not limited to the specific embodiments, and various modifications may be made within the scope of the present invention described in the appended claims.・ Change is possible.

FIG. 9 is a diagram for describing an example in which a user is authenticated using an authentication provider and a service provided by an application is used. FIG. 9 is a diagram for describing an example in which one Web portal supports a plurality of applications and a plurality of authentication directory providers. FIG. 9 is a diagram for describing an example in which access modules in a Web portal are integrated into one. FIG. 4 is a diagram illustrating an example in which a new application is added to the configuration of FIG. 3. It is a figure for explaining an example which introduced Local Authentication directory provider. FIG. 6 is a diagram for explaining an example of members of a group registered in the local authentication directory provider 12 shown in FIG. FIG. 9 is a diagram for explaining a problem of a conventional provider. FIG. 11 is a diagram for explaining an example in which a Join merge provider according to the present invention is introduced. FIG. 9 is a diagram for explaining an example of members of a group registered in the local authentication directory provider shown in FIG. FIG. 9 is a diagram illustrating an example of a structure of a user ID of the local authentication directory provider illustrated in FIG. 8. FIG. 1 is a configuration diagram of an embodiment of a fusion machine according to the present invention. FIG. 2 is a hardware configuration diagram of an embodiment of the multifunction peripheral according to the present invention. FIG. 3 is a diagram (part 1) for describing a configuration of a UCS. FIG. 4 is a diagram (part 2) for describing the configuration of the UCS. FIG. 10 is a diagram (part 3) for describing the configuration of the UCS. It is a functional block diagram of a Join merge provider and a sub provider in the first embodiment of the present invention. It is a conceptual diagram for demonstrating the structure of the session ticket of a Join merge provider. FIG. 9 is a diagram for describing an example of a modification of data of a directory operation wrapper. It is a flowchart of an example of the belonging group acquisition process of the user in the Join merge provider. It is a flowchart of an example of a user's belonging group acquisition process in a sub provider. 11 is an XML message as an example of a group acquisition request from a client to a Join merge provider. 8 is an XML message as an example of a group acquisition request from a Join merge provider to a Local directory provider which is one of sub-providers. 13 is an XML message as an example of a group acquisition request from a Join merge provider to a WinNT4 directory provider which is one of sub-providers. 9 is an XML message of an example of a group acquisition request from a Join merge provider to a Notes (registered trademark) R5 directory provider which is one of sub-providers. It is an XML message as an example of a group acquisition response from a Local directory provider, which is one of the sub-providers, to a Join merge provider. It is an XML message of an example of a group acquisition response from a WinNT4 directory provider, which is one of the sub-providers, to a Join merge provider. It is an XML message of an example of a group acquisition response from a Notes (registered trademark) R5 directory provider, which is one of the sub-providers, to a Join merge provider. 11 is an XML message as an example of a group acquisition response from a Join merge provider to a client. It is a functional block diagram of a Join merge provider and a sub provider in a second example of the present invention. It is a conceptual diagram for demonstrating the structure of the authentication ticket of a Join merge provider. FIG. 4 is a conceptual diagram (part 1) of data managed in an integrated directory. It is a flowchart of an example of the authentication ticket creation processing in the Join merge provider. It is a flowchart of an example of an authentication ticket creation process in a sub provider. It is a flowchart of an example of the authentication ticket ID confirmation processing in a sub provider. 9 is an XML message as an example of an authentication ticket creation request from a client to a Join merge provider. 9 is an XML message of an example of an authentication ticket creation request from a Join merge provider to a sub provider. It is an XML message of an example of an authentication ticket creation response from a sub-sub-provider to a Join merge provider. It is an XML message of an example of an authentication ticket ID confirmation request from a Join merge provider to a sub-sub-provider. It is an XML message of an example of an authentication ticket ID confirmation response from a sub-sub-provider to a Join merge provider. 9 is an XML message of an example of an authentication ticket creation request from a Join merge provider to a main sub provider. 13 is an XML message as an example of an authentication ticket creation response from the main sub provider to the Join merge provider. 9 is an XML message as an example of an authentication ticket creation response from a Join merge provider to a client. It is a flowchart of an example of the authentication ticket ID confirmation processing in a Join merge provider. 10 is an XML message as an example of an authentication ticket ID confirmation request from a client to a Join merge provider. It is an XML message of an example of an authentication ticket ID confirmation request from a Join merge provider to a main sub provider. It is an XML message as an example of an authentication ticket ID confirmation response from the main sub provider to the Join merge provider. It is an XML message of an example of an authentication ticket ID confirmation response from a Join merge provider to a client. FIG. 9 is a conceptual diagram (part 2) of data managed in an integrated directory. FIG. 11 is a diagram for describing an example of reading an IC card using a Join merge provider, authenticating a user, and acquiring a stored document stored in a repository service. FIG. 11 is a diagram (part 4) for describing the configuration of the UCS. FIG. 9 is a diagram for describing an example of a provider list acquisition sequence. 8 is an XML message of an example of a provider list acquisition request from a client to a dispatcher. 8 is an XML message as an example of a provider list acquisition response from a dispatcher to a client. It is a figure for explaining an example of a sub provider addition sequence. 9 is an XML message of an example of a sub-provider addition request from a client to a dispatcher. 9 is an XML message as an example of a sub-provider addition response from a dispatcher to a client. FIG. 2 is a hardware configuration diagram of an example of a client. It is a functional block diagram of a client. FIG. 11 is a diagram (part 1) illustrating a GUI related to provider settings in the client. FIG. 11 is a diagram (part 2) illustrating a GUI related to the setting of the provider in the client. FIG. 11 is a diagram (part 3) illustrating a GUI related to the setting of the provider in the client. FIG. 14 is a diagram (part 4) illustrating a GUI related to setting of a provider in a client. FIG. 3 is a diagram for describing an example of a remote provider. FIG. 9 is a diagram for describing an example of a process related to a remote provider. FIG. 11 is a diagram (No. 5) for describing the configuration of the UCS. FIG. 9 is a diagram for describing an example of a property addition sequence. FIG. 9 is a diagram for describing an example of a property acquisition sequence. FIG. 6 is a diagram illustrating an example of a property acquisition request. FIG. 9 is a diagram illustrating an example of a property acquisition response. FIG. 9 is a diagram for describing an example of a property update sequence. FIG. 9 is a diagram for explaining an example of a property deletion sequence. FIG. 9 is a diagram illustrating an example of a GUI in a client when an idJoin merge provider is applied to a multifunction peripheral or the like.

Explanation of reference numerals

DESCRIPTION OF SYMBOLS 1 Web browser 2 Web portal 3 Application 4 Authentication directory provider 5 Windows (registered trademark) application 6 Notes (registered trademark) application 7 Windows (registered trademark) authentication directory provider 8 Notes (registered trademark) authentication directory provider 9 Provider 10 Access module 11 Application 12 Local Authentication Directory Provider 13 Join Merge Provider 14 Sub Provider 15 Monochrome Line Printer 16 Color Line Printer 17 Hardware Resources 20 Software Group 30 Application 31 Printer Application 32 Copy Application 33 Fax Application 34 Scanner Application 35 Net File Application 36 Process Inspection Application 40 platform 4 Operating system (OS)
42 System Control Service (SCS)
43 System Resource Manager (SRM)
44 Engine Control Service (ECS)
45 Memory Control Service (MCS)
46 Operation Panel Control Service (OCS)
47 Fax Control Service (FCS)
48 Network Control Service (NCS)
49 User Information Management Service (UCS)
50 MFP starter 60 Controller board 61 CPU
62 ASIC (Application Specific Integrated Circuit)
63 SRAM (Static RAM)
64 SDRAM (Synchronous DRAM)
65 Flash memory 66 Hard disk drive (HDD)
70 Operation panel 80 Fax control unit (FCU)
90 USB device 100 IEEE 1394 device 110 Engine unit 120 Multifunction machine 130 Provider I / F
131 XML processing unit 132 UID conversion unit 133 merge processing unit 134 sub-provider calling unit 135 merge provider XML processing unit 136 sub-provider registration unit 137 session management unit 138 integrated directory 141 directory operation wrapper 142 session management unit 150 directory 152 user information storage unit 153 Group information storage section 160 Local directory provider 161 WinNT4 directory provider 162 Notes (R) R5 directory provider 170 Repository service 200 Session ticket (Session ticket of Join merge provider)
210 Session ticket ID (ID of session ticket of Join merge provider)
220 Main Sub Provider 230 IC Card Authentication Local Provider (Sub Sub Provider)
300 session ticket (sub-provider anonymous session ticket)
310 Session ticket ID (ID of sub-provider anonymous session ticket)
400 session ticket (sub-provider session ticket)
500 Authentication Ticket (Join Merge Provider Authentication Ticket)
510 Authentication ticket ID (ID of authentication ticket of Join merge provider)
600 Authentication Ticket (Subprovider Authentication Ticket)
610 Authentication ticket ID (ID of sub-provider authentication ticket)
700 Session Ticket (Repository Service Session Ticket)
710 Session ticket ID (ID of repository service session ticket)

Claims (35)

A merged information providing apparatus having a merged user information providing unit that sets a plurality of user information providing units that provide information about a user as lower order user information providing units,
The user information providing means whose use is permitted does not distinguish between users, and information on the user of the same user registered in another user information providing means together with the user information providing means whose use is permitted is obtained. And a combined information providing apparatus for combining and providing the acquired information on the user. Identification information management means for managing identification information for identifying the user registered in the user information provision means,
User information obtaining means for obtaining information on the user from the user information providing means,
2. The merged information providing apparatus according to claim 1, further comprising: a user information merging unit that merges information on the user acquired by the user information acquiring unit.   3. The apparatus according to claim 2, wherein the identification information management unit provides the identification information of the same user to the user information acquisition unit in response to a request from the user information acquisition unit.   The user information obtaining means obtains information on the user from the user information providing means using the identification information and use permission information permitting use of the user information providing means. 3. The merged information providing device according to 2 or 3.   The apparatus according to claim 1, further comprising a setting unit configured to set the lower-level user information providing unit in response to a request. A merged information providing apparatus having a merged user information providing unit that provides a plurality of user information providing units for providing information related to a user and providing an authentication service related to the user as lower order user information providing units,
The user information providing means for which use has been permitted and / or authenticated does not distinguish the user, and the user information providing means for which use has been permitted and / or authenticated is provided together with the other user information providing means. A merged information providing apparatus for acquiring information about a user of the same user registered in a means, and merging and providing the acquired information about the user. Identification information management means for managing identification information for identifying the user registered in the user information provision means,
User information obtaining means for obtaining information on the user from the user information providing means,
7. The merged information providing apparatus according to claim 6, further comprising: user information merging means for merging the information on the user acquired by the user information acquiring means.   8. The apparatus according to claim 7, wherein the identification information management unit provides the identification information of the same user to the user information acquisition unit in response to a request from the user information acquisition unit.   The user information obtaining means obtains information on the user from the user information providing means using the identification information and use permission information permitting use of the user information providing means. 7. The merged information providing device according to 7 or 8.   10. The merged information providing apparatus according to claim 6, further comprising setting means for setting the lower-level user information providing means in response to a request. A merged information providing apparatus having merged user information providing means for providing information related to a user and providing an authentication service related to the user, wherein the main user information providing means and the sub user information providing means are lower order user information providing means. ,
The user information providing means for which use has been permitted and / or authenticated does not distinguish the user, and the user information providing means for which use has been permitted and / or authenticated is provided together with the other user information providing means. A merged information providing apparatus for acquiring information about a user of the same user registered in a means, and merging and providing the acquired information about the user.   12. The merged information providing apparatus according to claim 11, further comprising an authentication information acquiring unit that acquires, from the main user information providing unit, first authentication information for authenticating the user in the main user information providing unit.   Using the first authentication information acquired by the authentication information acquiring means, a second authentication information creating means for creating second authentication information for authenticating the user in the merged user information providing means including the first authentication information 13. The merged information providing device according to claim 12, further comprising:   14. The combined information providing apparatus according to claim 13, further comprising a second authentication information providing unit that provides the second authentication information to a client that has requested authentication.   15. The merged information providing apparatus according to claim 11, further comprising a setting unit configured to set the lower-level user information providing unit in response to a request. An information providing device having user information providing means for providing information related to a user,
The user information providing means,
The user information providing means and / or other user information providing means are registered in the user information providing means and / or other user information providing means in response to a request from the merged user information providing means having the lower level user information providing means. An information providing apparatus, comprising: a user information providing unit that provides information on a user corresponding to identification information for identifying a user who is performing the connection to the combined user information providing unit.   17. The information providing apparatus according to claim 16, wherein the user information providing unit further includes a user information storage unit that stores information on the user.   The information related to the user is user information and / or group information to which the user belongs, and the group information includes user information and / or group information of another user information providing unit. Item 18. The information providing device according to Item 16 or 17. An information providing apparatus having user information providing means for providing information related to a user and providing an authentication service related to the user,
The user information providing means,
The user information providing means and / or other user information providing means are registered in the user information providing means and / or other user information providing means in response to a request from the merged user information providing means having the lower level user information providing means. An information providing apparatus, comprising: a user information providing unit that provides information on a user corresponding to identification information for identifying a user who is performing the connection to the combined user information providing unit.   18. The information providing apparatus according to claim 17, wherein the user information providing unit further includes a user information storage unit that stores information on the user.   The information related to the user is user information and / or group information to which the user belongs, and the group information includes user information and / or group information of another user information providing unit. Item 21. The information providing device according to Item 19 or 20.   The management apparatus according to any one of claims 1 to 15, further comprising: a setting request transmitting unit configured to transmit information related to a setting of the lower-level user information providing unit.   23. The management apparatus according to claim 22, further comprising setting screen display means for displaying a screen relating to setting of said combined user information providing means and said lower-level user information providing means. A merged user information providing method in a merged user information providing means in which a plurality of user information providing means for providing information relating to a user is a lower order user information providing means,
The user information providing means whose use is permitted does not distinguish between users, and information on the user of the same user registered in another user information providing means together with the user information providing means whose use is permitted is obtained. And providing the combined information on the acquired users in a combined manner. A merged user information providing method in a merged user information providing unit, wherein a plurality of user information providing units that provide information related to a user and provide an authentication service related to the user are lower order user information providing units,
The user information providing means for which use has been permitted and / or authenticated does not distinguish the user, and the user information providing means for which use has been permitted and / or authenticated is provided together with the other user information providing means. A method for providing combined information, comprising: obtaining information on a user of the same user registered in a means; and providing the obtained information on the user in a combined manner. A merged user information providing method in a merged user information providing means, wherein a main user information providing means and a sub user information providing means for providing information relating to a user and providing an authentication service relating to the user are provided as lower order user information providing means. ,
The user information providing means for which use has been permitted and / or authenticated does not distinguish the user, and the user information providing means for which use has been permitted and / or authenticated is provided together with the other user information providing means. A method for providing combined information, comprising: obtaining information on a user of the same user registered in a means; and providing the obtained information on the user in a combined manner. An information providing method in a user information providing means for providing information about a user,
The user information providing means and / or other user information providing means are registered in the user information providing means and / or other user information providing means in response to a request from the merged user information providing means having the lower level user information providing means. An information providing method, comprising the step of providing user information corresponding to a user corresponding to identification information for identifying a user to be provided to the combined user information providing means. An information providing method in a user information providing unit that provides information related to a user and provides an authentication service related to the user,
The user information providing means and / or other user information providing means are registered in the user information providing means and / or other user information providing means in response to a request from the merged user information providing means having the lower level user information providing means. An information providing method, comprising the step of providing user information corresponding to a user corresponding to identification information for identifying a user to be provided to the combined user information providing means.   27. A setting request transmitting step of transmitting a request relating to setting of said lower-level user information providing means to a combined information providing apparatus including the combined user information providing means according to claim 24. How to manage.   A combined information providing program for causing a computer to execute the combined information providing method according to any one of claims 24 to 26.   An information providing program for causing a computer to execute the information providing method according to claim 27 or 28.   A management program for causing a computer to execute the management method according to claim 29.   A computer-readable recording medium recording the merged information providing program according to claim 30.   A computer-readable recording medium recording the information providing program according to claim 31. A computer-readable recording medium on which the management program according to claim 32 is recorded.

Images