WO2017170176A1 - 情報送信システム、情報送信方法、及びプログラム - Google Patents

情報送信システム、情報送信方法、及びプログラム Download PDF

Info

Publication number
WO2017170176A1
WO2017170176A1 PCT/JP2017/011855 JP2017011855W WO2017170176A1 WO 2017170176 A1 WO2017170176 A1 WO 2017170176A1 JP 2017011855 W JP2017011855 W JP 2017011855W WO 2017170176 A1 WO2017170176 A1 WO 2017170176A1
Authority
WO
WIPO (PCT)
Prior art keywords
account
request
topic
user
information
Prior art date
Application number
PCT/JP2017/011855
Other languages
English (en)
French (fr)
Inventor
拓也 曽根田
直樹 梅原
宮本　篤
岳志 堀内
寛 日野原
Original Assignee
株式会社リコー
拓也 曽根田
直樹 梅原
宮本　篤
岳志 堀内
寛 日野原
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社リコー, 拓也 曽根田, 直樹 梅原, 宮本　篤, 岳志 堀内, 寛 日野原 filed Critical 株式会社リコー
Priority to JP2018509211A priority Critical patent/JP6583543B2/ja
Priority to EP17774714.4A priority patent/EP3438836A4/en
Publication of WO2017170176A1 publication Critical patent/WO2017170176A1/ja
Priority to US16/129,962 priority patent/US10778455B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1818—Conference organisation arrangements, e.g. handling schedules, setting up parameters needed by nodes to attend a conference, booking network resources, notifying involved parties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1831—Tracking arrangements for later retrieval, e.g. recording contents, participants activities or behavior, network status
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Definitions

  • the present invention relates to an information transmission system, an information transmission method, and a program.
  • a communication system for making a call or a conference via a communication network such as the Internet or a dedicated line has become widespread along with a request for reducing expenses and time of movement of parties.
  • content data such as image data and sound data is transmitted and received, thereby realizing communication between parties.
  • a publish-subscribe model (Publish-Subscribe model, hereinafter referred to as a PubSub model) is known.
  • 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.
  • 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.
  • the information transmission system of the invention is an information transmission system for transmitting the information between accounts authorized to transmit the information.
  • the information transmission system In response to a request to start a session with a first account, the information transmission system generates a topic corresponding to the session, and the request to start the session with the first account.
  • the information transmission system In response to authorizing publish and subscribe to the topic by the first account, and publish and subscribe to the topic by the second account in response to a request to join a second account to the session.
  • an authorization means for authorizing for authorizing.
  • FIG. 1 is a schematic diagram of a communication system according to an embodiment of the present invention. It is a block diagram which shows the hardware constitutions of the terminal which concerns on one Embodiment. It is a block diagram which shows the hardware constitutions of the management system which concerns on one Embodiment. It is a block diagram which shows the software structure of the terminal which concerns on one Embodiment. It is a block diagram which shows each function of the terminal which concerns on one Embodiment, an authentication server, and a management system. It is a conceptual diagram which shows the user management table managed in an authentication server. It is a conceptual diagram which shows the client management table managed in an authentication server. It is a conceptual diagram which shows the service management table managed in an authentication server.
  • FIG. 1 is a schematic diagram of a communication system according to an embodiment of the present invention.
  • the communication system 1 is constructed by a communication terminal 10, an authentication server 40, and a management system 50.
  • the communication terminal 10 is simply referred to as the terminal 10.
  • a message is published from a client (Publish, hereinafter referred to as “pub” as appropriate) and a message in order to exchange messages between the clients.
  • This is a server that accepts requests for subscriptions (Subscribe, hereinafter referred to as sub as appropriate).
  • the management system 50 implements, for example, MQTT (MQ Telemetry Transport), XMPP (eXtensible Messaging and Presence Protocol) PubSub extension (XEP-0060), etc. Also good.
  • the terminal 10 is, for example, a general-purpose terminal, and an arbitrary client application is installed.
  • the client application is referred to as a client application or an application.
  • the terminal 10 is a dedicated terminal, for example, and has a specific client application that operates as a client. Since 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 that runs on the terminal 10 and a “user” that uses the client, and authorizes the use of the management system 50.
  • the management system 50 implements an authentication and authorization protocol such as OAuth ⁇ ⁇ ⁇ 2.0 and OpenID Connect, for example.
  • FIG. 1 illustrates the case where the management system 50 and the authentication server 40 are each one device 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.
  • FIG. 2 is a block diagram illustrating a hardware configuration of the terminal 10 according to an embodiment.
  • the hardware configuration of each terminal 10 is not limited to the configuration shown in FIG.
  • 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.
  • the terminal 10 of the present embodiment has programs used for driving the CPU 101 such as a CPU (Central Processing Unit) 101 and IPL (Initial Program Loader) that control the operation of the terminal 10 as a whole.
  • CPU Central Processing Unit
  • IPL Intelligent Program Loader
  • ROM Read Only Memory
  • RAM Random Access Memory
  • flash memory for storing various data such as programs, image data, and sound data for various terminals of the terminal 10 104, reading or writing data to / from a recording medium 106 such as an SSD (Solid State Drive) 105, a flash memory or an IC card (Integrated Circuit Card), which controls the reading or writing of various data to the flash memory 104 according to the control of the CPU 101 Media I / F1 for controlling storage) 7, an operation button 108 operated when selecting a destination, a power switch 109 for switching on / off the power of the terminal 10, and a network I / F (for transmitting data using the communication network 2) Interface) 111.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • flash memory for storing various data such as programs, image data, and sound data for various terminals of the terminal 10 104, reading or writing data to / from a recording medium 106 such as an SSD (Solid State Drive) 105, a flash memory or an IC card (Integrated Circuit Card), which
  • 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.
  • a built-in speaker 115 that outputs sound, a sound input / output I / F 116 that processes input / output of audio signals between the microphone 114 and the speaker 115 according to the control of the CPU 101, and image data on the external display 120 according to the control of the CPU 101 As shown in FIG.
  • a bus line 110 such as an address bus or a data bus is provided for electrical connection.
  • 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 (registered trademark) (High-Definition Multimedia Interface) or DVI (Digital Video). Interactive) signal cable may be used.
  • the camera 112 includes a lens and a solid-state imaging device that converts light into electric charges and digitizes an object image (video).
  • a solid-state imaging device that converts light into electric charges and digitizes an object image (video).
  • CMOS Complementary Metal OxideCCDSemiconductor
  • CCD Charge Coupled Device
  • 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 through a USB (Universal Serial Bus) cable or the like inserted into the connection port 1132 of the housing 1100. Can be connected to.
  • USB Universal Serial Bus
  • the external camera is driven in preference to the built-in camera 112 under the control of the CPU 101.
  • 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 EEPROM (ElectricallyrErasable and Programmable ROM) or the like may be used.
  • EEPROM ElectricallyrErasable and Programmable ROM
  • FIG. 3 is a block diagram showing a hardware configuration of the management system 50 according to an 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 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, and the like
  • a CD-ROM drive 514 for controlling reading / writing of various data to / from a CD-ROM (Compact Disc Read Only Memory) 513, and for electrically connecting the above components as shown in FIG.
  • a bus line 510 such as an address bus or a data bus is provided. Since the authentication server 40 has the same hardware configuration as the management system 50,
  • FIG. 4 is a block diagram showing a software configuration of the terminal 10 according to an embodiment.
  • 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 and the client applications (1031, 1032) are installed in each terminal 10 constituting the communication system 1 of the present embodiment.
  • the OS 1020 is basic software that provides basic functions to the terminal 10 and manages the terminal 10 as a whole.
  • 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.
  • At least two client applications (1031, 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.
  • FIG. 5 is a block diagram illustrating functions (elements) of the terminal 10, the authentication server 40, and the management system 50 that constitute a part of the communication system 1 according to the embodiment.
  • 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.
  • 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 pubsub request unit 15, 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.
  • each functional configuration of the terminal 10 will be described in detail with reference to FIGS. 2 and 5.
  • 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 an instruction from the CPU 101 and the 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 accepting unit 12 is realized by an instruction from the CPU 101, the operation button 108, and the power switch 109, and accepts various inputs by the user and accepts 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 and requests the authentication server 40 for authentication.
  • the pubsub request unit 15 is realized by a command from the CPU 101, and requests the pub and sub of the message from the management system 50.
  • the pubsub request unit 15 can request the management system 50 to publish a message to another terminal 10.
  • the pubsub request unit 15 can request the management system 50 to receive a message published by another terminal 10.
  • the pubsub request unit 15 can transmit / receive a message (information) to / from the pubsub request unit 15 of another terminal 10 via the management system 50.
  • 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.
  • 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.
  • the authentication server 40 has a storage unit 4000 constructed by the HD 504.
  • FIG. 6A is a conceptual diagram showing a user management table.
  • a user management DB 4001 is constructed by a user management table.
  • a user name and a password are associated and managed for each user ID (identifier, identification).
  • FIG. 6B is a conceptual diagram showing a client management table.
  • a client management DB 4002 is constructed by a client management table.
  • a client name and a password are associated and managed for each client ID.
  • the video conference application is a client application for exchanging (transmitting / receiving) content data such as image data and sound data among a plurality of users.
  • FIG. 6C is a conceptual diagram illustrating a service management table.
  • a service management DB 4003 is constructed by a service management table.
  • a service name is associated with each service ID and managed.
  • the service “transmission management system” identified by the service ID “S01” is the management system 50.
  • the right to use the PubSub function of the management system 50 is a resource.
  • the PubSub service using the management system 50 is a scope that is a unit of authorization in the OAuth 2.0 protocol.
  • the management system 50 corresponds to a resource server.
  • FIG. 6D is a conceptual diagram showing a service authorization management table.
  • a service authorization management DB 4004 is constructed by a service authorization management table.
  • a service ID is associated with each client ID and managed.
  • the service authorization management table can manage which client can access and use which service.
  • the video conference application identified by the client ID “C01” accesses and uses the transmission management system identified by the service ID “S01”, that is, the management system 50. Show that you can.
  • 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 a command 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 a command 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.
  • the management system 50 includes a transmission / reception unit 51, a token confirmation unit 52, a pubsub processing unit 53, 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.
  • the management system 50 includes a storage unit 5000 constructed by the HD 504.
  • Table 1A is a conceptual diagram showing a user authorization management table.
  • a user authorization management DB 5003 is constructed by a user authorization management table.
  • a user name and authority information indicating whether the user has authority to pub or sub with respect to the topic are associated and managed.
  • the user a with the user name “a” has the right to sub to the topic with the topic name “Roster / userA” and the topic with the topic name “Roster / userM”. Shows permission to publish.
  • user a has the authority to receive messages issued to the topic with the topic name “Roster / userA”, and user a Has the authority to publish messages to the topic with the name "Roster / userM”.
  • the topic name starting with “Roster” indicates a message destined for the user described after “Roster”. That is, “Roster / userA” indicates a message addressed to user a.
  • Table 2A is a conceptual diagram showing a session management table.
  • a session management DB 5004 is constructed by a session management table.
  • the user name currently substituting the topic in the session established between the terminals 10 and the topic name of the topic are managed in association with each other.
  • 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 a command from the CPU 501 and confirms the authorization token included in the login request of the terminal 10.
  • the pubsub processing unit 53 is realized by an instruction from the CPU 501, and executes processing related to pub (pub request) or sub (sub request) by 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.
  • FIG. 7 is a sequence diagram illustrating an authentication process according to an embodiment.
  • the client application of the terminal 10 acquires the user ID and user password of the user (Step S22).
  • the operation input receiving unit 12 receives a user ID and password input by the user, or the storage / reading unit 19 uses the user ID and password stored in the storage unit 1000 in advance. A user ID and a user password are acquired by the reading method.
  • the authentication request unit 14 of the terminal 10 transmits 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 authentication server 40 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 service ID included in the authentication request is “S01” indicating the management system 50 will be described.
  • the transmission / reception unit 41 of the authentication server 40 receives the 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). .
  • 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.
  • the user authentication unit 42 fails in user authentication.
  • 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).
  • 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.
  • the client authentication unit 43 fails in client authentication.
  • 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.
  • the transmission / reception unit 41 transmits an error message indicating that the authentication or authorization has failed to the requesting terminal 10.
  • 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.
  • authentication and authorization can be executed using protocols such as OAuth 2.0 and OpenID Connect.
  • the method of exchanging authentication information such as the user ID / user password and the contents included in the authorization token are defined by specifications such as OAuth 2.0 and OpenID Connect.
  • the token itself may be JWT (JSON Web Token).
  • 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.
  • 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.
  • a known standard such as JWS (JSON (Web ⁇ ⁇ ⁇ Signature) can be used.
  • JWS JSON (Web ⁇ ⁇ ⁇ Signature)
  • JWE JSON Web Encryption
  • the transmission / reception unit 41 transmits the issued authorization token to the terminal 10 including the authentication result.
  • 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).
  • 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.
  • the token confirmation unit 52 determines whether the authorization token has expired by confirming the expiration date 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.
  • the token confirmation unit 52 confirms whether or not the service name corresponding to the self-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.
  • the transmission / reception unit 51 transmits authorization result information indicating that authorization has failed to the terminal 10.
  • 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.
  • 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.
  • the management system 50 manages the client user name, the client name, the client IP address, and the like included in the authorization token in the storage unit 1000 in association with each other.
  • the management system 50 can grasp the user name and the client name of the transmission source client without transmitting the user name and the client name to the management system 50 every time the other client transmits information. become able to.
  • the terminal (first communication terminal) 10a logs in to the management system 50 with the user name “a”
  • the terminal (second communication terminal) 10b logs in to the management system 50 with the user name “b”. Processing will be described.
  • FIG. 8 is a sequence diagram illustrating a process for updating the addressable candidate candidates.
  • the terminal 10a requests the update of the destination candidate.
  • other terminals 10 can similarly request the update of the destination candidate.
  • the operation input accepting unit 12 of the terminal 10a accepts an input of a destination candidate update request from the user a (step S31).
  • the transmission / reception unit 11 of the terminal 10a transmits the update request to the management system 50 (step S32).
  • the update request includes update information indicating addition or deletion of a destination candidate and a user name to be added or deleted.
  • the number of destination candidates to be added and deleted may be one or more.
  • the transmission / reception unit 51 of the management system 50 receives the update request transmitted by the terminal 10a.
  • the transmission / reception unit 51 that has received the update request determines whether the update information included in the update request indicates addition of a destination candidate (step S33). If it is determined that the update information does not indicate addition (NO in step S33), the process proceeds to step S36 described later.
  • the transmission / reception unit 51 of the management system 50 transfers to the terminal 10 that has logged into the management system 50 using the user name included in the update request.
  • An update request is transmitted (step S34).
  • the transmission / reception unit 51 of the management system 50 transmits the update request to the terminal 10b logged into the management system 50 with the user name “b”.
  • the transmission / reception unit 11 of the terminal 10b receives the update request transmitted by the management system 50.
  • the operation input accepting unit 12 of the terminal 10b accepts an update request approval input from the user b.
  • the transmission / reception unit 11 of the terminal 10b transmits approval information indicating the approval of the update request to the management system 50 (step S35).
  • the storage / reading unit 59 of the management system 50 updates the user authorization management table based on the update request (step S36). For example, when the update information included in the update request is additional and the user name to be updated is “b”, the storage / reading unit 59 associates with the topic name “Roster / userB” indicating the message addressed to the user b. Then, the user name “a” and the authority information “pub” of the user a who is the update request source are added to the user authorization management table. Thereby, a message can be transmitted from the user a to the user b.
  • the storage / reading unit 59 adds the user name “b” and the authority information “pub” of the user b to the user authorization management table in association with the topic name “Roster / userA” indicating the message addressed to the user a. . Thereby, a message can be transmitted from the user b to the user a.
  • the updated user authorization management table is shown in Table 1B.
  • the user a when the user a transmits an update request for adding the user b as a destination candidate to the management system 50, the user a can transmit / receive information (message) to / from the user b. . In other words, the user a can send and receive information (message) to and from one or more destination candidates associated with the user a.
  • the storage / reading unit 59 has a topic name “Roster / userA” in which information indicating the user a is described after “Roster” in the user authorization management table.
  • the user name included in the update request is deleted from the user name associated with the searched topic name.
  • the storage / reading unit 59 searches the user authorization management table for the topic name in which information indicating the user of the user name included in the update request is described after “Roster”, and is associated with the searched topic name.
  • the user name “a” of the user a is deleted from the existing user name. In other words, for example, when the user a transmits an update request for making the user b a destination candidate to the management system 50, the user a cannot send and receive information (message) to and from the user b. It becomes.
  • FIG. 9 is a sequence diagram illustrating processing for acquiring a destination list.
  • a process in which the terminal 10a acquires a destination list will be described.
  • other terminals 10 can acquire a destination list in the same manner.
  • the transmission / reception unit 11 of the terminal 10a After logging in to the management system 50, the transmission / reception unit 11 of the terminal 10a transmits a destination list acquisition request to the management system 50 (step S37).
  • the destination list acquisition request includes the topic name “Roster / userA” indicating the message addressed to the user a.
  • the transmission / reception unit 51 of the management system 50 receives the destination list acquisition request transmitted by the terminal 10a.
  • the storage / reading unit 59 of the management system 50 uses the combination of the topic name “Roster / userA” and the authority information “pub” included in the destination list acquisition request as a search key, and uses the user authorization management table in Table 1B. Search for. Thereby, the storage / reading unit 59 reads “b, m” as the user name of the user who can send a message to the user a (step S38).
  • the storage / reading unit 59 may search the user authorization management table using the user name “a” of the user a as a search key and read the corresponding topic name. As a result, it is possible to acquire information on destination candidates that can be transmitted by the user a.
  • the transmission / reception unit 51 of the management system 50 transmits the user name “b, m” read in step S38 as a destination list to the terminal 10a that requested the destination list (step S39). Thereby, the transmission / reception unit 11 of the terminal 10a acquires the destination list.
  • FIG. 10 is a sequence diagram illustrating an example of processing for starting a video conference.
  • a video conference can be started also by the same process between other terminals 10.
  • the relay management server 30 is connected to the communication network 2 so as to be communicable with the terminal 10 and the management system 50, and manages the relay of content data between the terminals 10.
  • the relay management server 30 is, for example, a video server, an MCU (Multi-point Control Unit), or a SIP server. Since the hardware configuration of the relay management server 30 is the same as that of the management system 50, the description thereof is omitted. Further, the relay management server 30 logs in to the management system 50 with the user name “z” by the relay management application.
  • the pubsub request unit 15 of the terminal 10a transmits a sub request including the topic name “Roster / userA” indicating the message addressed to the user a to the management system 50 in order to receive the message addressed to the user a (Step S41-1). ).
  • the pubsub request unit 15 of the terminal 10b transmits a sub request including the topic name “Roster / userB” indicating the message addressed to the user b to the management system 50 in order to receive the message addressed to the user b (step S41). -2).
  • the transmission / reception unit 51 of the management system 50 receives the sub requests transmitted by the terminals 10a and 10b, respectively.
  • the pubsub processing unit 53 of the management system 50 determines whether the user of each terminal 10a, 10b has sub authority related to the sub request (step S42). In this case, for each sub request, the pubsub processing unit 53 determines that the set of the topic name related to the sub request, the user name of the sub request source, and the authority information “sub” indicating that it has the sub authority is the user authorization in Table 1B Judge whether it is managed in the management table.
  • the pubsub processing unit 53 has the sub authority related to the sub request, and if not managed, the pubsub processing unit 53 determines that the sub authority related to the sub request is not included.
  • the pubsub processing unit 53 determines that the sub authority related to the sub request is not included.
  • the pubsub processing unit 53 registers the user name “a or b” of each sub request source and the topic “Roster / userA or Roster / userB” related to the sub request in association with the session management table (step S43).
  • the session management table after registration is shown in Table 2B.
  • the transmission / reception unit 11 of the terminal 10a transmits a conference topic issuance request for requesting issuance of a topic related to the video conference in which the user a participates to the management system 50 (step S51).
  • the transmission / reception unit 51 of the management system 50 receives the conference topic issue request transmitted by the terminal 10a.
  • the pubsub processing unit 53 issues a topic related to the video conference in which the user a participates (step S52).
  • the pubsub processing unit 53 generates “ConfRoom1” as a topic name for identifying a video conference concerning a request.
  • the transmission / reception unit 51 of the management system 50 transmits the topic name “ConfRoom1” of the issued topic to the terminal 10a that issued the request and the relay management server 30 (steps S53-1, S53-2).
  • the pubsub processing unit 53 of the management system 50 authorizes pub and sub for the published topic to the user a who is the topic publication request source and the user z of the relay management server. (Step S54).
  • the pubsub processing unit 53 authorizes the users a and z to publish messages to the topic with the topic name “ConfRoom1”, and the pubsub processing unit 53 The user z is authorized to receive a message issued to the topic having the topic name “ConfRoom1”.
  • the pubsub processing unit 53 associates the topic name “ConfRoom1” of the issued topic, the user name “a, z” of the authorized user, and authority information “pub, sub” indicating authority to pub and sub.
  • Table 1C shows an example of the user authorization management table after registration.
  • the transmission / reception unit 11 of the terminal 10a receives the topic name “ConfRoom1” transmitted by the management system 50 in step S53-1.
  • the pubsub request unit 15 of the terminal 10a transmits a sub request including the received topic name “ConfRoom1” and indicating a request for substituting the topic with the topic name to the management system 50 (step S55-1).
  • the relay management server 30 receives the topic name “ConfRoom1” transmitted by the management system 50 in step S53-2.
  • the relay management server 30 transmits to the management system 50 a sub request indicating a request for substituting the topic with the topic name “ConfRoom1” (step S55-2).
  • the transmission / reception unit 51 of the management system 50 receives the sub requests transmitted by the terminal 10a and the relay management server 30, respectively.
  • the pubsub processing unit 53 of the management system 50 determines whether the sub request source user has authority to sub the topic related to the sub request (step S56). In this case, for each sub request, the pubsub processing unit 53 includes the topic name “ConfRoom1” related to the sub request, the user name “a or z” of the sub request source, and authority information “sub” indicating that the sub request has the sub authority. It is determined whether the set is managed in the user authorization management table of Table 1C. In the present embodiment, since the above set is managed in the user authorization management table of Table 1C, the pubsub processing unit 53 determines that each sub request source has sub authority.
  • the pubsub processing unit 53 registers the user name “a or z” of each sub request source and the topic “ConfRoom1” related to the sub request in association with the session management table ( Step S57).
  • the session management table after registration is shown in Table 2C.
  • the terminal 10a and the relay management server 30 exchange a call control message by publishing a call control message for the session sed between the terminal 10a and the relay management server 30 for the topic having the topic name “ConfRoom1”. (Step S58). An example process will be described below.
  • the pubsub request unit 15 of the terminal 10a transmits to the management system 50 a pub request including a topic name “ConfRoom1” and a request to relay the content data on the terminal 10a side as a call control message.
  • the transmission / reception unit 51 of the management system 50 receives the pub request transmitted by the terminal 10a.
  • the pubsub processing unit 53 of the management system 50 refers to the user authorization management table of Table 1C, and associates it with the set of the user name “a” of the pub request source and the topic name “ConfRoom1” included in the pub request. Check whether the authority information “pub” indicating that the user has pub authority is managed. As a result, the pubsub processing unit 53 determines that the pub requester has the pub authority to the topic with the topic name “ConfRoom1” requested. If it is determined that the user has the pub authority, the pubsub processing unit 53 searches the session management table in Table 2C using the topic name “ConfRoom1” included in the pub request as a search key, and the corresponding user name “z”. "Read out. The pubsub processing unit 53 of the management system 50 transmits a call control message to the relay management server 30 logged into the management system 50 with the read user name “z”.
  • the relay management server 30 When the relay management server 30 receives the relay request transmitted by the management system 50, the relay management server 30 starts relaying the image data and sound data sent from the terminal 10a to the predetermined terminal 10. Thereby, the session sed between the terminal 10a and the relay management server 30 is established, and the terminal 10a can start a video conference.
  • FIG. 11 is a sequence diagram illustrating an example of processing for causing the terminal 10 to participate in a session.
  • the pubsub request unit 15 of the terminal 10a transmits a pub request including a topic name “Roster / userB” indicating a message addressed to the user b and a message “Invite” indicating that the user b is invited to the conference to the management system 50. (Step S61).
  • the transmission / reception unit 51 of the management system 50 receives the pub request transmitted by the terminal 10a.
  • the pubsub processing unit 53 of the management system 50 refers to the user authorization management table of Table 1C and associates it with the pair of the user name “a” of the pub request source and the topic name “Roster / userB” included in the pub request. Then, it is confirmed whether the authority information “pub” indicating that the user has the pub authority is managed (step S62). Thereby, the pubsub processing unit 53 determines whether the pub requester has the pub authority to the topic with the topic name “Roster / userB” according to the request.
  • the pubsub processing unit 53 of the management system 50 searches the session management table in Table 2C using the topic name “Roster / userB” included in the pub request as a search key, and the corresponding user. Read the name "b". Thereby, the pubsub processing unit 53 identifies the user b as the destination of the message “Invite” (step S63).
  • the pubsub processing unit 53 of the management system 50 authorizes the user “b” specified as the destination of the message “Invite” for pub and sub for the topic indicating the video conference in which the user “a” as the pub requester is participating ( Step S64).
  • the pubsub processing unit 53 associates the topic name “ConfRoom1” corresponding to the above topic, the user name “b” of the identified user b, and authority information “pub, sub” indicating authority to pub and sub.
  • Table 1D shows an example of the user authorization management table after registration.
  • the pubsub processing unit 53 of the management system 50 transmits the topic name “Roster / userB” and the message “Invite” related to the pub request of the terminal 10a to the terminal 10b of the user b specified in step S64 (step S65). Thereby, the transmission / reception unit 11 of the terminal 10b receives the topic name “Roster / userB” and the message “Invite” transmitted by the management system 50.
  • the transmission / reception unit 51 of the management system 50 transmits the topic name “ConfRoom1” of the topic for which pub and sub are approved by the user b to the terminal 10b of the user b (step S66).
  • the transmission / reception unit 11 of the terminal 10b receives the topic name “ConfRoom1” transmitted by the management system 50.
  • the pubsub request unit 15 of the terminal 10b transmits a sub request indicating a request for substituting the topic with the topic name “ConfRoom1” to the management system 50 (step S67).
  • the transmission / reception unit 51 of the management system 50 receives the sub request transmitted by the terminal 10b.
  • the pubsub processing unit 53 of the management system 50 determines whether the user b has the authority to sub-topic the topic name “ConfRoom1” in the same manner as in step S56 (step S68).
  • the pubsub processing unit 53 registers the sub request source user name “b” and the topic “ConfRoom1” related to the sub request in association with the session management table (step S69). ).
  • the session management table after registration is shown in Table 2D.
  • the terminals 10a and 10b and the relay management server 30 exchange the call control messages by publishing the call control message of the session sed to the topic with the topic name “ConfRoom1” (step S70).
  • An example process will be described below.
  • the pubsub request unit 15 of the terminal 10b transmits to the management system 50 a pub request including a topic name “ConfRoom1” and a request for participation in the session sed as a call control message.
  • the transmission / reception unit 51 of the management system 50 receives the pub request transmitted by the terminal 10b.
  • the pubsub processing unit 53 of the management system 50 refers to the user authorization management table of Table 1D and associates it with the set of the user name “b” of the pub request source and the topic name “ConfRoom1” included in the pub request. Check whether the authority information “pub” indicating that the user has pub authority is managed. Accordingly, the pubsub processing unit 53 determines whether the pub request source has pub authority to the topic having the topic name “ConfRoom1” for which the request is made. If it is determined that the user has pub authority, the pubsub processing unit 53 searches the session management table in Table 2D using the topic name “ConfRoom1” included in the pub request as a search key, and the corresponding user name “a, b, Read z ". The pubsub processing unit 53 of the management system 50 transmits a participation request as a call control message to the terminal 10a and the relay management server 30 logged into the management system 50 with the read user name “a, z”.
  • the terminal 10b participates in the session sed by permitting the participation request. Thereby, a video conference can be started between the terminals 10a and 10b.
  • step S54 the pubsub processing unit 53 of the management system 50 applies pub and comm as destination candidates for communication by the user a in addition to the user a who issued the request and the user z of the relay management server 30 for the topic for video conference. Authorize sub.
  • the management system 50 searches the user authorization management table of Table 1B using the combination of the topic name “Roster / userA” indicating the message addressed to the user “a” and the authority information “pub” as a search key. Thereby, based on the read user name “b, m”, the pubsub processing unit 53 identifies the users a and m as destination candidates.
  • the pubsub processing unit 53 includes a topic name “ConfRoom1” indicating a video conference in which the terminal 10a participates, a user name “a, b, m, z” of the user authorized in step S64, and authority information indicating authority to pub and sub. Associate "pub, sub” and register it in the user authorization management table.
  • Table 1E shows an example of the user authorization management table after registration.
  • the transmission / reception unit 51 of the management system 50 changes the topic name “ConfRoom1” of the topic by the user names “a, b, m, z” of the authorized users a, b, m, z in response to the authorization in step S64.
  • the information is transmitted to each terminal 10 logged in to the management system 50 and the relay management server 30 (step S66).
  • step S64 the pubsub processing unit 53 of the management system 50 authorizes pub and sub to destination candidates that can be designated by the user b, in addition to the user b as the invitation request destination, for the topic for video conference.
  • the management system 50 searches the user authorization management table in Table 1C using the combination of the topic name “Roster / userB” indicating the message addressed to the user b and the authority information “pub” as a search key. Accordingly, based on the read user name “a, n”, the pubsub processing unit 53 identifies the users a and n as destination candidates that can be designated by the user b.
  • the pubsub processing unit 53 associates the topic name “ConfRoom1” indicating the video conference in which the terminal 10a participates, the user name of the user newly authorized in step S64, and the authority information “pub, sub” indicating the authority to pub and sub.
  • Table 1F shows an example of the user authorization management table after registration.
  • the transmission / reception unit 51 of the management system 50 transmits the topic name “ConfRoom1” of the topic to each terminal 10 logged in to the management system 50 with the user name of the newly authorized user in accordance with the authorization in step S64 (step S64). S66).
  • the management system 50 (an example of an information transmission system) is used between users (an example of an account) who are authorized to pub (an example of transmission) of a call control message (an example of information). , Send a message.
  • the pubsub processing unit 53 (an example of an authorization unit) of the management system 50 responds to a conference topic issuance request (an example of a request for starting a session) with a first account by a pub (message message).
  • pub an example of sending a message
  • the second account is granted.
  • Authorize This makes it possible to authorize a new account to send a message during a session for sending a message between accounts.
  • the user authorization management DB 5003 (an example of management means) of the management system 50 manages a user name (an example of destination information) indicating one or a plurality of destination candidates associated with the first account.
  • the pubsub processing unit 53 of the management system 50 authorizes pub (information transmission) based on the above destination candidate of the user name in response to a request for invitation of the second account by the first account. Accordingly, when there are a plurality of second accounts to be invited to the session, the second account can participate in the session without transmitting an invitation message for each account.
  • the user authorization management DB 5003 of the management system 50 manages user names indicating one or more destination candidates associated with the second account.
  • the pubsub processing unit 53 of the management system 50 authorizes pub (information transmission) by the destination candidate indicated by the above user name in response to a request for invitation of the second account by the first account. Thereby, when there are a plurality of second accounts (other accounts) to be invited to the session, the second account can participate in the session without sending an invitation message for each account.
  • the pubsub processing unit 53 (an example of a generation unit) of the management system 50 issues a topic corresponding to a video conference session (an example of generation) in response to a conference topic issue request.
  • the pubsub processing unit 53 of the management system 50 authorizes pub and sub for the topic by the first account in response to the meeting topic issuance request by the first account, and responds to the request for the second account invitation.
  • the pubsub processing unit 53 publishes a message to the generated topic and publishes to the generated topic. You may authorize the receipt of received messages.
  • the pubsub processing unit 53 responds to a request for inviting the second account by the first account, so that the second account publishes a message to the generated topic and creates a generated topic. Authorize to receive published messages. This makes it possible to authorize a new account to transmit information during a session in which information is transmitted between accounts.
  • the user authorization management DB 5003 of the management system 50 manages the user name (an example of identification information) of the second account that is authorized to publish to the topic in association with the topic indicating the first account.
  • the transmission / reception unit 11 (an example of a transmission unit) of the management system 50 transmits the user name of the second account managed in the user authorization management DB 5003 to the first account. Thereby, since the destination candidate can be managed by the user authorization management DB 5003, the management system 50 can separately reduce the load for managing the destination list.
  • the transmission / reception unit 51 (an example of a reception unit) of the management system 50 receives a request to add a second account as a destination candidate from the first account.
  • the storage / reading unit 59 (an example of the adding unit) of the management system 50 causes the user authorization management DB 5003 to associate the second account relating to the request with the topic indicating the first account. Add a username for your account. Thereby, the management system 50 can update the destination candidate of the first account.
  • the transmission / reception unit 51 of the management system 50 receives a request to delete the second account from one or a plurality of destination candidates associated with the first account.
  • the storage / readout unit 59 (an example of the deleting unit) of the management system 50 responds to the request associated with the topic indicating the first account in the user authorization management DB 5003.
  • the user name of the second account is deleted. Thereby, the management system 50 can update the destination candidate of the first account.
  • 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.
  • a computer-readable recording medium such as the recording medium 106
  • the recording medium include CD-R (Compact Disc Recordable), DVD (Digital Versatile Disk), and Blu-ray Disc.
  • 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 (Program Product).
  • 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.
  • processing circuit refers to a processor programmed to execute each function by software, such as a processor including an electronic circuit, or an ASIC designed to execute each function described above. It includes devices such as (Application Specific Integrated Circuit) and conventional circuit modules.
  • the information transmission system may be realized by a device memory storing one or more programs and one or more processors.
  • the one or more processors execute the processes described in the embodiments by executing the one or more programs.
  • the device memory and the one or more processors can realize (implement) the functions described in the embodiments.
  • the device memory and the one or more processors may be realized (implemented) by hardware elements as described in the embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)

Abstract

情報の送信が認可されたアカウントの間で、前記情報を送信させる情報送信システムは、第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する生成手段と、前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可し、第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する認可手段と、を有する。

Description

情報送信システム、情報送信方法、及びプログラム
　本発明は、情報送信システム、情報送信方法、及びプログラムに関する。
　近年、当事者の移動の経費や時間を削減する要請等に伴い、インターネットや専用線等の通信ネットワークを介して通話や会議等を行う通信システムが普及している。このような通信システムでは、通信端末間で通信を開始すると、画像データ及び音データ等のコンテンツデータの送受信が行われ、当事者間のコミュニケーションを実現する。また、通信端末間でコンテンツデータを送信する方法として、出版－購読モデル（Publish-Subscribeモデル、以下、PubSubモデルと記載する）が知られている。
　例えば、特許文献１には、メッセージを発行側クライアントから購読側クライアントに複数のルーティング・ブローカ・マシンを介して配送するコンテンツベースのパブリッシュ・システムまたはサブスクライブ・システムのいずれかにおいてアクセス制御を提供する方法が開示されている。この方法では、ルーティング・ブローカ・マシンは新たなアクセス制御ルールを成立させる開始点を選ぶ。そして、開始点以前のメッセージは、そのメッセージが、アクセス制御バージョン識別子に対応付けられた変更前にサブスクリプション・フィルタとアクセス・フィルタを満たす場合かつその場合に限ってクライアントに配送され、また、開始点以降のメッセージは、そのメッセージがアクセス制御バージョン識別子に対応付けられた変更以降のサブスクリプション・フィルタとアクセス・フィルタの両方を満たす場合にクライアントに配送される。
　特許文献１に記載されているアクセス制御方法によると、予め設定されているフィルタに基づいて、所定の時点以降のメッセージの配送を制御する。しかしながら、この方法によると、アカウント間で情報を送信するセッション中に、セッションに対応するトピックに対する新たなアカウントによるパブリッシュ及びサブスクライブを認可することができないという課題が生じる。
　請求項１に係る発明の情報送信システムは、情報の送信が認可されたアカウントの間で、前記情報を送信させるための情報送信システムである。情報送信システムは、第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する生成手段と、前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可し、第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する認可手段と、を有する。
　以上説明したように本発明によれば、アカウント間で情報を送信するセッション中に、セッションに対応するトピックに対する新たなアカウントによるパブリッシュ及びサブスクライブを認可することが可能になるという効果を奏する。
本発明の一実施形態に係る通信システムの概略図である。 一実施形態に係る端末のハードウェア構成を示すブロック図である。 一実施形態に係る管理システムのハードウェア構成を示すブロック図である。 一実施形態に係る端末のソフトウェア構成を示すブロック図である。 一実施形態に係る端末、認証サーバ、及び管理システムの各機能を示すブロック図である。 認証サーバにおいて管理されるユーザ管理テーブルを示す概念図である。 認証サーバにおいて管理されるクライアント管理テーブルを示す概念図である。 認証サーバにおいて管理されるサービス管理テーブルを示す概念図である。 認証サーバにおいて管理されるサービス認可管理テーブルを示す概念図である。 一実施形態における認証処理を示すシーケンス図である。 指定可能な宛先候補を更新する処理の一例を示すシーケンス図である。 宛先リストを取得する処理の一例を示すシーケンス図である。 テレビ会議を開始する処理の一例を示すシーケンス図である。 端末をセッションに参加させる処理の一例を示すシーケンス図である。
　以下、本発明の実施形態について図面を参照して説明する。
　＜＜通信システムの概略＞＞
　図１は、本発明の一実施形態に係る通信システムの概略図である。図１に示されているように、通信システム１は、通信端末１０、認証サーバ４０、管理システム５０によって構築されている。以下、通信端末１０を単に端末１０と記載する。
　管理システム５０は、出版－購読（Publish-Subscribe、以下PubSubと記載する）モデルにおいて、クライアント間でメッセージを交換するために、クライアントから、メッセージの出版（Publish、以下pubと適宜記載する）やメッセージの購読（Subscribe、以下subと適宜記載する）の要求を受け付けるサーバである。管理システム５０は、PubSubモデル（Pub-Sub pattern）に対応するプロトコルとして、例えば、MQTT（MQ Telemetry Transport）や、XMPP（eXtensible Messaging and Presence Protocol）のPubSub拡張（XEP-0060）等を実装しても良い。
　端末１０は、例えば、汎用端末であって、任意のクライアントアプリケーションがインストールされている。以下、クライアントアプリケーションをクライアントアプリ又はアプリと表す。また、端末１０は、例えば、専用端末であって、クライアントとして稼働する特定のクライアントアプリが組み込まれている。端末１０が通信ネットワーク２を介して管理システム５０に通信可能に接続されているので、各クライアントは、管理システム５０にメッセージのpubやメッセージのsubを要求することができる。端末１０は、例えば、テレビ会議端末、電子黒板、電子看板、電話、タブレット、スマートフォン、カメラ、ＰＣ（personal computer）等であっても良い。
　認証サーバ４０は、端末１０上で動作するクライアントアプリである「クライアント」と、そのクライアントを利用する「ユーザ」とをそれぞれ認証し、管理システム５０の利用を認可するサーバである。管理システム５０は、上記の認証及び認可を実現するため、例えば、OAuth 2.0やOpenID Connectといった認証、認可のプロトコルを実装する。
　図１では、説明を簡単にするために、管理システム５０、及び認証サーバ４０がそれぞれ一つの装置である場合について説明したが、本発明はこのような実施形態に限定されない。管理システム５０、及び認証サーバ４０の少なくとも一方は、複数の装置により構築されていても良い。また、管理システム５０、及び認証サーバ４０が、一つのシステム又は装置によって構築されていても良い。また、図１では、説明を簡単にするために、通信システム１において、４つの端末１０が設けられている場合について説明したが、本発明はこのような実施形態に限定されない。通信システム１に設けられる端末１０は、２つであっても、３つであっても、５つ以上であっても良い。また、各端末１０は、それぞれ同種であっても、図１のように異種であっても良い。
　＜＜ハードウェア構成＞＞
　次に、通信システム１を構成する各装置のハードウェア構成を説明する。
　図２は、一実施形態に係る端末１０のハードウェア構成を示すブロック図である。なお、通信可能であれば、各端末１０のハードウェア構成は図２の構成に限定されない。例えば、端末１０には、図２に記載されていない構成が含まれていても、図２に記載の構成の一部が含まれていなくても良い。また、図２に記載の構成の一部は端末１０に接続可能な外部装置等であっても良い。図２に示されているように、本実施形態の端末１０は、端末１０全体の動作を制御するＣＰＵ(Central Processing Unit)１０１、ＩＰＬ(Initial Program Loader)等のＣＰＵ１０１の駆動に用いられるプログラムを記憶したＲＯＭ(Read Only Memory)１０２、ＣＰＵ１０１のワークエリアとして使用されるＲＡＭ(Random Access Memory)１０３、端末１０の各種端末用のプログラム、画像データ、及び音データ等の各種データを記憶するフラッシュメモリ１０４、ＣＰＵ１０１の制御にしたがってフラッシュメモリ１０４に対する各種データの読み出し又は書き込みを制御するＳＳＤ（Solid State Drive）１０５、フラッシュメモリやＩＣカード（Integrated Circuit Card）等の記録メディア１０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアＩ／Ｆ１０７、宛先を選択する場合などに操作される操作ボタン１０８、端末１０の電源のＯＮ／ＯＦＦを切り換えるための電源スイッチ１０９、通信ネットワーク２を利用してデータ伝送をするためのネットワークＩ／Ｆ(Interface)１１１を備えている。
　また、端末１０は、ＣＰＵ１０１の制御に従って被写体を撮像して画像データを得る内蔵型のカメラ１１２、このカメラ１１２の駆動を制御する撮像素子Ｉ／Ｆ１１３、音声を入力する内蔵型のマイク１１４、音声を出力する内蔵型のスピーカ１１５、ＣＰＵ１０１の制御に従ってマイク１１４及びスピーカ１１５との間で音声信号の入出力を処理する音入出力Ｉ／Ｆ１１６、ＣＰＵ１０１の制御に従って外付けのディスプレイ１２０に画像データを伝送するディスプレイＩ／Ｆ１１７、各種の外部機器を接続するための外部機器接続Ｉ／Ｆ１１８、端末１０の各種機能の異常を知らせるアラームランプ１１９、及び上記各構成要素を図２に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン１１０を備えている。
　ディスプレイ１２０は、被写体の画像や操作用等を表示する液晶や有機ＥＬ(Organic Electroluminescence)によって構成された表示部である。また、ディスプレイ１２０は、ケーブル１２０ｃによってディスプレイＩ／Ｆ１１７に接続される。このケーブル１２０ｃは、アナログＲＧＢ（ＶＧＡ）信号用のケーブルであってもよいし、コンポーネントビデオ用のケーブルであってもよいし、ＨＤＭＩ（登録商標）(High-Definition Multimedia Interface)やＤＶＩ(Digital Video Interactive)信号用のケーブルであってもよい。
　カメラ１１２は、レンズや、光を電荷に変換して被写体の画像（映像）を電子化する固体撮像素子を含み、固体撮像素子として、ＣＭＯＳ(Complementary Metal Oxide Semiconductor)や、ＣＣＤ（Charge Coupled Device）等が用いられる。
　外部機器接続Ｉ／Ｆ１１８には、筐体１１００の接続口１１３２に差し込まれたＵＳＢ(Universal Serial Bus)ケーブル等によって、外付けカメラ、外付けマイク、及び外付けスピーカ等の外部機器がそれぞれ電気的に接続可能である。外付けカメラが接続された場合には、ＣＰＵ１０１の制御に従って、内蔵型のカメラ１１２に優先して、外付けカメラが駆動する。同じく、外付けマイクが接続された場合や、外付けスピーカが接続された場合には、ＣＰＵ１０１の制御に従って、それぞれが内蔵型のマイク１１４や内蔵型のスピーカ１１５に優先して、外付けマイクや外付けスピーカが駆動する。
　なお、記録メディア１０６は、端末１０に対して着脱自在な構成となっている。また、ＣＰＵ１０１の制御にしたがってデータの読み出し又は書き込みを行う不揮発性メモリであれば、フラッシュメモリ１０４に限らず、ＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等を用いてもよい。
　図３は、一実施形態に係る管理システム５０のハードウェア構成を示すブロック図である。管理システム５０は、管理システム５０全体の動作を制御するＣＰＵ５０１、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶したＲＯＭ５０２、ＣＰＵ５０１のワークエリアとして使用されるＲＡＭ５０３、管理システム５０用のプログラム等の各種データを記憶するＨＤ５０４、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御するＨＤＤ(Hard Disk Drive)５０５、フラッシュメモリ等の記録メディア５０６に対するデータの読み出し又は書き込み（記憶）を制御するメディアドライブ５０７、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示するディスプレイ５０８、通信ネットワーク２を利用してデータ通信するためのネットワークＩ／Ｆ５０９、文字、数値、各種指示などの入力のための複数のキーを備えたキーボード５１１、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行うマウス５１２、着脱可能な記録媒体の一例としてのＣＤ－ＲＯＭ(Compact Disc Read Only Memory)５１３に対する各種データの読み出し又は書き込みを制御するＣＤ－ＲＯＭドライブ５１４、及び、上記各構成要素を図３に示されているように電気的に接続するためのアドレスバスやデータバス等のバスライン５１０を備えている。　認証サーバ４０は、管理システム５０と同様のハードウェア構成を有しているため、その説明を省略する。
　＜＜ソフトウェア構成＞＞　図４は、一実施形態に係る端末１０のソフトウェア構成を示すブロック図である。図４に示されているように、ＯＳ１０２０、クライアントアプリ（１０３１，１０３２）は、端末１０のＲＡＭ１０３の作業領域１０１０上で動作する。ＯＳ１０２０、及び、クライアントアプリ（１０３１，１０３２）は、端末１０にインストールされている。なお、ＯＳ１０２０、及び、クライアントアプリ（１０３１，１０３２）は、本実施形態の通信システム１を構成する各端末１０にインストールされている。
　ＯＳ１０２０は、基本的な機能を端末１０に提供し、端末１０全体を管理する基本ソフトウェアである。クライアントアプリ（１０３１，１０３２）は、認証サーバ４０に認証を要求し、管理システム５０にpub要求及びsub要求の少なくとも一つを実行するためのアプリである。
　なお、図４では少なくとも２つのクライアントアプリ（１０３１，１０３２）が端末１０にインストールされているが、１以上の任意の数のクライアントアプリが端末１０にインストールされていれば良い。また、ＯＳ１０２０上で任意のアプリケーションが動作しており、この任意のアプリケーション上でクライアントアプリが動作しても良い。
　＜＜機能構成＞＞
　次に、本実施形態の機能構成について説明する。図５は、一実施形態に係る通信システム１の一部を構成する端末１０、認証サーバ４０、及び管理システム５０の機能（要素）を示すブロック図である。図５では、端末１０、認証サーバ４０、及び管理システム５０が、通信ネットワーク２を介してデータ通信することができるように接続されている。
　＜端末の機能構成＞
　端末１０は、送受信部１１、操作入力受付部１２、表示制御部１３、認証要求部１４、pubsub要求部１５、及び記憶・読出部１９を有している。これら各部は、図２に示されている各構成要素のいずれかが、フラッシュメモリ１０４からＲＡＭ１０３上に展開されたプログラムに従ったＣＰＵ１０１からの命令によって動作することで実現される機能である。また、端末１０は、図２に示されているＲＯＭ１０２、ＲＡＭ１０３、フラッシュメモリ１０４によって構築される記憶部１０００を有している。
　（端末の各機能構成）
　次に、図２及び図５を用いて、端末１０の各機能構成について詳細に説明する。なお、以下では、端末１０の各機能構成を説明するにあたって、図２に示されている各構成要素のうち、端末１０の各機能構成を実現させるための主な構成要素との関係も説明する。
　送受信部１１は、ＣＰＵ１０１からの命令、及びネットワークＩ／Ｆ１１１によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
　操作入力受付部１２は、ＣＰＵ１０１からの命令、並びに操作ボタン１０８及び電源スイッチ１０９によって実現され、ユーザによる各種入力を受け付けたり、ユーザによる各種選択を受け付けたりする。
　表示制御部１３は、ＣＰＵ１０１からの命令、及びディスプレイＩ／Ｆ１１７によって実現され、通話する際に相手側から送られてきた画像データをディスプレイ１２０に送信するための制御を行う。
　認証要求部１４は、ＣＰＵ１０１からの命令によって実現され、認証サーバ４０に対して認証を要求する。
　pubsub要求部１５は、ＣＰＵ１０１からの命令によって実現され、管理システム５０に対してメッセージのpub及びsubを要求する。別の言い方をすれば、pubsub要求部１５は、管理システム５０に他の端末１０へメッセージのパブリッシュを要求することができる。また、pubsub要求部１５は、管理システム５０に、他の端末１０によりパブリッシュされたメッセージを受信するための要求をすることができる。別の言い方をすれば、pubsub要求部１５は、管理システム５０を介して、他の端末１０のpubsub要求部１５とメッセージ（情報）を送受信することができる。
　記憶・読出部１９は、ＣＰＵ１０１からの命令及びＳＳＤ１０５によって実行され、又はＣＰＵ１０１からの命令によって実現され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを抽出したりする処理を行う。
　＜認証サーバの機能構成＞
　認証サーバ４０は、送受信部４１、ユーザ認証部４２、クライアント認証部４３、認可部４４、トークン発行部４５、及び記憶・読出部４９を有する。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された認証サーバ４０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、認証サーバ４０は、ＨＤ５０４により構築される記憶部４０００を有している。
　（ユーザ管理テーブル）
　図６Ａは、ユーザ管理テーブルを示す概念図である。記憶部４０００には、ユーザ管理テーブルによってユーザ管理ＤＢ４００１が構築される。ユーザ管理テーブルでは、ユーザＩＤ（identifier, identification）毎に、ユーザ名、及びパスワードが関連付けられて管理されている。
　（クライアント管理テーブル）
　図６Ｂは、クライアント管理テーブルを示す概念図である。記憶部４０００には、クライアント管理テーブルによってクライアント管理ＤＢ４００２が構築される。クライアント管理テーブルでは、クライアントＩＤ毎に、クライアント名、及びパスワードが関連付けられて管理されている。なお、テレビ会議アプリは、複数のユーザ間で画像データ及び音データ等のコンテンツデータを交換（送受信）するためのクライアントアプリである。
　（サービス管理テーブル）
　図６Ｃは、サービス管理テーブルを示す概念図である。記憶部４０００には、サービス管理テーブルによってサービス管理ＤＢ４００３が構築される。サービス管理テーブルでは、サービスＩＤ毎に、サービス名が関連付けられて管理されている。一実施形態において、サービスＩＤ「Ｓ０１」で識別されるサービス「伝送管理システム」は、管理システム５０である。なお、管理システム５０のPubSubの機能を利用する権利がリソースである。また、管理システム５０を使ったPubSubサービスは、OAuth 2.0のプロトコルにおいて認可の単位となるスコープである。また、管理システム５０はリソースサーバに相当する。
　（サービス認可管理テーブル）
　図６Ｄは、サービス認可管理テーブルを示す概念図である。記憶部４０００には、サービス認可管理テーブルによってサービス認可管理ＤＢ４００４が構築される。サービス認可管理テーブルでは、クライアントＩＤ毎に、サービスＩＤが関連付けられて管理されている。これにより、サービス認可管理テーブルは、どのクライアントがどのサービスにアクセスして利用することができるかを管理することができる。図６Ｄのサービス認可管理テーブルによれば、クライアントＩＤ「Ｃ０１」で識別されるテレビ会議アプリは、サービスＩＤ「Ｓ０１」で識別される伝送管理システム、すなわち、管理システム５０にアクセスして利用することができることを示す。
　（認証サーバの各機能構成）
　送受信部４１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して、相手側の端末、各装置又はシステム等と各種データ（または情報）の送受信を行う。
　ユーザ認証部４２は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてユーザ認証を行う。
　クライアント認証部４３は、ＣＰＵ５０１からの命令によって実現され、クライアントからの要求に応じてクライアント認証を行う。
　認可部４４は、ＣＰＵ５０１からの命令によって実現され、サービスへのクライアントのアクセス権を指定することで認可する。
　トークン発行部４５は、ＣＰＵ５０１からの命令によって実現され、クライアントがサービスへアクセスするときに、サービスで用いられる認可トークンを発行する。
　記憶・読出部４９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部４０００に各種データを記憶したり、記憶部４０００に記憶された各種データを抽出したりする処理を行う。
　＜管理システムの機能構成＞
　管理システム５０は、送受信部５１、トークン確認部５２、pubsub処理部５３、及び記憶・読出部５９を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開された管理システム５０用のプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能である。また、管理システム５０は、ＨＤ５０４により構築される記憶部５０００を有している。
　（ユーザ認可管理テーブル）
　表１Ａは、ユーザ認可管理テーブルを示す概念図である。記憶部５０００には、ユーザ認可管理テーブルによってユーザ認可管理ＤＢ５００３が構築される。ユーザ認可管理テーブルでは、トピックのトピック名毎に、ユーザ名、及びユーザがトピックに対してpub又はsubする権限を有するかを示す権限情報が関連付けられて管理されている。例えば、表１Ａのユーザ認可管理テーブルにより、ユーザ名"a"のユーザａが、トピック名"Roster/userA"のトピックに対しsubする権限を有し、トピック名"Roster/userM"のトピックに対しpubする権限を有することが示される。別の言い方をすれば、表１Ａに示されるように、ユーザａは、トピック名"Roster/userA"のトピックに対して発行されたメッセージを受信する権限を有し、また、ユーザａは、トピック名"Roster/userM"のトピックに対しメッセージをパブリッシュする権限を有する。なお、本実施形態において、"Roster"で始まるトピック名は、"Roster"の後に記述されるユーザを宛先とするメッセージを示す。すなわち、"Roster/userA"は、ユーザａ宛てのメッセージを示す。
Figure JPOXMLDOC01-appb-T000001
 　（セッション管理テーブル）
　表２Ａは、セッション管理テーブルを示す概念図である。記憶部５０００には、セッション管理テーブルによってセッション管理ＤＢ５００４が構築される。セッション管理テーブルでは、端末１０間で確立されるセッションで現在トピックをsubしているユーザ名、及びそのトピックのトピック名が関連付けられて管理されている。
Figure JPOXMLDOC01-appb-T000002
 　（管理システムの各機能構成）
　次に、管理システム５０の各機能構成について詳細に説明する。なお、以下では、管理システム５０の各機能構成を説明するにあたって、図３に示されている各構成要素のうち、管理システム５０の各機能構成を実現させるための主な構成要素との関係も説明する。
　送受信部５１は、ＣＰＵ５０１からの命令、及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワーク２を介して各端末、装置又はシステムと各種データ（または情報）の送受信を行う。
　トークン確認部５２は、ＣＰＵ５０１からの命令によって実現され、端末１０のログイン要求に含まれている認可トークンを確認する。
　pubsub処理部５３は、ＣＰＵ５０１からの命令によって実現され、クライアントによるpub（pub要求）又はsub（sub要求）にかかる処理を実行する。
　記憶・読出部５９は、ＣＰＵ５０１からの命令及びＨＤＤ５０５によって実行され、又はＣＰＵ５０１からの命令によって実現され、記憶部５０００に各種データを記憶したり、記憶部５０００に記憶された各種データを抽出したりする処理を行う。
　＜＜処理または動作＞＞
　続いて、通信システム１を構成する端末１０、認証サーバ４０、及び管理システム５０の処理または動作について説明する。まずは、図７を用いて、一実施形態における認証処理について説明する。図７は、一実施形態における認証処理を示すシーケンス図である。
　端末１０にインストールされている任意のクライアントアプリが起動すると（ステップＳ２１）、起動したクライアントアプリに対応する各機能部により以下の処理が開始される。端末１０のクライアントアプリは、ユーザのユーザＩＤ及びユーザパスワードの取得する（ステップＳ２２）。取得方法は、特に限定されないが、操作入力受付部１２が、ユーザによるユーザＩＤ及びパスワードの入力を受け付ける方法や、記憶・読出部１９が、記憶部１０００に予め記憶されているユーザＩＤ及びパスワードを読み出す方法によって、ユーザＩＤ及びユーザパスワードが取得される。
　端末１０の認証要求部１４は、送受信部１１を介して、認証サーバ４０に認証／認可要求を送信する（ステップＳ２３）。この認証／認可要求には、ユーザの認証要求と、クライアントの認証要求と、サービス利用の認可要求とが含まれる。認証サーバ４０へ送信される認証要求には、端末１０において取得されたユーザＩＤ及びユーザパスワード、起動したクライアントのクライアントＩＤ及びクライアントパスワード、及びこれから利用するサービスを示すスコープとしてサービスＩＤが含まれている。クライアントＩＤ及びクライアントパスワードは、記憶部１０００に予め記憶されており、記憶・読出部１９によって読み出されたものでも良い。以下、認証要求に含まれるサービスＩＤは、管理システム５０を示す「Ｓ０１」である場合について説明する。
　認証サーバ４０の送受信部４１は、端末１０による認証要求を受信する。認証サーバ４０のユーザ認証部４２は、認証要求に含まれるユーザＩＤ及びユーザパスワードの組が、ユーザ管理テーブル（図６Ａ参照）で管理されているか否かに基づいてユーザ認証を行う（ステップＳ２４）。認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されている場合には、ユーザ認証部４２はユーザ認証に成功し、認証要求に含まれるユーザＩＤ及びユーザパスワードの組がユーザ管理テーブルで管理されていない場合には、ユーザ認証部４２はユーザ認証に失敗する。
　また、認証サーバ４０のクライアント認証部４３は、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組が、クライアント管理テーブル（図６Ｂ参照）で管理されているか否かに基づいてクライアント認証を行う（ステップＳ２５）。認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されている場合には、クライアント認証部４３はクライアント認証に成功し、認証要求に含まれるクライアントＩＤ及びクライアントパスワードの組がクライアント管理テーブルで管理されていない場合には、クライアント認証部４３はクライアント認証に失敗する。
　また、認証サーバ４０の認可部４４は、認証要求に含まれるクライアントＩＤ及びサービスＩＤの組が、サービス認可管理テーブル（図６Ｄ参照）で管理されているか否かに基づいて、要求元のクライアントのサービスへのアクセスを認可する（ステップＳ２６）。認証要求に含まれるクライアントＩＤ及びサービスＩＤの組がサービス認可管理テーブルで管理されている場合には、認可部４４は認可に成功し、認証要求に含まれるクライアントＩＤ及びサービスＩＤの組がサービス認可管理テーブルで管理されていない場合には、認可部４４は認可に失敗する。
　ユーザ認証、クライアント認証、及びサービス認可の少なくとも一つに失敗した場合、送受信部４１は、認証又は認可に失敗した旨を示すエラーメッセージを要求元の端末１０へ送信する。
　ユーザ認証、クライアント認証、及びサービス認可のすべてに成功した場合、認証サーバ４０のトークン発行部４５は、認証要求してきた端末１０が管理システム５０にアクセス可能であることを示す認可トークンを発行する（ステップＳ２７）。この認可トークンには、ユーザ名、クライアント名、この認可トークンを利用するサービス名、及びトークンの有効期限などが含まれている。
　なお、通信システム１において、認証及び認可は、OAuth 2.0及びOpenID Connect等のプロトコルを用いて実行することもできる。この場合、ユーザＩＤ／ユーザパスワードなどの認証情報の授受の方法、認可トークンに含まれる内容は、OAuth 2.0及びOpenID Connect等の仕様によって規定されることになる。その場合、トークン自体はJWT(JSON Web Token)であっても良い。また、認可トークンがその経路上で改竄されないことを保証するため、トークン発行部４５は、認可トークンに対して秘密鍵を用いて署名しても良い。秘密鍵は、ＲＳＡ（Rivest, Shamir, Adleman）暗号を用いたものでも良い。なお、署名に、ＨＭＡＣ(Hash-based Message Authentication Code)のような公開鍵を用いても良い。認可トークンを利用する管理システム５０では、認可トークンが秘密鍵で署名されているか共有鍵で署名されているかに応じて、公開鍵または共有鍵を用いて署名の確認をする。署名は例えばJWS(JSON Web Signature)といった公知の標準を用いることもできる。認可トークンは必要に応じて、例えば、JWE(JSON Web Encryption)で暗号化される。
　送受信部４１は、発行された認可トークンを認証結果に含めて端末１０へ送信する。端末１０の送受信部１１は、認証サーバによって送信された認可トークンを含む認証結果を受信する。続いて、端末１０の送受信部１１は受信した認可トークンを管理システム５０へ送信することにより、管理システム５０へログイン要求する（ステップＳ２８）。
　管理システム５０の送受信部５１は、端末１０によって送信されたログイン要求を受信する。管理システム５０のトークン確認部５２は、ログイン要求に含まれる認可トークンを確認する（ステップＳ２９）。この場合、トークン確認部５２は、通信システム１で用いられる標準にしたがって、ログイン要求に含まれている認可トークンを解析する。トークン確認部５２は、解析の結果に応じて、認証サーバによる署名が正しいか否かを判断しても良い。認証サーバによる署名が正しいものではないと判断された場合、トークン確認部５２は、ログイン要求に含まれる認可トークンが改竄されていると判断して、認可に失敗する。
　続いて、トークン確認部５２は、認可トークンに含まれている有効期限を確認することで、認可トークンの有効期限が切れているか否かを判断する。認可トークンの有効期限が切れていると判断された場合、トークン確認部５２は、認可トークンの期限切れにより認可に失敗する。
　続いて、トークン確認部５２は、認可トークンに自管理システムに対応するサービス名が含まれているか否かを確認する。認可トークンに自管理システムに対応するサービス名が含まれていないと判断された場合、トークン確認部５２は、認可に失敗する。
　トークン確認部５２が、認可トークンの署名、有効期限、及びサービスの確認のいずれかの過程で認可に失敗すると、送受信部５１は、端末１０へ認可に失敗した旨を示す認可結果情報を送信する。トークン確認部５２が、認可トークンの署名、有効期限、及びサービスのいずれもが正当なものであると判断した場合、認可トークンに示されているユーザ及びクライアントによるサービスの利用を認可する。ユーザ及びクライアントが認可されると、管理システム５０は、端末１０とのセッションを確立する（ステップＳ３０）。この場合、管理システム５０は、端末１０へ、認可に成功した旨を示す認可結果情報を送信する。
　セッションが確立すると管理システム５０では、認可トークンに含まれているクライアントのユーザ名、及びクライアント名、並びにクライアントのＩＰアドレス等を関連付けて記憶部１０００において管理する。これにより、相手側のクライアントが情報を送信する毎に管理システム５０へ、ユーザ名、及びクライアント名を送信しなくても、管理システム５０では、送信元のクライアントのユーザ名、及びクライアント名を把握できるようになる。
　以下、ユーザ名"a"で端末（第１の通信端末）１０ａが管理システム５０へログインし、ユーザ名"b"で端末（第２の通信端末）１０ｂが管理システム５０へログインしてからの処理について説明する。
　図８を用いて、通信の宛先として指定可能な宛先候補を更新する処理について説明する。図８は、指定可能な宛先候補を更新する処理を示すシーケンス図である。なお、以下、一例として、端末１０ａが宛先候補の更新を要求する処理について説明するが、他の端末１０も同様にして、宛先候補の更新を要求することができる。
　まず、端末１０ａの操作入力受付部１２は、宛先候補の更新要求の入力をユーザａから受け付ける（ステップＳ３１）。更新要求の入力に応じて、端末１０ａの送受信部１１は、更新要求を管理システム５０へ送信する（ステップＳ３２）。更新要求には、宛先候補の追加又は削除を示す更新情報、及び追加又は削除するユーザ名が含まれる。なお、図８に示す処理において、追加及び削除される宛先候補の数は１または複数であってもよい。
　管理システム５０の送受信部５１は、端末１０ａによって送信される更新要求を受信する。更新要求を受信した送受信部５１は、更新要求に含まれる更新情報が宛先候補の追加を示すものであるか判断する（ステップＳ３３）。ここで、更新情報が追加を示すものではないと判断される場合（ステップＳ３３のＮＯ）、後述のステップＳ３６の処理へ進む。
　更新情報が宛先候補の追加を示すものであると判断される場合（ステップＳ３３のＹＥＳ）、管理システム５０の送受信部５１は、更新要求に含まれるユーザ名により管理システム５０へログインした端末１０へ更新要求を送信する（ステップＳ３４）。更新要求に含まれるユーザ名が"b"である場合、管理システム５０の送受信部５１は、ユーザ名"b"で管理システム５０へログインした端末１０ｂへ更新要求を送信する。
　端末１０ｂの送受信部１１は、管理システム５０によって送信される更新要求を受信する。端末１０ｂの操作入力受付部１２は、ユーザｂから更新要求の承認の入力を受け付ける。承認の入力が受け付けられると、端末１０ｂの送受信部１１は、更新要求の承認を示す承認情報を管理システム５０へ送信する（ステップＳ３５）。
　承認情報が受信されると、管理システム５０の記憶・読出部５９は、更新要求に基づきユーザ認可管理テーブルを更新する（ステップＳ３６）。例えば、更新要求に含まれる更新情報が追加であり、更新されるユーザ名が"ｂ"である場合、記憶・読出部５９は、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"に関連付けて、更新要求元のユーザａのユーザ名"a"、及び権限情報"pub"をユーザ認可管理テーブルに追加する。これにより、ユーザａからユーザｂへメッセージを送信可能になる。更に、記憶・読出部５９は、ユーザa宛のメッセージを示すトピック名"Roster/userA"に関連付けて、ユーザｂのユーザ名"b"、及び権限情報"pub"をユーザ認可管理テーブルに追加する。これにより、ユーザｂからユーザａへメッセージを送信可能になる。更新後のユーザ認可管理テーブルを表１Ｂに示す。別の言い方をすれば、ユーザａが、ユーザｂを宛先候補として追加するための更新要求を、管理システム５０に送信すると、ユーザａはユーザｂと情報(メッセージ)を送受信することが可能となる。別の言い方をすれば、ユーザａは、ユーザａに関連付けられた１又は複数の宛先候補と情報(メッセージ)を送受信することができる。
Figure JPOXMLDOC01-appb-T000003
 　なお、更新情報が削除である場合（ステップＳ３３のＮＯ）、記憶・読出部５９は、ユーザ認可管理テーブルにおいて、"Roster"の後にユーザaを示す情報が記述されるトピック名"Roster/userA"を検索し、検索されたトピック名に関連付けられているユーザ名から、更新要求に含まれるユーザ名を削除する。更に、記憶・読出部５９は、ユーザ認可管理テーブルにおいて、"Roster"の後に更新要求に含まれるユーザ名のユーザを示す情報が記述されるトピック名を検索し、検索されたトピック名に関連付けられているユーザ名から、ユーザａのユーザ名"a"を削除する。別の言い方をすれば、例えば、ユーザａが、ユーザｂを宛先候補からするための更新要求を、管理システム５０に送信すると、ユーザａはユーザｂと情報(メッセージ)を送受信することが不可能となる。
　以下、ユーザ認可管理テーブルが表１Ｂに示されるように更新された場合について説明する。
　図９を用いて、端末１０が、通信の宛先として指定可能な宛先候補を示した宛先リストを取得する処理について説明する。図９は、宛先リストを取得する処理を示すシーケンス図である。なお、以下、一例として、端末１０ａが宛先リストを取得する処理について説明するが、他の端末１０も同様にして、宛先リストを取得することができる。
　管理システム５０へログイン後に、端末１０ａの送受信部１１は、宛先リスト取得要求を管理システム５０へ送信する（ステップＳ３７）。宛先リスト取得要求には、ユーザa宛のメッセージを示すトピック名"Roster/userA"が含まれている。
　管理システム５０の送受信部５１は、端末１０ａにより送信される宛先リスト取得要求を受信する。管理システム５０の記憶・読出部５９は、宛先リスト取得要求に含まれるトピック名"Roster/userA"、及び権限情報"pub"の組を検索キーとして利用して、表１Ｂのユーザ認可管理テーブルを検索する。これにより、記憶・読出部５９は、ユーザａへメッセージを送信可能なユーザのユーザ名として"b,m"を読み出す（ステップＳ３８）。なお、他の例として、記憶・読出部５９は、ユーザａのユーザ名"a"を検索キーとして利用して、ユーザ認可管理テーブルを検索し、対応するトピック名を読み出しても良い。これにより、ユーザａによりメッセージを送信可能な宛先候補の情報が取得できる。
　管理システム５０の送受信部５１は、ステップＳ３８で読み出されたユーザ名"b,m"を宛先リストとして、宛先リストの要求元の端末１０ａへ送信する（ステップＳ３９）。これにより、端末１０ａの送受信部１１は、宛先リストを取得する。
　続いて、図１０を用いて端末１０ａ，１０ｂ間でテレビ会議を開始する処理について説明する。図１０は、テレビ会議を開始する処理の一例を示すシーケンス図である。以下、一例として端末１０ａ，１０ｂ間でテレビ会議を開始する処理を説明するが、他の端末１０間でも同様の処理によりテレビ会議を開始できる。
　以下の処理において中継管理サーバ３０は、端末１０、管理システム５０と通信可能に通信ネットワーク２に接続し、端末１０間のコンテンツデータの中継を管理する。中継管理サーバ３０は、例えば、ビデオサーバ、ＭＣＵ（Multi-point Control Unit）、又はＳＩＰサーバである。なお、中継管理サーバ３０のハードウェア構成は管理システム５０と同様であるので説明を省略する。また、中継管理サーバ３０は、中継管理アプリにより、ユーザ名"z"で管理システム５０へログインしている。
　端末１０ａのpubsub要求部１５は、ユーザａ宛てのメッセージを受信するため、ユーザａ宛のメッセージを示すトピック名"Roster/userA"が含まれるsub要求を管理システム５０へ送信する（ステップＳ４１－１）。同様に、端末１０ｂのpubsub要求部１５は、ユーザｂ宛てのメッセージを受け取るため、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"が含まれるsub要求を管理システム５０へ送信する（ステップＳ４１－２）。
　管理システム５０の送受信部５１は、端末１０ａ，１０ｂによって送信されるsub要求をそれぞれ受信する。管理システム５０のpubsub処理部５３は、各端末１０ａ，１０ｂのユーザがsub要求に係るsub権限を有するか判断する（ステップＳ４２）。この場合、pubsub処理部５３は、sub要求ごとに、sub要求に係るトピック名、sub要求元のユーザ名、及びsub権限を有することを示す権限情報"sub"の組が、表１Ｂのユーザ認可管理テーブルにおいて管理されているか判断する。上記の組がユーザ認可管理テーブルにおいて管理されていれば、pubsub処理部５３は、sub要求に係るsub権限を有し、管理されていなければ、sub要求にかかるsub権限を有しないと判断する。以下、それぞれのsub要求に対して、sub権限を有すると判断された場合について説明する。
　pubsub処理部５３は、それぞれのsub要求元のユーザ名"a又はb"、及びsub要求に係るトピック"Roster/userA又はRoster/userB"をセッション管理テーブルに関連付けて登録する（ステップＳ４３）。登録後のセッション管理テーブルを表２Ｂに示す。
Figure JPOXMLDOC01-appb-T000004
 　sub要求が認可されると、端末１０ａの送受信部１１は、ユーザａが参加するテレビ会議に関するトピックの発行を要求するための会議用トピック発行要求を管理システム５０へ送信する（ステップＳ５１）。
　管理システム５０の送受信部５１は、端末１０ａによって送信される会議用トピック発行要求を受信する。会議用トピック発行要求の受信に応じて、pubsub処理部５３は、ユーザａが参加するテレビ会議に関するトピックを発行する（ステップＳ５２）。トピックの発行方法の一例として、pubsub処理部５３は、要求にかかるテレビ会議を識別するためのトピック名として"ConfRoom1"を生成する。
　管理システム５０の送受信部５１は、発行されたトピックのトピック名"ConfRoom1"を、発行要求元の端末１０ａ、及び中継管理サーバ３０へ送信する（ステップＳ５３－１，Ｓ５３－２）。
　会議用のトピックが発行されると、管理システム５０のpubsub処理部５３は、発行されたトピックに対するpub及びsubを、トピックの発行要求元のユーザa、及び中継管理サーバのユーザzに対して認可する（ステップＳ５４）。
別の言い方をすれば、pubsub処理部５３は、ユーザａ及びユーザｚが、トピック名"ConfRoom1"のトピックに対してメッセージをパブリッシュすることを認可し、かつ、pubsub処理部５３は、ユーザａ及びユーザｚが、トピック名"ConfRoom1"のトピックに対して発行されたメッセージを受信することを認可する。この場合、pubsub処理部５３は、発行されたトピックのトピック名"ConfRoom1"、認可されるユーザのユーザ名"a,z"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｃは、登録後のユーザ認可管理テーブルの一例を示す。
Figure JPOXMLDOC01-appb-T000005
 　端末１０ａの送受信部１１は、ステップＳ５３－１で管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。端末１０ａのpubsub要求部１５は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ５５－１）。
　中継管理サーバ３０は、ステップＳ５３－２で管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。中継管理サーバ３０は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ５５－２）。
　管理システム５０の送受信部５１は、端末１０ａ、及び中継管理サーバ３０によって送信されるsub要求をそれぞれ受信する。管理システム５０のpubsub処理部５３は、sub要求元のユーザが、sub要求に係るトピックをsubする権限を有するか判断する（ステップＳ５６）。この場合、pubsub処理部５３は、sub要求ごとに、sub要求に係るトピック名"ConfRoom1"、sub要求元のユーザ名"a又はz"、及びsub権限を有することを示す権限情報"sub"の組が、表１Ｃのユーザ認可管理テーブルにおいて管理されているか判断する。本実施形態では、上記の組が表１Ｃのユーザ認可管理テーブルにおいて管理されているので、pubsub処理部５３は、それぞれのsub要求元がsub権限を有すると判断する。
　それぞれsub権限を有すると判断された場合、pubsub処理部５３は、それぞれのsub要求元のユーザ名"a又はz"、及びsub要求に係るトピック"ConfRoom1"をセッション管理テーブルに関連付けて登録する（ステップＳ５７）。登録後のセッション管理テーブルを表２Ｃに示す。
Figure JPOXMLDOC01-appb-T000006
 　端末１０ａ、及び中継管理サーバ３０は、トピック名"ConfRoom1"のトピックに対して、端末１０ａ及び中継管理サーバ３０間のセッションｓｅｄの呼制御用メッセージをpubすることで、呼制御用メッセージを交換する（ステップＳ５８）。以下一例の処理について説明する。
　端末１０ａのpubsub要求部１５は、トピック名"ConfRoom1"、及び呼制御用メッセージとして端末１０ａ側のコンテンツデータを中継する要求を含むpub要求を管理システム５０へ送信する。管理システム５０の送受信部５１は、端末１０ａによって送信されるpub要求を受信する。
　管理システム５０のpubsub処理部５３は、表１Ｃのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"a"、及びpub要求に含まれるトピック名"ConfRoom1"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"ConfRoom1"のトピックへのpub権限を有すると判断する。pub権限を有すると判断された場合、pubsub処理部５３は、pub要求に含まれるトピック名"ConfRoom1"を検索キーとして利用して、表２Ｃのセッション管理テーブルを検索し、対応するユーザ名"z"を読み出す。管理システム５０のpubsub処理部５３は、読み出されたユーザ名"z"により管理システム５０にログインした中継管理サーバ３０へ呼制御用メッセージを送信する。
　中継管理サーバ３０が、管理システム５０により送信される中継要求を受信すると、端末１０ａから送られてくる画像データ及び音データを所定の端末１０へ中継開始する。これにより、端末１０ａ及び中継管理サーバ３０間のセッションｓｅｄは確立されて、端末１０ａはテレビ会議を開始できるようになる。
　続いて、図１１を用いて、端末１０ａがテレビ会議用のセッションｓｅｄに参加後に、端末１０ｂをこのセッションｓｅｄに参加させる処理を説明する。図１１は、端末１０をセッションに参加させる処理の一例を示すシーケンス図である。
　端末１０ａのpubsub要求部１５は、ユーザｂ宛のメッセージを示すトピック名"Roster/userB"、及びユーザｂを会議に招待する旨を示すメッセージ"Invite"を含むpub要求を管理システム５０へ送信する（ステップＳ６１）。管理システム５０の送受信部５１は、端末１０ａによって送信されるpub要求を受信する。
　管理システム５０のpubsub処理部５３は、表１Ｃのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"a"、及びpub要求に含まれるトピック名"Roster/userB"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する(ステップＳ６２)。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"Roster/userB"のトピックへのpub権限を有するか判断する。
　pub権限を有すると判断された場合、管理システム５０のpubsub処理部５３は、pub要求に含まれるトピック名"Roster/userB"を検索キーとして、表２Ｃのセッション管理テーブルを検索し、対応するユーザ名"b"を読み出す。これにより、pubsub処理部５３は、ユーザｂを、メッセージ"Invite"の宛先に特定する（ステップＳ６３）。
　管理システム５０のpubsub処理部５３は、pub要求元のユーザａが参加しているテレビ会議を示すトピックに対するpub及びsubを、メッセージ"Invite"の宛先として特定されたユーザｂに対して認可する（ステップＳ６４）。この場合、pubsub処理部５３は、上記のトピックに対応するトピック名"ConfRoom1"、特定されたユーザｂのユーザ名"b"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｄは、登録後のユーザ認可管理テーブルの一例を示す。
Figure JPOXMLDOC01-appb-T000007
 　管理システム５０のpubsub処理部５３は、ステップＳ６４において特定されたユーザｂの端末１０ｂへ、端末１０ａのpub要求にかかるトピック名"Roster/userB"及びメッセージ"Invite"を送信する（ステップＳ６５）。これにより、端末１０ｂの送受信部１１は、管理システム５０により送信されるトピック名"Roster/userB"及びメッセージ"Invite"を受信する。
　更に、管理システム５０の送受信部５１は、ユーザｂによるpub及びsubが認可されたトピックのトピック名"ConfRoom1"を、ユーザｂの端末１０ｂへ送信する（ステップＳ６６）。
　端末１０ｂの送受信部１１は、管理システム５０によって送信されるトピック名"ConfRoom1"を受信する。端末１０ｂのpubsub要求部１５は、受信されたトピック名"ConfRoom1"を含みこのトピック名のトピックをsubする要求を示すsub要求を管理システム５０へ送信する（ステップＳ６７）。
　管理システム５０の送受信部５１は、端末１０ｂによって送信されたsub要求を受信する。管理システム５０のpubsub処理部５３は、ステップＳ５６と同様にしてユーザｂがトピック名"ConfRoom1"のトピックをsubする権限を有するか判断する（ステップＳ６８）。
　ステップＳ６８でsub権限を有すると判断された場合、pubsub処理部５３は、sub要求元のユーザ名"b"、及びsub要求に係るトピック"ConfRoom1"をセッション管理テーブルに関連付けて登録する（ステップＳ６９）。登録後のセッション管理テーブルを表２Ｄに示す。
Figure JPOXMLDOC01-appb-T000008
 　端末１０ａ，１０ｂ、及び中継管理サーバ３０は、トピック名"ConfRoom1"のトピックに対して、上記のセッションｓｅｄの呼制御用メッセージをpubすることで、呼制御用メッセージを交換する（ステップＳ７０）。以下一例の処理について説明する。
　端末１０ｂのpubsub要求部１５は、トピック名"ConfRoom1"、及び呼制御用メッセージとしてセッションｓｅｄへの参加要求を含むpub要求を管理システム５０へ送信する。管理システム５０の送受信部５１は、端末１０ｂによって送信されるpub要求を受信する。
　管理システム５０のpubsub処理部５３は、表１Ｄのユーザ認可管理テーブルを参照して、pub要求元のユーザ名"b"、及びpub要求に含まれるトピック名"ConfRoom1"の組に対応付けて、pub権限を有することを示す権限情報"pub"が管理されているか確認する。これにより、pubsub処理部５３は、pub要求元が要求にかかるトピック名"ConfRoom1"のトピックへのpub権限を有するか判断する。pub権限を有すると判断された場合、pubsub処理部５３は、pub要求に含まれるトピック名"ConfRoom1"を検索キーとして、表２Ｄのセッション管理テーブルを検索し、対応するユーザ名"a,b,z"を読み出す。管理システム５０のpubsub処理部５３は、読み出されたユーザ名"a,z"により管理システム５０にログインした端末１０ａ、中継管理サーバ３０へ呼制御用メッセージとして参加要求を送信する。
　端末１０ａ、及び中継管理サーバ３０が参加要求を受信すると、この参加要求を許可することで、端末１０ｂはセッションｓｅｄへ参加する。これにより、端末１０ａ，１０ｂ間でテレビ会議を開始できる。
　＜＜変形例Ａ＞＞
　続いて、上記実施形態に対する変形例Ｂについて上記実施形態と異なる点を説明する。
　管理システム５０のpubsub処理部５３は、ステップＳ５４において、テレビ会議用のトピックに対し、発行要求元のユーザａ、中継管理サーバ３０のユーザｚに加えて、ユーザａによる通信の宛先候補にpub及びsubを認可する。
　ユーザａによる通信の宛先候補を特定する方法を説明する。管理システム５０は、ユーザａを宛先とするメッセージを示すトピック名"Roster/userA"、及び権限情報"pub"の組を検索キーとして表１Ｂのユーザ認可管理テーブルを検索する。これにより、読み出されるユーザ名"b,m"に基づいて、pubsub処理部５３は、ユーザａ，ｍを、宛先候補に特定する。
　pubsub処理部５３は、端末１０ａが参加するテレビ会議を示すトピック名"ConfRoom1"、ステップＳ６４で認可されるユーザのユーザ名"a,b,m,z"、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｅは、登録後のユーザ認可管理テーブルの一例を示す。
Figure JPOXMLDOC01-appb-T000009
 　管理システム５０の送受信部５１は、ステップＳ６４における認可に応じて、トピックのトピック名"ConfRoom1"を、認可されたユーザａ，ｂ，ｍ，ｚのユーザ名"a,b,m,z"により管理システム５０へログインした各端末１０及び中継管理サーバ３０へ送信する（ステップＳ６６）。
　変形例Ｂによると、テレビ会議への招待したいユーザが複数いる場合に、招待したいユーザ毎に招待のメッセージ"Invite"を送信しなくても良くなる。
　＜＜変形例Ｂ＞＞
　続いて、上記実施形態又は上記変形例Ａに対する変形例Ｂについて、上記実施形態又は上記変形例Ａと異なる点を説明する。
　管理システム５０のpubsub処理部５３は、ステップＳ６４において、テレビ会議用のトピックに対し、招待要求先のユーザｂに加えて、ユーザｂが指定可能な宛先候補にpub及びsubを認可する。
　ユーザｂが指定可能な宛先候補を特定する方法を説明する。管理システム５０は、ユーザｂを宛先とするメッセージを示すトピック名"Roster/userB"、及び権限情報"pub"の組を検索キーとして表１Ｃのユーザ認可管理テーブルを検索する。これにより、読み出されるユーザ名"a,n"に基づいて、pubsub処理部５３は、ユーザａ，ｎを、ユーザｂが指定可能な宛先候補に特定する。
　pubsub処理部５３は、端末１０ａが参加するテレビ会議を示すトピック名"ConfRoom1"、ステップＳ６４で新たに認可されるユーザのユーザ名、pub及びsubする権限を示す権限情報"pub,sub"を関連付けて、ユーザ認可管理テーブルに登録する。表１Ｆは、登録後のユーザ認可管理テーブルの一例を示す。
Figure JPOXMLDOC01-appb-T000010
 　管理システム５０の送受信部５１は、ステップＳ６４における認可に応じて、トピックのトピック名"ConfRoom1"を、新たに認可されたユーザのユーザ名により管理システム５０へログインした各端末１０へ送信する（ステップＳ６６）。
　変形例Ｂによると、テレビ会議への招待したいユーザが複数でいる場合に、招待したいユーザ毎に招待のメッセージ"Invite"を送信しなくても良くなる。
　＜＜本実施形態の主な効果＞＞
　続いて、上記の実施形態の主な効果を説明する。上記実施形態の情報送信方法によると、管理システム５０（情報送信システムの一例）は呼制御用のメッセージ（情報の一例）のpub（送信の一例）が認可されたユーザ（アカウントの一例）間で、メッセージを送信させる。管理システム５０のpubsub処理部５３（認可手段の一例）は、第１のアカウントによる会議用トピック発行要求（セッションを開始するための要求の一例）に応じて、第１のアカウントによるpub（メッセージの送信の一例）を認可し、第２のアカウントの招待の要求（第２のアカウントをセッションに参加せるための要求の一例）に応じて、第２のアカウントによるpub（メッセージの送信の一例）を認可する。これにより、アカウント間でメッセージを送信するセッション中に、新たなアカウントに対してメッセージの送信を認可することが可能になる。
　管理システム５０のユーザ認可管理ＤＢ５００３（管理手段の一例）は、第１のアカウントに関連付けられた１又は複数の宛先候補を示すユーザ名（宛先情報の一例）を管理する。管理システム５０のpubsub処理部５３は、第１のアカウントによる第２のアカウントの招待の要求に応じて、上記のユーザ名の宛先候補によるpub（情報の送信）を認可する。これにより、セッションに招待する第２のアカウントが複数いる場合に、アカウントごとに、招待のメッセージを送信しなくても、第２のアカウントがセッションに参加可能になる。
　管理システム５０のユーザ認可管理ＤＢ５００３は、第２のアカウントに関連付けられた１又は複数の宛先候補を示すユーザ名を管理する。管理システム５０のpubsub処理部５３は、第１のアカウントによる第２のアカウントの招待の要求に応じて、上記のユーザ名によって示される宛先候補によるpub（情報の送信）を認可する。これにより、セッションに招待する第２のアカウント（他のアカウント）が複数いる場合に、アカウントごとに、招待のメッセージを送信しなくても、第２のアカウントがセッションに参加可能になる。
　管理システム５０のpubsub処理部５３（生成手段の一例）は、会議用トピック発行要求に応じて、テレビ会議用のセッションに対応するトピックを発行（生成の一例）する。管理システム５０のpubsub処理部５３は、第１のアカウントによる会議用トピック発行要求に応じて、第１のアカウントによる、トピックに対するpub及びsubを認可し、第２のアカウントの招待の要求に応じて、第２のアカウントによる、トピックに対するpub及びsubを認可する。別の言い方をすれば、pubsub処理部５３は、会議用トピック発行要求に応じて、第１のアカウントが、生成されたトピックに対してメッセージをパブリッシュすること及び生成されたトピックに対してパブリッシュされたメッセージを受信することを認可してもよい。また、pubsub処理部５３は、第１のアカウントによる、第２のアカウントを招待する要求に応じて、第２のアカウントが、生成されたトピックに対してメッセージをパブリッシュすること及び生成されたトピックに対してパブリッシュされたメッセージを受信することを認可する。これにより、アカウント間で情報を送信するセッション中に、新たなアカウントに対して情報の送信を認可することが可能になる。
　管理システム５０のユーザ認可管理ＤＢ５００３は、第１のアカウントを示すトピックに関連付けて、トピックに対するパブリッシュが認可される第２のアカウントのユーザ名（識別情報の一例）を管理する。管理システム５０の送受信部１１（送信手段の一例）は、ユーザ認可管理ＤＢ５００３において管理されている第２のアカウントのユーザ名を第１のアカウントへ送信する。これにより、ユーザ認可管理ＤＢ５００３により宛先候補を管理できるので、管理システム５０は、別途、宛先リストを管理する負荷を軽減できる。
　管理システム５０の送受信部５１（受付手段の一例）は、第１のアカウントから、第２のアカウントを宛先候補として追加する要求を受け付ける。管理システム５０の記憶・読出部５９（追加手段の一例）は、第２のアカウントを追加する要求に応じて、ユーザ認可管理ＤＢ５００３において、第１のアカウントを示すトピックに関連付けて要求に係る第２のアカウントのユーザ名を追加する。これにより、管理システム５０は、第１のアカウントの宛先候補を更新できる。
　管理システム５０の送受信部５１前記受付手段は、第２のアカウントを第１のアカウントに関連付けられた１又は複数の宛先候補から削除する要求を受け付ける。管理システム５０の記憶・読出部５９（削除手段の一例）は、第２のアカウントを削除する要求に応じて、ユーザ認可管理ＤＢ５００３において、第１のアカウントを示すトピックに関連付けられている、要求に係る第２のアカウントのユーザ名を削除する。これにより、管理システム５０は、第１のアカウントの宛先候補を更新できる。
　＜＜実施形態の補足＞＞
　端末１０、認証サーバ４０、及び管理システム５０用の各プログラムは、インストール可能な形式又は実行可能な形式のファイルによって、コンピュータで読み取り可能な記録媒体（記録メディア１０６等）に記録されて流通されるようにしてもよい。また、上記記録媒体の他の例として、ＣＤ－Ｒ(Compact Disc Recordable)、ＤＶＤ(Digital Versatile Disk)、ブルーレイディスク等が挙げられる。
　また、上記実施形態の各プログラムが記憶されたＣＤ－ＲＯＭ等の記録媒体、並びに、これらプログラムが記憶されたＨＤ５０４は、プログラム製品(Program Product)として、国内又は国外へ提供されることができる。
　また、上記実施形態における端末１０、認証サーバ４０、及び管理システム５０は、単一のコンピュータによって構築されてもよいし、各部（機能又は手段）を分割して任意に割り当てられた複数のコンピュータによって構築されていてもよい。また、認証サーバ４０及び管理システム５０は、単一のコンピュータによって構築されていても良い。
　上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路を含むプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC(Application Specific Integrated Circuit)や従来の回路モジュール等のデバイスを含むものとする。
　なお、上記した実施形態に係る情報送信システムは、１以上のプログラムを記憶したデバイスメモリーと、１以上のプロセッサによって実現されてもよい。１以上のプロセッサは、１以上のプログラムを実行することで、実施形態において記載された処理を実行する。例えば、デバイスメモリーと１以上のプロセッサは、実施形態に記載されたような機能を実現（実装）することができる。例えば、デバイスメモリーと１以上のプロセッサは、実施形態において記載されたようなハードウェア要素によって実現（実装）されてもよい。
　以上、本発明を実施形態に基づいて説明したが、本発明は上記実施形態に限定されるものではなく、特許請求の範囲に記載の範囲内で様々な変形が可能である。
　本願は、日本特許庁に２０１６年３月２８日に出願された基礎出願２０１６－０６３７５１号の優先権を主張するものであり、その全内容を参照によりここに援用する。
１　通信システム
２　通信ネットワーク
１０　端末
１１　送受信部
１２　操作入力受付部
１３　表示制御部
１４　認証要求部
１５　pubsub要求部
１９　記憶・読出部
４０　認証サーバ
４１　送受信部
４２　ユーザ認証部
４３　クライアント認証部
４４　認可部
４５　トークン発行部
４９　記憶・読出部
５０　管理システム
５１　送受信部
５２　トークン確認部
５３　pubsub処理部
５９　記憶・読出部
１０００　記憶部
４０００　記憶部
４００１　ユーザ管理ＤＢ
４００２　クライアント管理ＤＢ
４００３　サービス管理ＤＢ
４００４　サービス認可管理ＤＢ
５０００　記憶部
５００３　ユーザ認可管理ＤＢ
５００４　セッション管理ＤＢ
特許第５１６０１３４号公報

Claims (9)

  1. 　情報の送信が認可されたアカウントの間で、前記情報を送信させる情報送信システムであって、
    　第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する生成手段と、
    　前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可し、第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する認可手段と、
    　を有する情報送信システム。
  2. 　前記第１のアカウントに関連付けられた１又は複数の宛先候補を示す宛先情報を管理する管理手段を有し、
    　前記認可手段は、前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記宛先情報によって示される前記１又は複数の宛先候補による前記情報の送信を認可する請求項１に記載の情報送信システム。
  3. 　前記管理手段は、前記第２のアカウントに関連付けられた１又は複数の宛先候補を示す宛先情報を管理し、
    　前記認可手段は、前記第１のアカウントによる前記第２のアカウントを前記セッションに参加させるための前記要求に応じて、前記宛先情報によって示される前記第２のアカウントに関連付けられた１又は複数の前記宛先候補による前記情報の送信を認可する請求項２に記載の情報送信システム。
  4. 　前記管理手段は、前記第１のアカウントを示す前記トピックに関連付けて、前記トピックに対するパブリッシュが認可される前記第２のアカウントの識別情報を管理し、
    　前記管理手段において管理されている前記第２のアカウントの前記識別情報を、前記第１のアカウントへ送信する送信手段を有する請求項３に記載の情報送信システム。
  5. 　前記第２のアカウントを宛先候補として追加する要求を受け付ける受付手段と、
    　前記第２のアカウントを追加する前記要求に応じて、前記管理手段において、前記第１のアカウントを示すトピックに関連付けて、前記第２のアカウントの識別情報を追加する追加手段と、
    　を有する請求項４に記載の情報送信システム。
  6. 　前記受付手段は、前記第２のアカウントを前記第１のアカウントに関連付けられた前記１又は複数の宛先候補から削除する要求を受け付け、
    　前記第２のアカウントを削除する前記要求に応じて、前記管理手段から、前記第２のアカウントの識別情報を削除する削除手段を有する請求項５に記載の情報送信システム。
  7. 　前記認可手段は、前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントが、前記トピックに対してメッセージをパブリッシュすること及び前記トピックに対してパブリッシュされたメッセージを受信することを認可し、
    　前記認可手段は、前記第１のアカウントによる前記第２のアカウントを前記セッションに参加させるための前記要求に応じて、前記第２のアカウントが、前記トピックに対してメッセージをパブリッシュすること及び前記トピックに対してパブリッシュされた前記メッセージを受信することを認可する請求項１に記載の情報送信システム。
  8. 　情報の送信が認可されたアカウントの間で、前記情報を送信させる情報送信システムに、
    　第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する処理と、
    　前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
    　第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
    　を実行させる情報送信方法。
  9. 　情報の送信が認可されたアカウントの間で、前記情報を送信させる情報送信システムに、
    　第１のアカウントによるセッションを開始するための要求に応じて、前記セッションに対応するトピックを生成する処理と、
    　前記第１のアカウントによる前記セッションを開始するための前記要求に応じて、前記第１のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
    　第２のアカウントを前記セッションに参加させるための要求に応じて、前記第２のアカウントによる前記トピックに対するパブリッシュ及びサブスクライブを認可する処理と、
    　を実行させるプログラム。
PCT/JP2017/011855 2016-03-28 2017-03-23 情報送信システム、情報送信方法、及びプログラム WO2017170176A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018509211A JP6583543B2 (ja) 2016-03-28 2017-03-23 情報送信システム、情報送信方法、及びプログラム
EP17774714.4A EP3438836A4 (en) 2016-03-28 2017-03-23 INFORMATION TRANSMISSION SYSTEM, INFORMATION TRANSMISSION PROCEDURE AND PROGRAM
US16/129,962 US10778455B2 (en) 2016-03-28 2018-09-13 Conference system, information transmission method, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-063751 2016-03-28
JP2016063751 2016-03-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/129,962 Continuation US10778455B2 (en) 2016-03-28 2018-09-13 Conference system, information transmission method, and storage medium

Publications (1)

Publication Number Publication Date
WO2017170176A1 true WO2017170176A1 (ja) 2017-10-05

Family

ID=59965524

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/011855 WO2017170176A1 (ja) 2016-03-28 2017-03-23 情報送信システム、情報送信方法、及びプログラム

Country Status (4)

Country Link
US (1) US10778455B2 (ja)
EP (1) EP3438836A4 (ja)
JP (1) JP6583543B2 (ja)
WO (1) WO2017170176A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020092318A (ja) * 2018-12-04 2020-06-11 株式会社東芝 中継装置、中継方法及びコンピュータプログラム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11061641B2 (en) 2019-02-28 2021-07-13 Ricoh Company, Ltd. Screen sharing system, and information processing apparatus
US11190369B2 (en) * 2020-03-27 2021-11-30 Sharp Nec Display Solutions, Ltd. Method and system for joining an online meeting
FR3113447B1 (fr) * 2020-08-17 2024-06-21 Canton Consulting Procede de connexion a une visio-conference securisee par authentification forte
CN113727059B (zh) * 2021-08-31 2023-10-24 成都卫士通信息产业股份有限公司 多媒体会议终端入网认证方法、装置、设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005277806A (ja) * 2004-03-25 2005-10-06 Nec Corp プレゼンス情報に基づくグループ通信方式およびクライアント装置
US20080103854A1 (en) * 2006-10-27 2008-05-01 International Business Machines Corporation Access Control Within a Publish/Subscribe System
JP2012252699A (ja) * 2011-06-03 2012-12-20 Nhn Corp メンバー追加を拡張するためのメッセージングサービスシステム及びその方法
JP5160134B2 (ja) 2006-04-12 2013-03-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 配送保証されるコンテンツベースのパブリッシュ／サブスクライブ・システムの動的アクセス制御
WO2013145518A1 (ja) * 2012-03-28 2013-10-03 ソニー株式会社 情報処理装置、情報処理システム、情報処理方法及びプログラム
JP2016063751A (ja) 2014-09-22 2016-04-28 株式会社レックス・ベリー 可塑性食品用分配容器

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8306831B2 (en) * 2005-01-10 2012-11-06 International Business Machines Corporation Systems with message integration for data exchange, collection, monitoring and/or alerting
US20070091834A1 (en) * 2005-10-25 2007-04-26 Hyun Lee Method of increasing the wireless communication range using wireless repeater/amplifier/router
US8255873B2 (en) * 2006-11-20 2012-08-28 Microsoft Corporation Handling external content in web applications
JP5279333B2 (ja) * 2008-04-28 2013-09-04 キヤノン株式会社 システム、接続制御装置、端末装置、制御方法及びプログラム
US8832284B1 (en) * 2011-06-16 2014-09-09 Google Inc. Virtual socializing
US9959523B2 (en) * 2012-03-08 2018-05-01 Google Llc Aggregating a list of current, contextually and/or member-wise relevant video conferences
US9002938B2 (en) * 2012-04-26 2015-04-07 International Business Machines Corporation Notifying electronic meeting participants of interesting information
JP5949272B2 (ja) 2012-07-25 2016-07-06 株式会社リコー 通信システムおよびプログラム
JP6198477B2 (ja) 2013-06-21 2017-09-20 キヤノン株式会社 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム
US20150111553A1 (en) * 2013-10-21 2015-04-23 Vonage Network Llc Method and system for automating conferencing in a communication session
US20160125451A1 (en) * 2014-11-04 2016-05-05 Adobe Systems Incorporated Asset suggestions for electronic posts
JP6724423B2 (ja) * 2015-09-30 2020-07-15 株式会社リコー 通信端末、通信システム、出力方法、及びプログラム
JP2017068596A (ja) * 2015-09-30 2017-04-06 株式会社リコー 管理システム、通信システム、送信制御方法、及びプログラム
JP2017097652A (ja) * 2015-11-25 2017-06-01 株式会社リコー 管理システム、通信システム、通信制御方法、及びプログラム
JP2017098780A (ja) * 2015-11-25 2017-06-01 株式会社リコー 管理システム、通信システム、通信制御方法、及びプログラム
US11863509B2 (en) * 2015-12-18 2024-01-02 Amazon Technologies, Inc. Publish-subscribe message transformation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005277806A (ja) * 2004-03-25 2005-10-06 Nec Corp プレゼンス情報に基づくグループ通信方式およびクライアント装置
JP5160134B2 (ja) 2006-04-12 2013-03-13 インターナショナル・ビジネス・マシーンズ・コーポレーション 配送保証されるコンテンツベースのパブリッシュ／サブスクライブ・システムの動的アクセス制御
US20080103854A1 (en) * 2006-10-27 2008-05-01 International Business Machines Corporation Access Control Within a Publish/Subscribe System
JP2012252699A (ja) * 2011-06-03 2012-12-20 Nhn Corp メンバー追加を拡張するためのメッセージングサービスシステム及びその方法
WO2013145518A1 (ja) * 2012-03-28 2013-10-03 ソニー株式会社 情報処理装置、情報処理システム、情報処理方法及びプログラム
JP2016063751A (ja) 2014-09-22 2016-04-28 株式会社レックス・ベリー 可塑性食品用分配容器

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3438836A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020092318A (ja) * 2018-12-04 2020-06-11 株式会社東芝 中継装置、中継方法及びコンピュータプログラム

Also Published As

Publication number Publication date
US10778455B2 (en) 2020-09-15
JP6583543B2 (ja) 2019-10-02
JPWO2017170176A1 (ja) 2019-02-14
US20190013956A1 (en) 2019-01-10
EP3438836A1 (en) 2019-02-06
EP3438836A4 (en) 2019-03-20

Similar Documents

Publication Publication Date Title
JP6583543B2 (ja) 情報送信システム、情報送信方法、及びプログラム
JP2017068596A (ja) 管理システム、通信システム、送信制御方法、及びプログラム
US9300913B2 (en) Communication system, communication management apparatus, and recording medium
US10498716B2 (en) Management system, communication control method, and communication system
US10164784B2 (en) Communication terminal, communication system, and data transmission method
US10681094B2 (en) Control system, communication control method, and program product
JP2017097652A (ja) 管理システム、通信システム、通信制御方法、及びプログラム
JP2017228145A (ja) 認証システム、通信システム、認証認可方法、及びプログラム
JP6724423B2 (ja) 通信端末、通信システム、出力方法、及びプログラム
US20170339135A1 (en) Authentication system, communication system, and authentication method
US10205686B2 (en) Communication terminal, communication system, and output method
JP2017098780A (ja) 管理システム、通信システム、通信制御方法、及びプログラム
US11128623B2 (en) Service providing system, service delivery system, service providing method, and non-transitory recording medium
JP6729123B2 (ja) 通信システム、リソース管理方法、及びプログラム
US20180183791A1 (en) Remote communication system, remote communication method, and recording medium
US9300915B2 (en) Apparatus, system, and method of managing data, and recording medium
US20150244813A1 (en) Session control system, communication system, session control method, and recording medium storing session control program
US10728254B2 (en) Management system, communication system, and management method
JP7164833B2 (ja) 遠隔コミュニケーションシステム、通信方法、プログラム
JP2022053955A (ja) 方法、プログラム、情報処理装置、認証サーバ、および情報処理システム
JP2017211769A (ja) 管理システム、通信システム、認可方法、及びプログラム
JP2017054325A (ja) 通信システム及び通信方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018509211

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017774714

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017774714

Country of ref document: EP

Effective date: 20181029

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17774714

Country of ref document: EP

Kind code of ref document: A1