JP2017091261A - Device, program, and system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make it easy to share information among devices.SOLUTION: A device of the present invention includes: a reception unit for receiving a request to start sharing information with another first device connected via a first communication path from another second device via a second communication path different from the first communication path; a transmission unit for transmitting permission information necessary for the other first device to participate in sharing information to the other second device via the second communication path when receiving the request; and a control unit for having the other first device participate in sharing information when receiving the permission information via the first communication path.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an apparatus, a program, and a system.

  There is a technique for sharing display contents on a screen among a plurality of electronic blackboards (hereinafter referred to as IWB (Interactive Whiteboard)). In such a technique, a plurality of IWBs communicate with each other via a network, and image data input to one IWB is reflected in the display of another IWB.

  When sharing of display contents among a plurality of IWBs is started, authentication information managed by the IWBs sharing the display contents is used when authenticating the participating IWBs.

  For example, information for starting communication using NFC (Near Field Communication) is exchanged between two portable terminals, and large-capacity multimedia data that cannot be communicated by NFC is exchanged using two communication means other than NFC. A technique for exchanging between portable terminals is disclosed (for example, Patent Document 1).

  However, the conventional technique has a problem that the authentication operation is complicated when the display is shared with other IWBs.

  For example, when sharing the display on one IWB with another IWB, an authentication operation is performed in which authentication information such as the IP address and password of the shared IWB is manually input to the software keyboard of the participating IWB. However, it was a cumbersome operation for the user.

  Therefore, the disclosed technique aims to easily share information between apparatuses.

  In the embodiment, a request to start sharing information with another first device connected via the first communication path is sent to another request via a second communication path different from the first communication path. When receiving a request from a receiving unit that receives from the second device, permission information necessary for participation in sharing information of the other first device is sent to the other second device via the second communication path. An apparatus is disclosed that includes a transmission unit that transmits to a device, and a control unit that causes another first device to participate in information sharing when permission information is received via a first communication path.

  Information can be easily shared between devices.

It is a figure which shows the example of the whole structure of a communication system. It is a figure which shows the example of the hardware block diagram of IWB. It is a figure which shows the example of the hardware block diagram of a terminal. It is a figure which shows the example of the functional block diagram of IWB. It is a figure which shows the example of the data structure of the request received from a terminal. It is a figure which shows the example of the data structure of the response transmitted to a terminal. It is a figure which shows the example of the functional block diagram of a terminal. It is a figure which shows the example of the processing sequence of a communication system. It is a figure which shows the example of the screen (screen 0) before application starting. It is a figure which shows the example of the screen (screen 1) after application starting. It is a figure which shows the example of the screen (screen 2) displayed when a sharing session is started. It is a figure which shows the example of the screen (screen 3) which requests | requires IWB of the 1st participating side made to participate in a sharing session. It is a figure which shows the example of the screen (screen 4) displayed when 1st IWB participates in a sharing session. It is a figure which shows the example of the screen (screen 5) which requests | requires IWB of the 2nd participating side made to participate in a sharing session. It is a figure which shows the example of the screen (screen 6) displayed when 2nd IWB participates in a sharing session. It is a figure which shows the example of the screen (screen 7) which requests | requires IWB of the 3rd participating side made to participate in a sharing session. It is a figure which shows the example of the screen (screen 8) displayed when 3rd IWB participates in a sharing session. It is a figure which shows the example of the flowchart of a process of a terminal. It is a figure which shows the example of the flowchart of a process of IWB.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In addition, in this specification and drawing, about the component which has substantially the same function structure, the duplicate description is abbreviate | omitted by attaching | subjecting the same code | symbol.

<Overall Configuration and Processing of Communication System 1>
FIG. 1 is a diagram illustrating an example of the overall configuration of the communication system 1. The communication system 1 includes a terminal 100 that is an information processing apparatus, an IWB 200A that is an information processing apparatus, an IWB 200B, and an IWB 200C.

  In this embodiment, the communication system 1 uses the terminal 100 to perform processing for causing the IWB 200B and the IWB 200C to share information input to the IWB 200A by the user and displaying the same screen.

  The terminal 100 is a portable device such as a smartphone or a tablet terminal. Hereinafter, when one IWB is indicated, it may be described as IWB200.

  The IWB 200A, IWB 200B, and IWB 200C are connected to the same LAN (Local Area Network) and can communicate with each other via an IP (Internet Protocol) I / F 201A, an IP I / F 201B, and an IP I / F 201C, respectively.

  The terminal 100 has an NFC I / F 102. The IWB 200A, IWB 200B, and IWB 200C include an NFC I / F 202A, an NFC I / F 202B, and an NFC I / F 202C, respectively. The terminal 100 can start communication with each IWB 200 by bringing the terminal 100 close to the position where the NFC I / F 202 is installed.

<HWB block diagram of IWB 200>
FIG. 2 is a diagram illustrating an example of a hardware block diagram of the IWB 200. The IWB 200 includes an IPI / F 201, an NFC I / F 202, a memory 210, a CPU 220, a pointing device 221, and a display device 222.

  The IP I / F 201 is a network interface for communicating with another IWB 200. The NFC I / F 202 receives a request from the terminal 100, transmits authentication information to the terminal 100, and the like. The authentication information will be described later. The NFC I / F 202 communicates with the terminal 100 using a communication standard such as a wireless LAN, Bluetooth (registered trademark), infrared, 3G (mobile phone), or LTE (Long Term Evolution).

  The CPU 220 is a processor that performs overall control of the IWB 200. The CPU 220 controls the operation of each processing unit. The CPU 220 executes programs such as an operating system, applications, and various services stored in the memory 210 and implements various functions of the IWB 200.

  The pointing device 221 is a device that accepts image information input to the IWB 200 by the user. An image input to the pointing device 221 is transmitted to another IWB 200 via the IP I / F 201.

<Hardware block diagram of terminal 100>
FIG. 3 is a diagram illustrating an example of a hardware block diagram of the terminal 100. The terminal 100 includes an NFC I / F 102, a memory 105, a display device 110, a CPU 120, and a pointing device 121.

  The NFC I / F 102 transmits a request to the IWB 200, receives authentication information (response) from the IWB 200, and the like. The NFC I / F 102 may communicate with a terminal according to a communication standard such as wireless LAN, Bluetooth (registered trademark), infrared, 3G (mobile phone), or LTE.

  The CPU 120 is a processor that performs overall control of the terminal 100. The CPU 220 controls the operation of each processing unit. The CPU 120 executes programs such as an operating system, applications, and various services stored in the memory 105 and the like, and realizes various functions of the terminal 100. The memory 105 records authentication information such as an IP address and a password transmitted from the IWB 200.

  The display device 110 is configured by a liquid crystal or an organic EL that displays images, operation icons, and the like. The pointing device 221 detects a touch operation by the user on the display device 110.

<Functional block diagram of IWB 200>
FIG. 4 is a diagram illustrating an example of a functional block diagram of the IWB 200. The IWB 200 includes an NFC detection unit 250, a request reception unit 251, a request determination unit 252, a session start unit 253, an authentication information setting unit 254, a response generation unit 255, a response transmission unit 256, and a session participation unit 257. And have.

  The IWB 200 sets up a connection with another IWB 200 connected via the network and the other IWB 200 in order to share information input by the user. Hereinafter, a connection established by one IWB 200 with another IWB 200 is referred to as a shared session. When a shared session is set between the IWBs 200, information input to one IWB 200 is reflected to the other IWB 200, and similarly, information input to the other IWB 200 is reflected to one IWB 200.

  The NFC detection unit 250 detects a state in which NFC communication from the terminal 100 is possible when the terminal 100 approaches the NFC I / F 202.

  The request receiving unit 251 starts NFC communication with the terminal 100 and receives a request from the terminal 100 when a state in which NFC communication from the terminal 100 is possible is detected. The request receiving unit 251 includes, for example, a start request (START_SHARE) that requests the sharing-side IWB 200 to start a sharing session, and a participation that requests the IWB 200 that wants to participate in information sharing to participate in the sharing session. One of the requests (JOIN_SHARE) is received from the terminal 100. The start request is a request command for requesting the sharing-side IWB 200 to start a shared session. Hereinafter, the IWB 200 on the information sharing side is referred to as the sharing-side IWB 200.

  The participation request is a request command for requesting the IWB 200 that wants to participate in information sharing to participate in the sharing session. Hereinafter, the IWB 200 on the side participating in the information sharing is referred to as the IWB 200 on the participating side. In addition, the participation request includes, as parameters, the IP address of the sharing-side IWB 200 and the password for starting the sharing session, which were included in the response to the start request.

  FIG. 5 is a diagram illustrating an example of a data structure of a request received from the terminal 100. FIG. 5A shows a typical basic structure of a request. For example, the request has a request name and parameters 1 to N. The request name indicates the type of request such as a start request or a participation request. Parameters 1 to N indicate parameters included in the request.

  FIG. 5B shows an example of the data structure of START_SHARE (start request). START_SHARE is a request command for requesting the sharing-side IWB 200 to start a shared session, and may not have parameters.

  FIG. 5C shows an example of the data structure of JOIN_SHARE (participation request). JOIN_SHARE includes the IP address of the sharing-side IWB 200 as parameter 1 and includes a password for starting a shared session as parameter 2.

  Returning to FIG. The request determination unit 252 determines the type of request from the terminal 100 received by the request reception unit 251 (for example, whether it is a start request or a participation request).

  The session start unit 253 performs a process of starting a shared session with another IWB 200 when the received request is a start request.

  Specifically, the session start unit 253 determines whether or not a shared session with another IWB 200 can be started by determining whether or not connection to a network (LAN) is possible. Subsequently, the session start unit 253 requests the authentication information setting unit 254 to set authentication information when a shared session with another IWB 200 can be started. The authentication information includes the IP address of the sharing-side IWB 200 and a password used when performing authentication processing between the other IWB 200. Subsequently, the session start unit 253 requests the response generation unit 255 to generate a response including the set authentication information. Subsequently, the response transmission unit 256 is requested to transmit a response to the terminal 100.

  The authentication information setting unit 254 sets a password used when starting a shared session. For example, the authentication information setting unit 254 may set a different password each time a shared session is started or reset. Thereby, the security function of the communication system 1 can be further strengthened.

  The authentication information setting unit 254 performs authentication by requesting a password or the like when another IWB 200 requests participation in a shared session started by the own device.

  The response generation unit 255 generates a response to the request received from the terminal 100. For example, the response generation unit 255 generates a response including the IP address of the own device and the password set by the authentication information setting unit 254 as a response to the start request. A response to the participation request will be described later.

  The response transmission unit 256 transmits the response generated by the response generation unit 255 to the terminal 100 by NFC.

  FIG. 6 is a diagram illustrating an example of a data structure of a response transmitted to the terminal 100. FIG. 6A shows a typical basic structure of a response. For example, the response has a result and parameters 1 to N. The result is information indicating whether the processing related to the request requested from the terminal 100 succeeded (SUCCESS) or failed (FAILURE). Parameters 1 to N are parameters that the response has.

  FIG. 6B shows an example of a data structure of a response to START_SHARE (start request). The response to the start request includes, in addition to the result, the IP address of the sharing-side IWB 200 as parameter 1, and the password for starting the shared session as parameter 2. In the result, for example, a bit “1” indicating SUCCESS is stored when a shared session with another IWB 200 can be started, and FAILURE is set when the shared IWB 200 cannot communicate with the other IWB 200 and the shared session cannot be started. The indicated bit “0” is stored. As a response to the start request, a response notifying only the result and a response including the IP address and the password may be transmitted separately.

  FIG. 6C illustrates an example of a data structure of a response to JOIN_SHARE (participation request). The response to JOIN_SHARE is only the result, but may include parameters. In the result, for example, a bit “1” indicating SUCCESS is stored when the authentication with the shared IWB 200 is successful, and a bit “0” indicating FAILURE is stored when the authentication fails.

  Returning to FIG. When the received request is a participation request, the session participation unit 257 performs processing for participating in a shared session with the sharing-side IWB 200.

  Specifically, the session participation unit 257 accesses the sharing-side IWB 200 based on the IP address of the sharing-side IWB 200 included in the participation request, and authenticates with the sharing-side IWB 200 based on the password included in the participation request. Process. When the authentication processing with the sharing-side IWB 200 is successful, the response generation unit 255 generates a response storing the bit “1” related to SUCCESS in the result. If the authentication fails, the response generation unit 255 sets the bit “0” related to FAILURE to the result. Is generated. The response transmission unit 256 transmits the response generated by the response generation unit 255 to the terminal 100 by NFC.

  Note that the request and response parameters illustrated in FIGS. 5 and 6 are examples, and may include other parameters.

<Functional Block Diagram of Terminal 100>
FIG. 7 is a diagram illustrating an example of a functional block diagram of the terminal 100. The terminal 100 includes a role determination unit 150, a request generation unit 151, an NFC detection unit 152, a request transmission unit 153, a response reception unit 154, a status display unit 155, and an authentication information holding unit 156.

  Role determining section 150 determines the role of IWB 200 that transmits the request. Specifically, the role determination unit 150 determines the role of the IWB 200 according to the number of times NFC communication has been set since the program for starting a shared session is started on the terminal 100.

  For example, when the number of times NFC communication is set is 1, the role determination unit 150 determines that the IWB 200 communicated by NFC is the shared IWB 200. Further, the role determining unit 150 determines that the IWB 200 communicated by NFC is the participating IWB 200 when the number of times NFC communication is set is two or more. Note that, when the process related to the shared session is reset, the role determining unit 150 resets the number of times of setting NFC communication to 0.

  The request generation unit 151 generates a request to be transmitted to the IWB 200 according to the role of the IWB 200. For example, the request generation unit 151 generates a start request for starting a shared session as a request for the IWB 200 on the sharing side. On the other hand, the request generation unit 151 generates a participation request for participating in the shared session as a request for the IWB 200 on the participation side.

  The NFC detection unit 152 detects a state in which NFC communication is possible when the own device approaches the NFC I / F 202. When the NFC detection unit 152 detects a state where NFC communication is possible, the role determination unit 150 counts the number of times NFC communication is set. Further, when the NFC detection unit 152 cannot detect a state where NFC communication is possible, the NFC detection unit 152 performs processing for detecting NFC communication again after a predetermined time has elapsed.

  The request transmission unit 153 transmits the request generated by the request generation unit 151 to the IWB 200 when the NFC communication is possible. For example, the request transmission unit 153 transmits a start request to the sharing-side IWB 200. Further, the request transmission unit 153 transmits a request for participation request to the IWB 200 on the participation side.

  The response receiving unit 154 receives a response from the IWB 200. For example, the response receiving unit 154 receives, as a response to the start request, a result indicating whether the shared session can be started, the IP address of the sharing-side IWB 200, and a password. The response receiving unit 154 records the received IP address and password of the sharing-side IWB 200 in the authentication information holding unit 156.

  In addition, the response receiving unit 154 receives a result indicating whether or not it can participate in the shared session as a response to the participation request.

  The status display unit 155 displays the processing status based on the response received from the IWB 200. The status display unit 155 responds to each scene, for example, a scene before starting a sharing session, a scene after sending a request to the sharing-side IWB 200, a scene after sending a request to each participating IWB 200, etc. The processing state is displayed on the screen 110 in a format that is easy for the user to determine.

  For example, when a program for starting a sharing session is activated, the status display unit 155 displays an instruction on the screen 110 to hold the terminal 100 over the IWB 200 that is desired to start sharing.

  When the result indicating that the shared session is successfully started (SUCCESS) is notified as a response to the start request, the status display unit 155 displays a notification that the shared session is started on the screen 110.

  In addition, when a result indicating that the start of the shared session has failed (FAILURE) is notified as a response to the start request, the status display unit 155 notifies an error such as a problem in the communication status of the sharing-side IWB 200. It is displayed on the screen 110.

  In addition, when the result indicating that it is possible to participate in the shared session is notified as a response to the participation request, the status display unit 155 displays a notification that the participating IWB 200 has participated on the screen 110. If there is already a participating IWB 200, the status display unit 155 may display the participating IWB 200 as an icon. As a result, the number of other IWBs 200 that are currently participating can be displayed in an easy-to-understand manner for the user.

  Further, when the result indicating that the participation in the shared session is not possible is notified as a response to the participation request, the status display unit 155 displays a notification indicating that the participation in the shared session was not possible (FAILURE) on the screen 110. . Note that the status display unit 155 may display a reason such as a communication failure or the like, which has failed in the authentication process, on the screen 110 together with the result as a reason for failing to participate in the sharing session.

  The authentication information holding unit 156 holds authentication information such as an IP address and a password received from the sharing-side IWB 200 as a response to the start request.

<Processing sequence>
FIG. 8 is a diagram illustrating an example of a processing sequence of the communication system 1. In the example of FIG. 8, the communication system 1 includes a terminal 100, an IWB 200A, an IWB 200B, and an IWB 200C. The processing sequence in FIG. 8 shows processing performed in each of the terminal 100, IWB 200A, IWB 200B, and IWB 200C in time series. The IWB 200A is the shared IWB 200, and the IWB 200B and the IWB 200C are the participating IWB 200, respectively.

  FIG. 9A is a diagram illustrating an example of a screen 110 (screen 0) before the application is activated. Before the application is activated, an icon α is displayed on the home screen of the screen 110. The terminal 100 activates the application when the icon α is double-tapped by the user.

  FIG. 9B is a diagram illustrating an example of the screen 110 (screen 1) after the application is activated. When the application is activated, the terminal 100 displays the screen 1 (Step S10). The terminal 100 displays a message “Please hold it over the IWB that you want to start sharing” as shown in the screen 1 and an icon β1 indicating an instruction to bring the terminal 100 close to the sharing-side IWB 200. For example, as shown in screen 1, the terminal 100 visually indicates to the user an operation for designating the sharing-side IWB 200 by representing an instruction to move the own device to the sharing-side IWB 200 with an icon on the screen 110. Can be easily instructed.

  When the terminal 100 approaches the NFC I / F 202 of the IWB 200A, the terminal 100 transmits START_SHARE (start request) to the IWB 200A by NFC (step S11). The IWB 200A communicates with the IWB 200B and the IWB 200C and determines whether or not a shared session can be started. If the IWB 200A determines that the shared session can be started, the IWB 200A transmits a response including the result indicating that the shared session has been successfully started (SUCCESS), the IP address of the IWB 200A, and the password to the terminal 100 (step S12). Subsequently, the IWB 200A starts a shared session (step S13).

  FIG. 9C is a diagram illustrating an example of a screen 110 (screen 2) displayed when a sharing session is started. When the sharing session is started, the terminal 100 displays, for example, an icon γ1 indicating that the sharing session has started, and a message “sharing has started” on the screen 110 (step S14). For example, by displaying “shared” on the icon indicating the sharing-side IWB 200, the terminal 100 can easily display to the user that the IWB 200A has been normally designated as the sharing-side IWB 200.

  FIG. 9D is a diagram illustrating an example of a screen 110 (screen 3) for requesting the first participating IWB 200 to participate in the sharing session. The terminal 100 displays an icon β2 indicating an instruction to bring the terminal 100 close to the participating IWB 200 and a message “Please hold it over the participating IWB” on the screen 110 (step S15). For example, as shown in screen 3, the terminal 100 visually indicates to the user an operation for specifying the participating IWB 200 by representing an instruction to move the own device to the participating IWB 200 with an icon on the screen 110. Can be easily instructed.

  Subsequently, when the terminal 100 comes close to the NFC I / F 202, the terminal 100 transmits JOIN_SHARE (participation request) to the IWB 200B (step S16). JOIN_SHARE includes the IP address and password received from IWB 200A. Subsequently, the IWB 200B accesses the IWB 200A via the network (LAN), and performs an authentication process on the IWB 200A using the IP address and password received from the terminal 100. Subsequently, if the authentication process is successful, the IWB 200B transmits a result indicating that the participation in the shared session is successful (SUCCESS) to the terminal 100 as a response (step S17). Subsequently, the IWB 200B participates in the sharing session (step S18).

  FIG. 9E is a diagram illustrating an example of a screen 110 (screen 4) displayed when the first IWB 200 participates in the sharing session. When the sharing session is started, for example, the terminal 100 displays a message “I participated” on the screen 110 together with an icon κ1 indicating that the first IWB 200 has participated in the sharing session (step S19). . For example, by displaying “participating” on the icon indicating the participating IWB 200, the terminal 100 can easily display to the user that the IWB 200B has successfully participated in the shared session.

  FIG. 9F is a diagram illustrating an example of a screen 110 (screen 5) for requesting the second participating IWB 200 to participate in the sharing session. The terminal 100 displays an icon κ1 indicating that the IWB 200 is participating in the sharing session and an icon β3 instructing participation, and displays a message “Please hold it over the participating IWB” on the screen 110 ( Step S20). For example, the terminal 100 displays the icon indicating that the IWB 200 is participating in the shared session in parallel with the icon instructing participation, thereby indicating that one IWB 200 has already participated in the shared session. Can be displayed in an easy-to-understand manner.

  Subsequently, when the terminal 100 comes close to the NFC I / F 202 of the IWB 200C, the terminal 100 transmits JOIN_SHARE to the IWB 200C (Step S21). JOIN_SHARE includes the IP address and password received from IWB 200A. Subsequently, the IWB 200C accesses the IWB 200A via the network (LAN), and performs an authentication process on the IWB 200A using the IP address and password received from the terminal 100. Subsequently, when the authentication process is successful, the IWB 200C transmits a result indicating that the participation in the shared session is successful (SUCCESS) to the terminal 100 as a response (step S22). Subsequently, the IWB 200C participates in the sharing session (step S23).

  FIG. 9G is a diagram illustrating an example of a screen 110 (screen 6) displayed when the second IWB 200 participates in the sharing session. When the sharing session is started, for example, the terminal 100 displays a message “I participated” on the screen 110 together with an icon κ2 indicating that the second IWB 200 has participated in the sharing session (step S24). .

  FIG. 9H is a diagram illustrating an example of a screen 110 (screen 7) for requesting the third participating IWB 200 to participate in the sharing session. The terminal 100 displays a message “Please hold it over the participating IWB” on the screen 110 together with the icons κ1 and κ2 indicating that the two IWBs 200 are already participating in the sharing session and the icon β4 instructing participation. (Step S20).

  Furthermore, the IWB 200D can be additionally participated in the shared session by the same operation as the IWB 200B and the IWB 200C.

  FIG. 9I is a diagram illustrating an example of a screen 110 (screen 8) displayed when the third IWB 200 participates in the sharing session. When the sharing session is started, the terminal 100 displays a message “I joined” on the screen 110 together with an icon κ3 indicating that the third IWB 200 has joined the sharing session, for example.

  In this manner, the terminal 100 can display each IWB 200 participating in the information sharing in an easy-to-understand manner for the user by displaying the icon indicating the sharing-side IWB 200 and the icon indicating each participating IWB 200 on the screen 110. .

  The terminal 100 connects the icon indicating the sharing-side IWB 200 and the icon indicating each participating IWB 200 with a bidirectional arrow. Accordingly, the sharing-side IWB 200 and the participating-side IWB 200 communicate with each other, and the information input to the participating-side IWB 200 can be displayed in an easy-to-understand manner. In addition, when the information input to each IWB 200 on the participating side is not reflected on the IWB 200 on the sharing side, a one-way arrow heading the IWB 200 on the participating side may be used.

  In addition, when a new IWB 200 participates in a shared session, the terminal 100 displays a character string for identifying the IWB 200 such as a model name and an identification number of the participating IWB 200 together with an icon indicating that the IWB 200 has participated in the shared session. May be written together. As a result, the IWB 200 that has already participated in the sharing session can be easily identified, which contributes to user convenience.

<Processing flow of terminal 100>
FIG. 10 is a diagram illustrating an example of a flowchart of processing of the terminal 100. When the application 100 is activated or the process is reset, the terminal 100 determines whether to detect NFC by the sharing-side IWB 200 (step S30). If the terminal 100 does not detect NFC by the sharing-side IWB 200 (NO in step S30), the terminal 100 again determines NFC detection after a predetermined time has elapsed (step S30).

  When the terminal 100 detects NFC with the IWB 200 (YES in step S30), since it is the first NFC after the start of processing, the terminal 100 assumes that the IWB 200 is the sharing side and transmits START_SHARE for starting the sharing session to the IWB 200 ( Step S31). Subsequently, the terminal 100 receives a response to START_SHARE including the IP address and password of the sharing-side IWB 200 (step S32). Subsequently, the terminal 100 causes the authentication information holding unit 156 to hold the IP address and password included in the received response (Step S33).

  Subsequently, the terminal 100 determines whether to detect NFC by the participating IWB 200 (step S34). When the terminal 100 does not detect NFC by the participating IWB 200 (NO in step S34), the terminal 100 determines NFC detection again after a predetermined time (step S34).

  If the terminal 100 detects NFC by the participating IWB 200 (YES in step S34), the terminal 100 determines that the IWB 200 is the participating side since it is the second or subsequent NFC after the start of processing, and sets JOIN_SHARE for participating in the shared session to the IWB 200. (Step S35). Subsequently, the terminal 100 receives a response to JOIN_SHARE (step S36).

  The terminal 100 may further perform processing (steps S34 to S36) for causing the other participating IWB 200 to participate in the sharing session.

  In addition, when the said process is reset by the user, it shall return to the starting point of a process even in the middle of a flow.

<Processing flow of IWB 200>
FIG. 11 is a diagram illustrating an example of a flowchart of processing of the IWB 200. When activated, the IWB 200 determines whether to detect NFC by the terminal 100 (step S40). If the IWB 200 does not detect NFC by the terminal 100 (NO in step S30), the IWB 200 determines again NFC detection after a predetermined time (step S40).

  When the IWB 200 detects NFC by the terminal 100 (step S40 YES), the IWB 200 receives a request from the terminal 100 (step S41).

  Subsequently, the IWB 200 determines whether or not a shared session is possible by detecting whether or not communication with the other IWB 200 is possible (step S42). If the IWB 200 cannot have a shared session with another IWB 200 (NO in step S42), the IWB 200 transmits an image notifying that an error has occurred to the terminal 100, and returns to the start point.

  If the IWB 200 can have a shared session with another IWB 200 (YES in step S42), the type of request is determined (step S43). If the request type is START_SHARE, the IWB 200 transmits a response including the IP address and password as a result of the successful start of the shared session (step S44). Subsequently, the IWB 200 starts a sharing session as the sharing-side IWB 200 (step S45).

  On the other hand, if the request type is JOIN_SHARE, the IWB 200 transmits a response including a result indicating that the sharing session has been successfully joined (step S46). Subsequently, the IWB 200 participates in the sharing session as the participating IWB 200 (step S47).

  In this way, for example, by acquiring authentication information using a portable terminal 100 such as a smartphone or a tablet terminal using NFC for the IWB 200 on the sharing side and inputting the authentication information using NFC for the IWB 200 on the participation side, The participating IWB 200 can participate in a sharing session initiated by the sharing IWB 200. This eliminates the need to manually input the authentication information such as the IP address and the password presented at the start of sharing into the software keyboard of the participating IWB, thereby simplifying authentication between devices.

  Further, the terminal 100 displays on the screen 110 the IWB 200 that has participated in the sharing session as to whether or not the sharing session has been started as described above. Thereby, for example, when a user who performs an operation related to a shared session is switched to another user, the user can easily grasp the progress of the shared session, which contributes to user convenience.

  Moreover, although the said embodiment demonstrated the example which applies a process to IWB, it is not limited to this. For example, you may apply to other display apparatuses, such as a projector which can communicate with a terminal using NFC.

  As described above, the present invention is not limited to the above embodiment, and various modifications and improvements can be made within the scope of the present invention.

  In this embodiment, the terminal 100 is an example of another second device according to claim 1 and a device to which claims 5 and 9 are connected. The sharing-side IWB 200 is an example of an apparatus according to claim 1 and an apparatus for sharing information according to claims 5 and 9. The participating IWB 200 is an example of another first apparatus according to claim 1 and an apparatus sharing the information according to claims 5 and 9. The request receiving unit 251 is an example of a receiving unit. The response transmission unit 256 is an example of a transmission unit. The authentication information setting unit 254 is an example of a control unit. The session participation unit 257 is an example of a participation request unit. The request transmission unit 153 is an example of a request unit. The authentication information holding unit 156 is an example of a storage unit. The LAN of the communication system 1 is an example of a first communication path. NFC between the terminal 100 and the IWB 200 is an example of a second communication path. Authentication information (IP address, password) is an example of permission information.

1 Communication system 100 Terminal 102 NFC I / F
110 Screen 150 Role determination unit 151 Request generation unit 152 NFC detection unit 153 Request transmission unit 154 Response reception unit 155 Status display unit 156 Authentication information holding unit 200 IWB
201 IPI / F
202 NFC I / F
250 NFC detection unit 251 Request reception unit 252 Request determination unit 253 Session start unit 254 Authentication information setting unit 255 Response generation unit 256 Response transmission unit 257 Session participation unit

JP 2013-172458 A

Claims (9)

A request to start sharing information with another first device connected via the first communication path is sent to another second device via a second communication path different from the first communication path. A receiver for receiving from the device;
A transmission unit that transmits permission information necessary for participation in sharing of information of the other first device to the other second device via the second communication path when the request is received; ,
And a control unit that causes the other first device to participate in information sharing when the permission information is received via the first communication path.   When the receiving unit receives the permission information from the other second device via the second communication path, the permission information is used for the other first device that has started sharing information. The apparatus according to claim 1, further comprising a participation request unit that requests participation in information sharing.   The device according to claim 1 or 2, wherein the reception unit and the transmission unit communicate with the other second device using a communication interface used for non-contact communication in the second communication path.   The said transmission part transmits the result of whether it started the sharing of information via the said 2nd communication path, or succeeded in participation in information sharing to the said other 2nd apparatus. The apparatus of any one of these. A program that causes a device that connects a device that shares information and a device that shares the information to be connected via a first communication path,
The permission information used when sharing the information of the device that shares the information with the device that shares the information connected via the first communication path shares the information via the second communication path Requesting the device to be
Storing permission information received from a device that shares the information in a storage unit;
Transmitting the permission information stored in the storage unit to a device that shares the information via the second communication path. Determining whether the information sharing apparatus or the information sharing apparatus is based on the number of times communication is set by the second communication path;
If it is determined that the device is to share the information, requesting permission information to the device that shares the information via the second communication path, and further causing the device to be connected to execute,
The program according to claim 5, wherein the transmitting step transmits the permission information to a device sharing the information via a second communication path.   7. The method of causing the apparatus to be connected to further execute a step of displaying on a screen whether or not the apparatus is an information sharing apparatus or an information sharing apparatus based on a determination result in the determining step. The listed program.   The program according to claim 7, wherein the displaying step displays each of devices sharing one or more pieces of information on the screen. A system having an information sharing apparatus, an apparatus sharing the information, an apparatus sharing the information, and an apparatus connecting the information sharing apparatus via a first communication path,
The device to be connected is
The permission information used when sharing the information of the apparatus that shares the information with the apparatus that shares the information connected via the first communication path is used as the permission information used via the second communication path. A request unit for requesting a shared device;
A storage unit that stores permission information received from a device that shares the information,
The request unit transmits the permission information stored in the storage unit to a device that shares the information via the second communication path,
An apparatus for sharing the information includes:
A receiving unit that receives a request to start sharing information to the device that shares the information connected via the first communication path from the device that connects the information via the second communication path;
A transmission unit that transmits permission information used when a device that shares the information participates in information sharing when the request is received, to the device to be connected via the second communication path;
And a control unit that causes a device that shares the information to participate in information sharing when the permission information is received from the device that shares the information via the first communication path.

Images