JP2017097652A - Management system, communication system, communication control method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a management system, communication system, communication control method, and program that can control access to a message every service used by a client in the communication system.SOLUTION: A transmission/reception unit of a management system 50 accepts a publish request for a message for a topic from a terminal 10b authenticated by a first client, and on the other hand accepts a subscription request for a message for the topic from a terminal 10a authenticated by a second client. A publication processing unit and a subscription processing unit of the management system 50 control delivery of a message to the terminal 10a on the basis of whether the topic is associated with each service used by the first client and the second client.SELECTED DRAWING: Figure 9

Description

  The present invention relates to a management system, a communication system, a communication control method, and a program.

  2. Description of the Related Art In recent years, communication systems that perform calls, conferences, and the like via communication networks such as the Internet and dedicated lines have become widespread along with requests for reducing expenses and time required for movement of parties. In such a communication system, when communication is started between communication terminals, content data such as image data and sound data is transmitted and received, thereby realizing communication between parties. As a method for transmitting content data between communication terminals, a publish-subscribe model (Publish-Subscribe model, hereinafter referred to as a PubSub model) is known.

  For example, U.S. Pat. No. 6,057,051 provides access control in either a content-based publishing system or a subscribing system that delivers messages from an issuing client to a subscribing client via multiple routing broker machines. A method is disclosed. In this method, the routing broker machine chooses a starting point for establishing a new access control rule. A message before the start point is delivered to the client if and only if the message satisfies the subscription filter and the access filter before the change associated with the access control version identifier. Messages after the point are delivered to the client if the message satisfies both the subscription filter and the access filter since the change associated with the access control version identifier.

  According to the publishing system or the subscribing system of Patent Document 1, it is possible to change a rule for controlling access to a message by a client before and after a starting point for establishing a new access control rule. However, according to the conventional PubSub model communication system, there arises a problem that access to a message cannot be controlled for each service used by a client.

  The management system of the invention according to claim 1 receives a request for distributing information of a predetermined attribute from the first communication terminal authenticated by the first client, while receiving the information of the predetermined attribute. Receiving means from a second communication terminal authenticated by the second client, a first service used by the first client, and a second service used by the second client, Distribution control means for controlling distribution of information of the predetermined attribute to the second communication terminal based on whether each is associated with the predetermined attribute.

  As described above, according to the present invention, it is possible to control access to a message for each service used by a client in a communication system.

1 is a schematic diagram of a communication system according to an embodiment of the present invention. It is a hardware block diagram of the terminal which concerns on one Embodiment. It is a hardware block diagram of the management system which concerns on one Embodiment. It is a software block diagram of the terminal which concerns on one Embodiment. It is each functional block diagram of the terminal which concerns on one Embodiment, an authentication server, and a management system. It is a conceptual diagram which shows each management table which an authentication server manages. It is a conceptual diagram which shows each management table which a management system manages. It is a sequence diagram which shows the authentication process in one Embodiment. It is a sequence diagram which shows an example of the process which pubs and subs a message. It is the flowchart which showed an example of the process which judges whether it has the authority to sub-message. It is the flowchart which showed an example of the process which judges whether it has the authority to publish a message. It is a conceptual diagram which shows the authority to pub or sub.

  Hereinafter, embodiments of the present invention will be described.

<< Outline of communication system >>
FIG. 1 is a schematic diagram of a communication system according to an embodiment of the present invention. As shown in FIG. 1, the communication system 1 is constructed by a communication terminal 10, an authentication server 40, and a management system 50. Hereinafter, the communication terminal 10 is simply referred to as the terminal 10.

  In the publish-subscribe (hereinafter referred to as “PubSub”) model, the management system 50 receives a message from a client (Publish, hereinafter referred to as “pub”) or a message in order to exchange messages between the clients. It is a server that accepts subscription requests (subscribe, hereinafter referred to as sub). The management system 50 may implement, for example, MQTT (MQ Telemetry Transport) or XMPP (eXtensible Messaging and Presence Protocol) PubSub extension (XEP-0060) as a protocol corresponding to the PubSub model.

  The terminal 10 is, for example, a general-purpose terminal, and an arbitrary client application is installed. Hereinafter, the client application is referred to as a client application. The terminal 10 is a dedicated terminal, for example, and has a specific client application that operates as a client. When the terminal 10 is communicably connected to the management system 50 via the communication network 2, each client can request the management system 50 for a message pub or a message sub. The terminal 10 may be, for example, a video conference terminal, an electronic blackboard, an electronic signboard, a telephone, a tablet, a smartphone, a camera, a PC (personal computer), or the like.

  The authentication server 40 is a server that authenticates a “client” that is a client application running on the terminal 10 and a “user” that uses the client, and authorizes the use of the management system 50. In order to realize the above authentication and authorization, the management system 50 implements an authentication and authorization protocol such as OAuth 2.0 and OpenID Connect, for example.

  In FIG. 1, the case where the management system 50 and the authentication server 40 are each one device has been described for the sake of simplicity, but the present invention is not limited to such an embodiment. At least one of the management system 50 and the authentication server 40 may be constructed by a plurality of devices. Further, the management system 50 and the authentication server 40 may be constructed by a single system or apparatus. Further, in FIG. 1, the case where four terminals 10 are provided in the communication system 1 is described for the sake of simplicity, but the present invention is not limited to such an embodiment. The number of terminals 10 provided in the communication system 1 may be two, three, or five or more. Further, the terminals 10 may be the same type or different types as shown in FIG.

<< Hardware configuration >>
Next, the hardware configuration of each device constituting the communication system 1 will be described.

  FIG. 2 is a hardware configuration diagram of the terminal 10 according to an embodiment. As long as communication is possible, the hardware configuration of the terminal 10 is not limited to the configuration shown in FIG. For example, the terminal 10 may include a configuration not illustrated in FIG. 2 or may not include a part of the configuration illustrated in FIG. 2 may be an external device or the like that can be connected to the terminal 10. As shown in FIG. 2, the terminal 10 according to the present embodiment has programs used for driving the CPU 101 such as a CPU (Central Processing Unit) 101 and an IPL (Initial Program Loader) for controlling the operation of the terminal 10 as a whole. A ROM (Read Only Memory) 102, a RAM (Random Access Memory) 103 used as a work area of the CPU 101, a flash memory for storing various data such as programs for various terminals of the terminal 10, image data, and sound data 104, reading or writing data to or from a recording medium 106 such as an SSD (Solid State Drive) 105 that controls reading or writing of various data to the flash memory 104 according to the control of the CPU 101, or a flash memory or an IC card (Integrated Circuit Card). Media I / F 107 that controls the storage) An operation button 108 that is operated when selecting a power source, a power switch 109 for switching on / off the power of the terminal 10, and a network I / F (Interface) 111 for data transmission using the communication network 2. It has.

  The terminal 10 also includes a built-in camera 112 that captures an image of a subject under the control of the CPU 101 to obtain image data, an image sensor I / F 113 that controls driving of the camera 112, a built-in microphone 114 that inputs sound, and sound. The built-in speaker 115 that outputs the sound, the sound input / output I / F 116 that processes the input / output of the audio signal between the microphone 114 and the speaker 115 according to the control of the CPU 101, and the image data on the external display 120 according to the control of the CPU 101 As shown in FIG. 2, a display I / F 117 for transmission, an external device connection I / F 118 for connecting various external devices, an alarm lamp 119 for notifying abnormality of various functions of the terminal 10, and the above-described components are shown. A bus line 110 such as an address bus or a data bus for electrical connection There.

  The display 120 is a display unit configured by liquid crystal or organic EL (Organic Electroluminescence) that displays an image of a subject, an operation, and the like. The display 120 is connected to the display I / F 117 by a cable 120c. The cable 120c may be an analog RGB (VGA) signal cable, a component video cable, HDMI (High-Definition Multimedia Interface) or DVI (Digital Video). Interactive) signal cable may be used.

  The camera 112 includes a lens and a solid-state image sensor that converts light into electric charges and digitizes a subject image (video). As the solid-state image sensor, a CMOS (Complementary Metal Oxide Semiconductor) or a CCD (Charge Coupled Device) is used. Etc. are used.

  External devices such as an external camera, an external microphone, and an external speaker are electrically connected to the external device connection I / F 118 by a USB (Universal Serial Bus) cable or the like inserted into the connection port 1132 of the housing 1100. Can be connected to. When an external camera is connected, the external camera is driven in preference to the built-in camera 112 under the control of the CPU 101. Similarly, when an external microphone is connected or when an external speaker is connected, each of the external microphones and the built-in speaker 115 is given priority over the internal microphone 114 and the internal speaker 115 according to the control of the CPU 101. An external speaker is driven.

  The recording medium 106 is detachable from the terminal 10. Further, as long as it is a non-volatile memory that reads or writes data according to the control of the CPU 101, not only the flash memory 104 but also an EEPROM (Electrically Erasable and Programmable ROM) or the like may be used.

  FIG. 3 is a hardware configuration diagram of the management system 50 according to the embodiment. The management system 50 includes a CPU 501 that controls the overall operation of the management system 50, a ROM 502 that stores a program used to drive the CPU 501 such as an IPL, a RAM 503 that is used as a work area for the CPU 501, a program for the management system 50, and the like. HD 504 for storing data, HDD (Hard Disk Drive) 505 for controlling reading or writing of various data to the HD 504 according to the control of the CPU 501, media for controlling reading or writing (storage) of data to a recording medium 506 such as a flash memory Drive 507, display 508 for displaying various information such as a cursor, menu, window, character, or image, network I / F 509 for data communication using communication network 2, character A keyboard 511 having a plurality of keys for inputting numerical values and various instructions, a mouse 512 for selecting and executing various instructions, selecting a processing target, moving a cursor, etc., and a CD as an example of a removable recording medium A CD-ROM drive 514 for controlling reading or writing of various data to / from a ROM (Compact Disc Read Only Memory) 513, and an address for electrically connecting the above components as shown in FIG. A bus line 510 such as a bus or a data bus is provided.

  Since the authentication server 40 has the same hardware configuration as that of the management system 50, the description thereof is omitted.

<< Software configuration >>
FIG. 4 is a software configuration diagram of the terminal 10 according to an embodiment. As shown in FIG. 4, the OS 1020 and the client applications (1031 and 1032) operate on the work area 1010 of the RAM 103 of the terminal 10. The OS 1020 and the client applications (1031, 1032) are installed in the terminal 10.

  The OS 1020 is basic software that provides basic functions to the terminal 10 and manages the entire terminal 10. The client applications (1031, 1032) are applications for requesting authentication from the authentication server 40 and executing at least one of a pub request and a sub request from the management system 50.

  In FIG. 4, at least two client applications (1031 and 1032) are installed in the terminal 10, but any number of one or more client applications may be installed in the terminal 10. Further, an arbitrary application is operating on the OS 1020, and the client application may be operated on the arbitrary application.

<< Functional configuration >>
Next, the functional configuration of this embodiment will be described. FIG. 5 is a functional block diagram of the terminal 10, the authentication server 40, and the management system 50 that constitute a part of the communication system 1 according to an embodiment. In FIG. 5, the terminal 10, the authentication server 40, and the management system 50 are connected so that data communication can be performed via the communication network 2.

<Functional configuration of terminal>
The terminal 10 includes a transmission / reception unit 11, an operation input reception unit 12, a display control unit 13, an authentication request unit 14, a pub request unit 15, a sub request unit 16, and a storage / reading unit 19. Each of these units is a function realized by any one of the constituent elements shown in FIG. 2 operating according to a command from the CPU 101 according to a program expanded from the flash memory 104 onto the RAM 103. Further, the terminal 10 has a storage unit 1000 constructed by the ROM 102, the RAM 103, and the flash memory 104 shown in FIG.

(Functional configuration of terminal)
Next, each functional configuration of the terminal 10 will be described in detail with reference to FIGS. 2 and 5. In the following, in describing each functional configuration of the terminal 10, a relationship between main components for realizing each functional configuration of the terminal 10 among the respective components illustrated in FIG. 2 will also be described. .

  The transmission / reception unit 11 is realized by a command from the CPU 101 and a network I / F 111, and transmits / receives various data (or information) to / from a partner terminal, each device, system, or the like via the communication network 2.

  The operation input receiving unit 12 is realized by an instruction from the CPU 101, the operation button 108, and the power switch 109, and receives various inputs by the user and various selections by the user.

  The display control unit 13 is realized by an instruction from the CPU 101 and the display I / F 117 and performs control for transmitting image data sent from the other party to the display 120 when making a call.

  The authentication request unit 14 is realized by a command from the CPU 101 according to the client application, and requests the authentication server 40 for authentication. When a plurality of client applications are installed in the terminal 10, the authentication request unit 14 is generated in the terminal 10 for each activated client application.

  The pub request unit 15 is realized by a command from the CPU 101 according to the client application, and issues a message pub request to the management system 50. If the client application supports sub but does not support pub, the terminal 10 does not generate the pub request unit 15. When a plurality of client applications corresponding to pub are installed in the terminal 10, a pub request unit 15 is generated in the terminal 10 for each activated client application.

  The sub request unit 16 is implemented by a command from the CPU 101 according to the client application, and makes a message sub request to the management system 50. If the client application supports pub but does not support sub, the terminal 10 does not generate the sub request unit 16. Further, when a plurality of client applications corresponding to sub are installed in the terminal 10, a sub request unit 16 is generated in the terminal 10 for each activated client application.

  The storage / reading unit 19 is executed by an instruction from the CPU 101 and the SSD 105, or realized by an instruction from the CPU 101, stores various data in the storage unit 1000, and extracts various data stored in the storage unit 1000. Perform the process.

<Functional configuration of authentication server>
The authentication server 40 includes a transmission / reception unit 41, a user authentication unit 42, a client authentication unit 43, an authorization unit 44, a token issuing unit 45, and a storage / reading unit 49. Each of these units is a function realized by any one of the constituent elements shown in FIG. 3 operating according to a command from the CPU 501 according to the program for the authentication server 40 expanded from the HD 504 onto the RAM 503. is there. Further, the authentication server 40 has a storage unit 4000 constructed by the HD 504.

(User management table)
FIG. 6A is a conceptual diagram showing a user management table. In the storage unit 4000, a user management DB 4001 is constructed by a user management table. In the user management table, a user name and a password are associated and managed for each user ID (identifier, identification).

(Client management table)
FIG. 6B is a conceptual diagram showing a client management table. In the storage unit 4000, a client management DB 4002 is constructed by a client management table. In the client management table, a client name and a password are associated and managed for each client ID.

(Service management table)
FIG. 6C is a conceptual diagram illustrating a service management table. In the storage unit 4000, a service management DB 4003 is constructed by a service management table. In the service management table, a service name is associated with each service ID and managed.

(Service authorization management table)
FIG. 6D is a conceptual diagram showing a service authorization management table. In the storage unit 4000, a service authorization management DB 4004 is constructed by a service authorization management table. In the service authorization management table, the service ID of the service and the client ID of the client authorized to access the service are associated and managed.

(Functional configuration of authentication server)
The transmission / reception unit 41 is realized by a command from the CPU 501 and a network I / F 509, and transmits / receives various data (or information) to / from a partner terminal, each device, system, or the like via the communication network 2.

  The user authentication unit 42 is realized by a command from the CPU 501 and performs user authentication in response to a request from the client.

  The client authentication unit 43 is realized by a command from the CPU 501 and performs client authentication in response to a request from the client.

  The authorization unit 44 is realized by an instruction from the CPU 501 and authorizes the client by designating the access right of the client to the service.

  The token issuing unit 45 is realized by an instruction from the CPU 501, and issues an authorization token used in the service when the client accesses the service.

  The storage / reading unit 49 is executed by an instruction from the CPU 501 and the HDD 505 or realized by an instruction from the CPU 501, and stores various data in the storage unit 4000 or extracts various data stored in the storage unit 4000. Perform the process.

<Functional configuration of management system>
The management system 50 includes a transmission / reception unit 51, a token confirmation unit 52, a pub processing unit 53, a sub processing unit 54, and a storage / reading unit 59. Each of these units is a function realized by any one of the constituent elements shown in FIG. 3 operating according to a command from the CPU 501 in accordance with the program for the management system 50 expanded from the HD 504 onto the RAM 503. is there. In addition, the management system 50 includes a storage unit 5000 constructed by the HD 504.

(Topic management table)
FIG. 7A is a conceptual diagram showing a topic management table. In the storage unit 5000, a topic management DB 5001 is constructed by a topic management table. In the topic management table, topic names are managed in association with each topic ID. A topic is an attribute associated with a message. When the client application specifies a topic and makes a sub request, the management system 50 transmits a message published in association with the topic to the client application that is the sub request source for the topic.

(User topic management table)
FIG. 7B is a conceptual diagram showing a user topic management table. In the storage unit 5000, a user topic management DB 5002 is constructed by a user topic management table. In the user topic management table, the user ID of the user, the topic ID of the topic, and authority information indicating the authority to permit the request when the user requests pub or sub of the topic are associated and managed. The authority information “pub” indicates that the user has authority to permit pub, the authority information “sub” indicates that the user has authority to allow sub, and the authority information “pubsub” has the authority to allow pub and sub. Indicates that there is.

(User service management table)
FIG. 7C is a conceptual diagram illustrating a user service management table. In the storage unit 5000, a user service management DB 5003 is constructed by a user service management table. In the user service management table, the user ID of the user, the service ID of the service, and authority information indicating the authority to permit the request when the user requests pub or sub using the service are managed in association with each other. Yes.

(User client management table)
FIG. 7D is a conceptual diagram illustrating a user client management table. In the storage unit 5000, a user client management DB 5004 is constructed by a user client management table. In the user client management table, the user ID of the user, the client ID of the client, and authority information indicating the authority to permit the request when the user requests pub or sub from the client are associated and managed.

(Client topic management table)
FIG. 7E is a conceptual diagram showing a client topic management table. In the storage unit 5000, a client topic management DB 5005 is constructed by a client topic management table. In the client topic management table, the topic ID of the topic, the client ID of the client, and authority information indicating the authority to permit the request when the client requests the pub or sub of the topic are associated and managed.

(Client service management table)
FIG. 7F is a conceptual diagram illustrating a client service management table. In the storage unit 5000, a client service management DB 5006 is constructed by a client service management table. In the client service management table, a service ID of a service and a client ID of a client authorized to access the service are associated and managed.

(Service topic management table)
FIG. 7G is a conceptual diagram showing a service topic management table. In the storage unit 5000, a service topic management DB 5007 is constructed by a service topic management table. In the service topic management table, when requesting a pub or sub of a topic using a service service ID, a topic topic ID, and a service, authority information indicating authority to permit the request is associated and managed. Yes.

(Service inheritance management table)
FIG. 7H is a conceptual diagram showing a service inheritance management table. In the storage unit 5000, a service inheritance management DB 5008 is constructed by the service inheritance management table. In the service inheritance management table, the service ID of the inherited service and the service ID of the inherited service are managed in association with each other. The right to pub or sub for a topic is inherited between services associated in the service inheritance management table.

  FIG. 12A is a conceptual diagram illustrating authority to pub or sub according to an embodiment. Each user has the authority to pub or message messages from the associated client in the user client management table. Each client can use a service associated with the client service management table. Further, by using each service, the authority to pub and sub a message of a specific topic associated with the service in the service topic management table can be obtained. The authority to pub or sub is inherited between services associated in the service inheritance management table. In this way, by associating the authority to pub or sub with the service, it is not necessary to build a platform for each service, but also inherit the authority for the existing service when starting to provide a new service It becomes possible.

  FIG. 12B is a conceptual diagram showing authority to pub or sub according to a comparative example. In the comparative example in which the authority to pub or sub is not associated with the service, the request source can pub or sub the topic related to the request regardless of which service is used. For this reason, since it becomes necessary to construct a platform for each service or to construct a platform for each service in which a common topic is handled, expandability deteriorates.

(Session management table)
FIG. 7I is a conceptual diagram showing a session management table. In the storage unit 5000, a session management DB 5014 is constructed by a session management table. As will be described later, when login authentication is performed using a user ID and a client ID, a session between the terminal 10 and the management system 50 is established. Further, the terminal 10 is authorized to access the service. In the session management table, a user ID on the terminal 10 side used for login authentication, a client ID, a service ID of an authorized service, and a topic ID to be sub-used using an established session are associated and managed.

(Functional configuration of the management system)
Next, each functional configuration of the management system 50 will be described in detail. In the following, in describing each functional configuration of the management system 50, among the components shown in FIG. 3, the relationship with the main components for realizing each functional configuration of the management system 50 is also described. explain.

  The transmission / reception unit 51 is realized by an instruction from the CPU 501 and a network I / F 509, and transmits / receives various data (or information) to / from each terminal, device, or system via the communication network 2.

  The token confirmation unit 52 is realized by an instruction from the CPU 501 and confirms the authorization token included in the login request of the terminal 10.

  The pub processing unit 53 is realized by a command from the CPU 501 and accepts a pub request from a client.

  The sub processing unit 54 is realized by a command from the CPU 501 and accepts a sub request from the client.

  The storage / reading unit 59 is executed by an instruction from the CPU 501 and the HDD 505 or realized by an instruction from the CPU 501, and stores various data in the storage unit 5000 or extracts various data stored in the storage unit 5000. Perform the process.

<< Process or action >>
Next, processes or operations of the terminal 10, the authentication server 40, and the management system 50 that configure the communication system 1 will be described. First, an authentication process according to an embodiment will be described with reference to FIG. FIG. 8 is a sequence diagram illustrating an authentication process according to an embodiment.

  When an arbitrary client application installed in the terminal 10 is activated (step S21), the following processing is started by each functional unit corresponding to the activated client application. The client application of the terminal 10 acquires the user ID and user password of the user (Step S22). The acquisition method is not particularly limited, but the operation input receiving unit 12 receives a user ID and password input by the user, or the storage / reading unit 19 stores the user ID and password stored in the storage unit 1000 in advance. The method of reading out is mentioned.

  The authentication request unit 14 of the terminal 10 makes an authentication / authorization request to the authentication server 40 via the transmission / reception unit 11 (step S23). This authentication / authorization request includes a user authentication request, a client authentication request, and a service use authorization request. The authentication request transmitted to the management system 50 includes the user ID and user password acquired in the terminal 10, the client ID and client password of the activated client, and a service ID as a scope indicating the service to be used in the future. . The client ID and the client password may be stored in advance in the storage unit 1000 and read by the storage / reading unit 19.

  The transmission / reception unit 41 of the authentication server 40 receives an authentication request from the terminal 10. The user authentication unit 42 of the authentication server 40 performs user authentication based on whether or not the combination of the user ID and the user password included in the authentication request is managed in the user management table (see FIG. 6A) (step S24). . When the combination of user ID and user password included in the authentication request is managed in the user management table, the user authentication unit 42 succeeds in user authentication, and the combination of user ID and user password included in the authentication request is the user. When not managed by the management table, the user authentication unit 42 fails in user authentication.

  Further, the client authentication unit 43 of the authentication server 40 performs client authentication based on whether or not the combination of the client ID and the client password included in the authentication request is managed in the client management table (see FIG. 6B) (step S1). S25). When the combination of the client ID and client password included in the authentication request is managed by the client management table, the client authentication unit 43 succeeds in client authentication, and the combination of the client ID and client password included in the authentication request is the client. When not managed by the management table, the client authentication unit 43 fails in client authentication.

  Further, the authorization unit 44 of the authentication server 40 determines whether the client ID and the service ID included in the authentication request are managed in the service authorization management table (see FIG. 6D). Access to the service is authorized (step S26). If the combination of client ID and service ID included in the authentication request is managed by the service authorization management table, the authorization unit 44 succeeds in the authorization, and the pair of client ID and service ID included in the authentication request is service authorization. If not managed by the management table, the authorization unit 44 fails to authorize.

  When at least one of user authentication, client authentication, and service authorization fails, the transmission / reception unit 41 transmits an error message indicating that authentication or authorization has failed to the requesting terminal 10.

  When the user authentication, the client authentication, and the service authorization are all successful, the token issuing unit 45 of the authentication server 40 issues an authorization token indicating that the terminal 10 that has requested authentication can access the management system 50 ( Step S27). The authorization token includes a user name, a client name, a service name using the authorization token, a token expiration date, and the like.

  In the communication system 1, authentication and authorization can also be executed using protocols such as OAuth 2.0 and OpenID Connect. In this case, the method of exchanging authentication information such as user ID / user password and the contents included in the authorization token are defined by specifications such as OAuth 2.0 and OpenID Connect. In that case, the token itself may be JWT (JSON Web Token). Further, in order to ensure that the authorization token is not tampered with on the route, the token issuing unit 45 may sign the authorization token using a secret key. The secret key may use RSA (Rivest, Shamir, Adleman) encryption. A public key such as HMAC (Hash-based Message Authentication Code) may be used for the signature. In the management system 50 using the authorization token, the signature is confirmed using the public key or the shared key depending on whether the authorization token is signed with the secret key or the shared key. For the signature, a known standard such as JWS (JSON Web Signature) can be used. The authorization token is encrypted with JWE (JSON Web Encryption), for example, as necessary.

  The transmission / reception unit 41 includes the issued authorization token in the authentication result and transmits it to the terminal 10. The transmission / reception unit 11 of the terminal 10 receives the authentication result including the authorization token transmitted by the authentication server. Subsequently, the transmission / reception unit 11 of the terminal 10 transmits the received authorization token to the management system 50, thereby making a login request to the management system 50 (step S28).

  The transmission / reception unit 51 of the management system 50 receives the login request transmitted by the terminal 10. The token confirmation unit 52 of the management system 50 confirms the authorization token included in the login request (step S29). In this case, the token confirmation unit 52 analyzes the authorization token included in the login request according to the standard used in the communication system 1. The token confirmation unit 52 may determine whether the signature by the authentication server is correct according to the analysis result. If it is determined that the signature by the authentication server is not correct, the token confirmation unit 52 determines that the authorization token included in the login request has been tampered with and fails authorization.

  Subsequently, the token confirmation unit 52 determines whether the validity period of the authorization token has expired by confirming the validity period included in the authorization token. If it is determined that the authorization token has expired, the token confirmation unit 52 fails to authorize due to the expiration of the authorization token.

  Subsequently, the token confirmation unit 52 confirms whether or not the service name corresponding to the own management system is included in the authorization token. If it is determined that the service name corresponding to the self-management system is not included in the authorization token, the token confirmation unit 52 fails in authorization.

  When the token confirmation unit 52 fails authorization in any of the process of signature of the authorization token, expiration date, and service confirmation, the transmission / reception unit 51 transmits authorization result information indicating that authorization has failed to the terminal 10. . When the token confirmation unit 52 determines that the authorization token signature, expiration date, and service are all valid, the token confirmation unit 52 authorizes the use of the service by the user and client indicated in the authorization token. When the user and the client are authorized, the management system 50 establishes a session with the terminal 10 (step S30). In this case, the management system 50 transmits authorization result information indicating that authorization is successful to the terminal 10.

  When the session is established, the management system 50 manages the user ID, client ID, service ID, client IP address, and the like included in the authorization token in the storage unit 1000 in association with each other. As a result, the terminal 10 transmits the authentication / authorization request in the management system 50 without transmitting the user ID, client ID, and service ID to the management system 50 each time the client on the other side transmits information. The user ID, client ID, and service ID can be grasped.

  The processes in steps S21 to S30 are executed for each client application activated on the terminal 10. For example, each client application such as the camera application and the OS2 video conference application may request authentication from the authentication server 40. When the management system 50 succeeds in authenticating each client application, separate sessions are simultaneously established between the management system 50 and each client application.

  Next, a process for pubping and substituting messages between terminals 10 will be described with reference to FIG. FIG. 9 is a sequence diagram illustrating an example of processing for pub and sub of a message. Hereinafter, as an example of the plurality of terminals 10, a process of pubping and substituting messages between the terminal 10a and the terminal 10b will be described.

  First, the terminal 10a authenticated by the user ID “U01” of the user “User1” and the client ID “C02” of the client “dedicated terminal video conference application” and authorized to access the service “video conference service” Processing for making a sub request for “video” will be described. The sub request unit 16 of the terminal 10a transmits a sub request to the management system 50 in order to receive video in the video conference service (step S41). The sub request includes the topic name “video” related to the video.

  The transmission / reception unit 51 of the management system 50 receives the sub request transmitted by the terminal 10a. The sub processing unit 54 of the management system 50 determines whether or not the dedicated terminal video conference application of the terminal 10a has the authority to use the video conference service to sub-subscribe the message related to the sub request (step S42). The process of step S42 will be described in detail with reference to FIG. FIG. 10 is a flowchart illustrating an example of a process for determining whether or not the user has authority to subsubscribe a message.

  The storage / reading unit 59 obtains the topic ID corresponding to the topic name included in the sub request from the topic management table (step S42-1). For example, if the topic name included in the sub request is “video”, the topic ID “T04” is acquired from the topic management table.

  The sub processing unit 54 refers to the client service management table and determines whether there is a service ID associated with the client ID of the sub request source client (step S42-2). The client ID of the sub request source is included in an authorization token that is transmitted to the management system 50 when the terminal 10a first logs into the management system 50. For example, when the client ID of the sub request source client “dedicated terminal video conference application” is “C02”, it is determined that there is a service ID associated with this client ID in the client service management table. If NO is determined in step S42-2, the process proceeds to step S42-14, and sub authority is determined in accordance with the relationship between the user, the client, and the topic of the sub request source. As described above, by performing the determination in step S42-2, it is possible to realize the sub process using the service and the sub process without using the service on a common platform.

  If YES is determined in step S42-2, the sub processing unit 54 starts determining sub authority according to the relationship between the user who requested the sub, the client, the service to be used, and the topic. First, the sub processing unit 54 searches the user service management table using the set of the user ID of the sub request source user and the service ID of the service authorized for the sub request source as a search key (step S42-3). ). The user ID of the user of the sub request source and the service ID of the service authorized for the sub request source are included in the authorization token transmitted to the management system 50 when the sub request source first logs into the management system 50. include. Note that if the user ID of the user who requested the sub is “U01” and the service ID of the authorized service is “S02”, the authority information “sub” corresponding to these groups is obtained from the user service management table. To be acquired.

  The sub processing unit 54 determines whether the authority information “sub” or “pubsub” is acquired in step S42-3 (step S42-4). When the authority information “sub” or “pubsub” is not acquired (NO in step S42-4), the process proceeds to step S42-7, and the inherited service is confirmed.

  When the authority information “sub” or “pubsub” is acquired (YES in step S42-4), the sub processing unit 54 acquires the service ID of the service authorized for the sub request source, and in step S42-1. The service topic management table is searched using the set of topic IDs as a search key (step S42-5). For example, when the service ID of the service authorized to the sub request source is “S02” and the acquired topic ID is “T04”, the authority information “pubsub” corresponding to these sets is acquired.

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-5 (step S42-6). When the authority information “sub” or “pubsub” is acquired (YES in step S42-6), the process proceeds to step S42-14, and the sub authority is determined according to the relationship between the user, the client, and the topic of the sub request source. Do.

  When the authority information “sub” or “pubsub” is not acquired (NO in steps S42-4 and S42-6), the sub processing unit 54 searches the service ID of the service authorized for the sub request source with the search key. In the service inheritance management table, the inherited service field is searched (step S42-7).

  The sub processing unit 54 determines whether or not the service ID of the corresponding inherited service is acquired in step S42-7 (step S42-8). If it is determined NO in step S42-8, the sub processing unit 54 determines that the sub request source has no sub authority since there is no service inherited by the sub request source (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  If “YES” is determined in the step S42-8, the determination of the sub authority according to the relationship between the user who requested the sub, the client, the inherited service, and the topic is started. First, the sub processing unit 54 searches the user service management table using the set of the user ID of the user who made the sub request and the service ID of the inherited service acquired in step S42-7 as a search key (step S42). -9).

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-9 (step S42-10). When the authority information “sub” or “pubsub” is not acquired (NO in step S42-10), the sub processing unit 54 determines that the sub request source has no sub authority (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  When the authority information “sub” or “pubsub” is acquired (YES in step S42-10), the sub processing unit 54 determines the service ID of the inherited service acquired in step S42-7 and step S42-1. The service topic management table is searched using the set of topic IDs acquired in step 1 as a search key (step S42-11).

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-11 (step S42-12). When the authority information “sub” or “pubsub” is acquired (YES in step S42-12), the process proceeds to step S42-14 to determine the sub authority according to the relationship between the sub requesting user, client, and topic. Do.

  When the authority information “sub” or “pubsub” is not acquired (NO in step S42-12), the sub processing unit 54 determines that the sub request source does not have the sub authority (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  If NO is determined in step S42-2 or YES is determined in steps S42-6 and S42-12, the sub processing unit 54 determines the user ID of the sub request source user and the client ID of the sub request source. The user client management table is searched using the set of client IDs as a search key (step S42-14). For example, when the user ID “U01” of the sub request source user and the client ID “C02” of the sub request source client are obtained, the authority information “sub” corresponding to these sets is acquired from the user client management table.

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-14 (step S42-15). When the authority information “sub” or “pubsub” is not acquired (NO in step S42-15), the sub processing unit 54 determines that the sub request source has no sub authority (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  When the authority information “sub” or “pubsub” is acquired (YES in step S42-15), the sub processing unit 54 determines the client ID of the client that made the sub request, and the topic ID of the topic acquired in step S42-1. The client topic management table is searched using the set as a search key (step S42-16). For example, when the client ID “C02” of the client of the sub request source and the topic ID of the acquired topic are “T04”, the authority information “sub” corresponding to these sets is acquired from the client topic management table.

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-16 (step S42-17). When the authority information “sub” or “pubsub” is not acquired (NO in step S42-17), the sub processing unit 54 determines that the sub request source has no sub authority (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  When the authority information “sub” or “pubsub” is acquired (YES in step S42-17), the sub processing unit 54 determines the user ID of the user who made the sub request, and the topic ID of the topic acquired in step S42-1. The user topic management table is searched using the set as a search key (step S42-18). For example, when the user ID “U01” of the user who made the sub request and the topic ID of the acquired topic are “T04”, the authority information “sub” corresponding to these sets is acquired from the user topic management table.

  The sub processing unit 54 determines whether or not the authority information “sub” or “pubsub” is acquired in step S42-18 (step S42-19). When the authority information “sub” or “pubsub” is not acquired (NO in step S42-19), the sub processing unit 54 determines that the sub request source has no sub authority (step S42-13). In this case, the transmission / reception unit 51 transmits information indicating that the sub request is rejected to the terminal 10a that is the sub request source, and ends the process.

  When the authority information “sub” or “pubsub” is acquired (YES in step S42-19), the sub processing unit 54 determines that the sub request source has the sub authority (step S42-20).

  When it is determined in step S42-20 that the sub request source has sub authority, the sub processing unit 54 determines the user ID and client ID of the sub request source, the service ID of the service authorized for the sub request source, The topic ID of the topic related to the sub request is registered in association with the session management table (step S43).

  Subsequently, the terminal 10b authenticated by the user ID “U02” of the user “User2” and the client ID “C05” of the client “OS2 cooperation application” and authorized to access the service “video conference cooperation service” Processing for making a pub request for “video” will be described. The pub request unit 15 of the terminal 10b transmits a pub request to the management system 50 in order to distribute video in the video conference service (step S44). The pub request includes the topic name “video” related to the video and video data of the video captured by the terminal as a message.

  The transmission / reception unit 51 of the management system 50 receives the pub request transmitted by the terminal 10b. The pub processing unit 53 of the management system 50 determines whether or not the OS2 cooperative app of the terminal 10b has the authority to publish a message related to the pub request using the video conference cooperation service (step S45). The process of step S45 will be described in detail with reference to FIG. FIG. 11 is a flowchart showing an example of processing for determining whether or not the user has authority to publish a message.

  The storage / reading unit 59 acquires the topic ID corresponding to the topic name included in the pub request from the topic management table (step S45-1). For example, if the topic name included in the pub request is “video”, the topic ID “T04” is acquired from the topic management table.

  The pub processing unit 53 refers to the client service management table and determines whether there is a service ID associated with the client ID of the pub request source client (step S45-2). The client ID of the pub request source is included in the authorization token transmitted to the management system 50 when the terminal 10b first logs into the management system 50. For example, if the client ID of the client “publishing application for OS2” of the pub request source is “C05”, it is determined that there is a service ID associated with this client ID in the client service management table. If NO is determined in step S45-2, the process proceeds to step S45-14 to determine pub authority according to the relationship between the pub requesting user, client, and topic. As described above, by performing the determination in step S45-2, the process of publishing using the service and the process of publishing without using the service can be realized on a common platform.

  If YES is determined in step S45-2, the pub processing unit 53 starts determining pub authority according to the relationship between the pub requesting user, the client, the service to be used, and the topic. First, the pub processing unit 53 searches the user service management table using the set of the user ID of the pub request source user and the service ID of the service authorized for the pub request source as a search key (step S45-3). ). The user ID of the user of the pub request source and the service ID of the service authorized for the pub request source are included in the authorization token transmitted to the management system 50 when the pub request source first logs into the management system 50. include. For example, when the user ID of the pub request source user is “U02” and the service ID of the authorized service is “S03”, the authority information “pubsub” corresponding to these groups is obtained from the user service management table. To be acquired.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-3 (step S45-4). When the authority information “pub” or “pubsub” is not acquired (NO in step S45-4), the process proceeds to step S45-7, and the inherited service is confirmed.

  When the authority information “pub” or “pubsub” is acquired (YES in step S45-4), the pub processing unit 53 acquires the service ID of the service authorized for the pub request source, and in step S45-1. The service topic management table is searched using the set of topic IDs as a search key (step S45-5). When the service ID of the service authorized for the pub request source is “S03” and the acquired topic ID is “T04”, the authority information is not acquired because there is no authority information corresponding to these sets. .

  The pub processing unit 53 determines whether or not the corresponding authority information “pub” or “pubsub” is acquired in step S45-5 (step S45-6). When the authority information “pub” or “pubsub” is acquired (YES in step S45-6), the process proceeds to step S45-14, and the pub authority is determined according to the relationship between the pub requesting user, the client, and the topic. Do.

  When the authority information “pub” or “pubsub” has not been acquired (NO in steps S45-4 and S45-6), the pub processing unit 53 searches the service ID of the service authorized for the pub request source with the search key. The service inheritance field in the service inheritance management table is searched (step S45-7). For example, the service ID “S02” of the inherited service corresponding to the service ID “S03” of the service authorized to the pub request source is acquired.

  The pub processing unit 53 determines whether the service ID of the corresponding inherited service has been acquired in step S45-7 (step S45-8). If NO is determined in step S45-8, the pub processing unit 53 determines that the pub request source does not have the pub authority because there is no service inherited by the pub request source (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  If “YES” is determined in the step S45-8, the determination of the pub authority is started according to the relationship between the pub request source user, the client, the inherited service, and the topic. First, the pub processing unit 53 searches the user service management table using the set of the user ID of the pub requesting user and the service ID of the inherited service acquired in step S45-7 as a search key (step S45). -9). When the user ID of the pub request source is “U02” and the service ID of the inherited service is “S02”, the authority information “pub” corresponding to these sets is acquired from the user service management table.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-9 (step S45-10). When the authority information “pub” or “pubsub” is not acquired (NO in step S45-10), the pub processing unit 53 determines that the pub request source does not have the pub authority (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  When the authority information “pub” or “pubsub” is acquired (YES in step S45-10), the pub processing unit 53 determines the service ID of the inherited service acquired in step S45-7 and step S45-1. The service topic management table is searched by using the set of topic IDs acquired in (5) as a search key (step S45-11). When the service ID of the inherited service is “S02” and the acquired topic ID is “T04”, the authority information “pubsub” corresponding to these groups is acquired from the service topic management table.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-11 (step S45-12). When the authority information “pub” or “pubsub” has been acquired (YES in step S45-12), the process proceeds to step S45-14 to determine the pub authority in accordance with the relationship between the pub requesting user, the client, and the topic. Do.

  When the authority information “pub” or “pubsub” is not acquired (NO in step S45-12), the pub processing unit 53 determines that the pub request source does not have the pub authority (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  If NO is determined in step S45-2, or if YES is determined in steps S45-6 and S45-12, the pub processing unit 53 determines the user ID of the pub request source user and the pub request source client. The user client management table is searched using the set of client IDs as a search key (step S45-14). For example, if the user ID “U02” of the pub request source user and the client ID “C05” of the pub request source client are obtained, the authority information “pub” corresponding to these sets is acquired from the user client management table.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-14 (step S45-15). When the authority information “pub” or “pubsub” is not acquired (NO in step S45-15), the pub processing unit 53 determines that the pub request source does not have the pub authority (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  When the authority information “pub” or “pubsub” is acquired (YES in step S45-15), the pub processing unit 53 determines the client ID of the client that issued the pub request and the topic ID of the topic acquired in step S45-1. The client topic management table is searched using the set as a search key (step S45-16). For example, when the client ID “C05” of the client of the pub request source and the topic ID of the acquired topic are “T04”, the authority information “pubsub” corresponding to these groups is acquired from the client topic management table.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-16 (step S45-17). When the authority information “pub” or “pubsub” is not acquired (NO in step S45-17), the pub processing unit 53 determines that the pub request source does not have the pub authority (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  When the authority information “pub” or “pubsub” is acquired (YES in step S45-17), the pub processing unit 53 determines the user ID of the pub request source user and the topic ID of the topic acquired in step S45-1. The user topic management table is searched using the set as a search key (step S45-18). For example, when the user ID “U02” of the pub request source user and the topic ID of the acquired topic are “T04”, the authority information “pubsub” corresponding to these sets is acquired from the user topic management table.

  The pub processing unit 53 determines whether or not the authority information “pub” or “pubsub” is acquired in step S45-18 (step S45-19). When the authority information “pub” or “pubsub” is not acquired (NO in step S45-19), the pub processing unit 53 determines that the pub request source does not have the pub authority (step S45-13). In this case, the transmission / reception unit 51 transmits information indicating that the pub request is rejected to the terminal 10b that is the pub request source, and ends the process.

  When the authority information “pub” or “pubsub” is acquired (YES in step S45-19), the pub processing unit 53 determines that the pub request source has the pub authority (step S45-20).

  If it is determined in step S45-20 that the pub request source has the pub authority, the pub processing unit 53 searches the session management table using the topic ID of the topic related to the pub request as a search key, and the corresponding user ID and A client ID and a service ID are acquired (step S46). For example, when the topic ID of the topic related to the pub request is “T04”, the user ID “U01”, the client ID “C02”, and the service ID “S02” are acquired from the session management table. As a result, the pub processing unit 53 identifies the terminal 10a authenticated by the user ID “U01” and the client ID “C02” and authorized to use the service with the service ID “S02” as the message delivery destination.

  The transmission / reception unit 51 transmits a message related to the pub request, that is, video data to the identified terminal 10a. Thereby, the terminal 10a can receive the video data transmitted by the terminal 10b as a message.

  The management system 50 may manage the message related to the pub request in the storage unit 5000. Thus, when a client not connected to the management system 50 at the time of pub request connects to the management system 50 later, the management system 50 can also transmit a message managed in the storage unit 5000 to the client.

<< Main effects of this embodiment >>
Next, main effects of the above embodiment will be described. According to the communication control method of the above-described embodiment, the transmission / reception unit 51 (an example of the accepting unit) of the management system 50 is the terminal 10b (the first communication terminal of the first communication terminal) authenticated by the OS2 cooperative application (an example of the first client). While receiving a pub request (an example of a distribution request) of a message (an example of information) for a topic “video” (an example of a predetermined attribute) from an example), a video conference application for a dedicated terminal (an example of a second client) A message sub request (an example of a reception request) for the topic “video” is received from the terminal 10a (an example of a second communication terminal) authenticated in (an example of a reception process). Note that the topic is a predetermined attribute for specifying sub information in the PubSub model. Further, the message is information that can be published or sub-published in the PubSub model, and includes text, content data such as image data, video data, and sound data. The pub processing unit 53 and the sub processing unit 54 (an example of a distribution control unit) of the management system 50 are a video conference cooperation service (an example of a first service) used by the OS 2 cooperation application, and a video conference application for a dedicated terminal. The video conferencing service (an example of the second service) used by the terminal 10a controls the distribution of the message of the topic “video” to the terminal 10a based on whether each is associated with the topic “video” (distribution control). Example of processing). As will be described later, the video conference cooperation service is associated with the topic “video” by inheriting the service. According to the communication system 1 of the above embodiment, access to a message can be controlled for each service used by a client.

  The transmitting / receiving unit 51 of the management system 50 receives a message pub request for the topic “video” from the terminal 10b authenticated using the user ID “U02” (an example of the first account), while the user ID “U01”. A message sub-request for the topic “video” is received from the terminal 10a authenticated using (an example of the second account). The account is an authority to use a service or the like, and the communication system 1 uses a user ID as an account. The pub processing unit 53 and the sub processing unit 54 of the management system 50 determine whether the user ID “U02” is associated with the video conference service and the user ID “U01” is associated with the video conference cooperation service. Based on this, the delivery of the message of the topic “video” to the terminal 10a is controlled. According to the communication system 1 of the above embodiment, access to the message can be further controlled for each service used by the user.

  When the video conference cooperation service is associated as a service that inherits the video conference service (an example of the third service), the pub processing unit 53 and the sub processing unit 54 of the management system 50 may have the topic “video” as the video conference. Based on whether the message is associated with the service, the delivery of the message of the topic “video” to the terminal 10a is controlled. According to the communication system 1 of the above-described embodiment, the pub authority or sub authority set when using a predetermined service can be inherited by a specific service.

  The pub processing unit 53 and the sub processing unit 54 of the management system 50 control the delivery of the topic “video” message to the terminal 10a based on whether the user ID “U02” is associated with the video conference service. According to the communication system 1 of the above embodiment, access to the message can be further controlled for each service used by the user.

  When the topic “video” is associated with the video conference service and the video conference linkage service, the pub processing unit 53 and the sub processing unit 54 of the management system 50 distribute the message of the topic “video” to the terminal 10a. If the topic “video” is not associated with the video conference service or the video conference linkage service, control is performed so that the message of the topic “video” is not distributed to the terminal 10a. As a result, the management system 50 can appropriately distribute the message according to the service used by the pub request source and the sub request source.

  The service topic management DB 5007 (an example of attribute management means) of the management system 50 manages the topic ID (an example of attribute information) of the topic and the service ID (an example of service information) of the service in association with each other. In the service topic management DB 5007, the pub processing unit 53 and the sub processing unit 54 of the management system 50 manage the service ID of each service used by the pub request source and the sub request source in association with the topic ID of a predetermined topic. The message delivery of a predetermined topic to the sub request source is controlled based on whether or not the request is made. Thereby, the communication system 1 can control access to the message for each service used by the client.

<< Supplement of Embodiment >>
Each program for the terminal 10, the authentication server 40, and the management system 50 is recorded and distributed on a computer-readable recording medium (such as the recording medium 106) in a file that can be installed or executed. You may do it. Other examples of the recording medium include CD-R (Compact Disc Recordable), DVD (Digital Versatile Disk), and Blu-ray Disc.

  Further, a recording medium such as a CD-ROM in which the programs of the above-described embodiments are stored, and the HD 504 in which these programs are stored can be provided domestically or abroad as a program product.

  In addition, the terminal 10, the authentication server 40, and the management system 50 in the above embodiment may be constructed by a single computer, or by a plurality of computers arbitrarily assigned by dividing each unit (function or means). It may be constructed. The authentication server 40 and the management system 50 may be constructed by a single computer.

DESCRIPTION OF SYMBOLS 1 Communication system 2 Communication network 10 Terminal 11 Transmission / reception part 12 Operation input reception part 13 Display control part 14 Authentication request part 15 Pub request part 16 Sub request part 19 Storage / reading part 40 Authentication server 41 Transmission / reception part 42 User authentication part 43 Client authentication Unit 44 authorization unit 45 token issuing unit 49 storage / reading unit 50 management system 51 transmission / reception unit 52 token checking unit 53 pub processing unit 54 sub processing unit 59 storage / reading unit 1000 storage unit 4000 storage unit 4001 user management DB
4002 Client management DB
4003 Service management DB
4004 Service authorization management DB
5000 storage unit 5001 topic management DB
5002 User Topic Management DB
5003 User service management DB
5004 User client management DB
5005 Client Topic Management DB
5006 Client Service Management DB
5007 Service Topic Management DB
5008 Service inheritance management DB
5014 Session Management DB

Japanese Patent No. 5160134

Claims (10)

While receiving a request for distributing information of a predetermined attribute from the first communication terminal authenticated by the first client, a request for receiving the information of the predetermined attribute is received by a second client authenticated by the second client. Receiving means for receiving from the two communication terminals;
Based on whether the first service used by the first client and the second service used by the second client are associated with the predetermined attribute, respectively, the second communication terminal Distribution control means for controlling distribution of information of the predetermined attribute to
A management system comprising: The accepting unit accepts a request for distributing the information of the predetermined attribute from the first communication terminal authenticated by the first account, while receiving a request for receiving the information of the predetermined attribute. Accepted from the second communication terminal authenticated with the account of
The distribution control means determines whether the first account is associated with the first service and the second account is associated with the second service. 2. The management system according to claim 1, wherein distribution of information of the predetermined attribute to the communication terminal is controlled.   When the first service is associated with a third service, the distribution control unit is configured to determine whether the second communication is based on whether the third service is associated with the predetermined attribute. The management system according to claim 2, wherein delivery of information of the predetermined attribute to the terminal is controlled.   The distribution control means controls distribution of information of the predetermined attribute to the second communication terminal based on whether the first account is associated with the third service. The management system according to claim 3.   The distribution control means distributes the information of the predetermined attribute to the second communication terminal when the first service and the second service are associated with the predetermined attribute, respectively. And when the first service or the second service is not associated with the predetermined attribute, information on the predetermined attribute is not distributed to the second communication terminal. The management system according to claim 1, wherein the management system is controlled. Having attribute management means for managing attribute information indicating attributes and service information indicating services in association with each other;
Whether the distribution control means manages the service information indicating the first service and the service information indicating the second service in association with the attribute information indicating the predetermined attribute in the attribute management means. 6. The management system according to claim 1, wherein distribution of the information of the predetermined attribute to the second communication terminal is controlled based on the management information. A management system according to any one of claims 1 to 5;
The first communication terminal;
The second communication terminal;
A communication system comprising: Management system
While receiving a request for distributing information of a predetermined attribute from the first communication terminal authenticated by the first client, a request for receiving the information of the predetermined attribute is received by a second client authenticated by the second client. Accepting process received from the communication terminal 2;
Based on whether the first service used by the first client and the second service used by the second client are associated with the predetermined attribute, respectively, the second communication terminal A delivery control process for controlling delivery of information of the predetermined attribute to
The communication control method characterized by performing. The first communication terminal is
A process of transmitting a request to distribute information of the predetermined attribute to the management system after being authenticated by the first client;
The second communication terminal is
The communication control method according to claim 8, wherein a process of transmitting a request for receiving the information of the predetermined attribute to the management system after being authenticated by the second client is executed. In the management system,
While receiving a request for distributing information of a predetermined attribute from the first communication terminal authenticated by the first client, a request for receiving the information of the predetermined attribute is received by a second client authenticated by the second client. Accepting process received from the communication terminal 2;
Based on whether the first service used by the first client and the second service used by the second client are associated with the predetermined attribute, respectively, the second communication terminal A delivery control process for controlling delivery of information of the predetermined attribute to
A program characterized by having executed.

Images