Patent Publication Number: US-2023139827-A1

Title: Terminal, terminal communication method, and communication system

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the priority benefit of Japan application serial no. 2021-178347, filed on Oct. 29, 2021. The entirety of the above-mentioned patent application is hereby incorporated by reference herein and made a part of this specification. 
     BACKGROUND 
     Technical Field 
     The disclosure relates to a server, an electronic device, a server communication method, a device communication method, and a communication system. 
     Related Art 
     Patent Document 1 (Japanese Patent Application Laid-open No. 2021-177219, e.g., paragraphs 0013, 0014, 0047, 0096, and FIG. 1) discloses a data utilization system S in which sound data stored on a server 10 is transmitted to an electronic musical instrument 50 via a personal computer (PC) 30 and a recording medium 45, and the transmitted sound data is utilized by the electronic musical instrument 50. In the electronic musical instrument 50, since not only sound data pre-built therein but also the sound data acquired from the server 10 can be utilized, these sound data enable an expressive performance. 
     However, in Patent Document 1, the use of the sound data on the server 10 by the electronic musical instrument 50 must be performed through the recording medium 45. Specifically, it is necessary to first store the sound data of the server 10 in the PC 30, then store the stored sound data in the recording medium 45 connected to the PC 30, then remove the recording medium 45 from the PC 30 and connect it to the electronic musical instrument 50, and further store the sound data in the recording medium 45 to the electronic musical instrument 50. Accordingly, there is a problem that significant effort and time are required for a user to utilize the sound data of the server 10 by the electronic musical instrument 50. 
     SUMMARY 
     A terminal according to an embodiment of the disclosure is a terminal connected to a server and connected to an electronic device via the server and includes a correspondence data information storage means, a data association information receiving means, a comparison means, and a display means. The correspondence data information storage means stores correspondence data information of the electronic device. The data association information receiving means receives, from the server, data association information associated with data used for reproduction of sounds or images in the electronic device. The comparison means compares the data association information with the correspondence data information. The display means displays the data association information included in the correspondence data information based on a comparison result obtained by the comparison means. 
     A terminal according to another embodiment of the disclosure is a terminal connected to a server and connected to an electronic device via the server and includes a device association data storage means, a display means, and an instruction transmitting means. The device association data storage means stores device association data of the electronic device. The display means displays a reception screen of instructions for the electronic device. The instruction transmitting means transmits an instruction received by the display means to the electronic device via the server. The display means displays instructions which the electronic device is capable of handling based on the device association data of the electronic device stored in the device association data storage means. 
     A terminal communication method according to an embodiment of the disclosure is executed by a terminal which is connected to a server and connected to an electronic device via the server, and the terminal communication method includes the following steps. Data association information associated with data used for reproduction of sounds or images in the electronic device is received from the server. The received data association information is compared with correspondence data information of the electronic device stored in the terminal. The data association information included in the correspondence data information is displayed based on a result of the comparison. 
     A communication system according to an embodiment of the disclosure includes the terminal above. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1 A  illustrates an outline of a communication system.  FIG.  1 B  illustrates an appearance of a communication device. 
         FIG.  2    illustrates communication performed by a communication device, an electronic musical instrument, a mobile terminal, and a server in a setup mode. 
         FIG.  3 A  illustrates communication performed by the communication device, the electronic musical instrument, the mobile terminal, and the server after the setup mode.  FIG.  3 B  is a view showing correspondence timbre information. 
         FIG.  4 A  is a view illustrating an outline of loading, writing, and installation.  FIG.  4 B  is a view showing each timbre data.  FIG.  4 C  is a view showing each wave data.  FIG.  4 D  is a view showing each expansion sound source data set. 
         FIG.  5    is a view showing the communication performed by the communication device, the electronic musical instrument, the mobile terminal, and the server in loading. 
         FIG.  6    is a view showing the communication performed by the communication device, the electronic musical instrument, the mobile terminal, and the server in writing. 
         FIG.  7    is a view showing the communication performed by the communication device, the electronic musical instrument, the mobile terminal, and the server in installation. 
         FIG.  8    is a functional block diagram of the server. 
         FIG.  9    is a block diagram showing electrical configurations of the communication device and the electronic musical instrument in the communication system. 
         FIG.  10    is a block diagram showing electrical configurations of the mobile terminal and the server in the communication system. 
         FIG.  11 A  schematically illustrates a user database (DB).  FIG.  11 B  schematically illustrates a device DB.  FIG.  11 C  is schematically illustrates sync data.  FIG.  11 D  schematically illustrates a load history. 
         FIG.  12 A  is a flowchart of a communication device main processing.  FIG.  12 B  is a flowchart of a mobile terminal main processing.  FIG.  12 C  is a flowchart of a server main processing. 
         FIG.  13    is a flowchart of a BT communication part setup processing. 
         FIG.  14    is a flowchart of a Wi-Fi main processing. 
         FIG.  15    is a flowchart of a Wi-Fi communication part setup processing. 
         FIG.  16    is a flowchart of a mobile terminal setup processing. 
         FIG.  17    is a flowchart of a server setup processing. 
         FIG.  18    is a flowchart of a Wi-Fi communication part workflow processing. 
         FIG.  19    is a flowchart of an electronic musical instrument workflow processing. 
         FIG.  20    is a flowchart of a mobile terminal workflow processing. 
         FIG.  21    is a flowchart of an HTTPS workflow processing. 
         FIG.  22    is a flowchart of an MQTT workflow processing. 
         FIG.  23    is a flowchart of a mobile terminal event processing. 
         FIG.  24 A  is a flowchart of a mobile terminal loading processing.  FIG.  24 B  is a flowchart of a mobile terminal writing processing.  FIG.  24 C  is a flowchart of a mobile terminal installation processing. 
         FIG.  25    is a flowchart of a server MQTT event processing. 
         FIG.  26    is a flowchart of a server HTTPS event processing. 
         FIG.  27    is a flowchart of a server sync processing. 
         FIG.  28    is a flowchart of an electronic musical instrument event processing. 
         FIG.  29    is a flowchart of an electronic musical instrument writing processing. 
         FIG.  30    is a flowchart of an electronic musical instrument installation processing. 
     
    
    
     DESCRIPTION OF THE EMBODIMENTS 
     Embodiments of the disclosure provide a server, an electronic device, a server communication method, a device communication method, and a communication system in which data on the server can be easily used in the electronic device. 
     Hereinafter, exemplary embodiments will be described with reference to the accompanying drawings. An outline of a communication system S of the present embodiment will be described with reference to  FIG.  1 A  and  FIG.  1 B .  FIG.  1 A  illustrates the outline of the communication system S, and  FIG.  1 B  illustrates an appearance of a communication device  1 . As shown in  FIG.  1 A , the communication system S includes an electronic musical instrument  30 , a mobile terminal  50 , and a server  70 . The electronic musical instrument  30  is connected to an access point (AP)  90  by wireless communication by Wi-Fi®, and is connected to the Internet N from the AP  90 . The mobile terminal  50  is connected to a base station  100 , and is connected to the Internet N from the base station  100 . Since the server  70  is also connected to the Internet N, the electronic musical instrument  30  and the server  70  as well as the mobile terminal  50  and the server  70  are configured to be mutually communicable via the Internet N. Accordingly, information can be exchanged between the electronic musical instrument  30  and the mobile terminal  50  via the server  70 . 
     The electronic musical instrument  30  is a device (electronic device) that produces a musical tone based on a performance of a user H. The electronic musical instrument  30  is provided with timbre data having information about timbre and wave data, and a timbre according to selection of the user H is acquired from the timbre data and the wave data and outputted as a musical tone. The timbre data and the wave data may be built in the electronic musical instrument  30  at the time of factory shipment, and may also be acquired from the server  70  via the Internet N. Next, communication by the electronic musical instrument  30  like this with an external device such as the server  70  will be described. 
     The communication device  1  is connected to the electronic musical instrument  30 . The communication device  1  is a device that communicates with the external device by Wi-Fi or Bluetooth®, and is detachably connected to the electronic musical instrument  30  via USB®. The data inputted from the electronic musical instrument  30  to the communication device  1  via USB is transmitted to the external device via Wi-Fi or Bluetooth. On the other hand, the data received by the communication device  1  from the external device via Wi-Fi or Bluetooth is inputted to the electronic musical instrument  30  via USB. As shown in  FIG.  1 B , the communication device  1  is provided with an operation button  2  for inputting an instruction from the user H, and an LED  3 . An operation state of the communication device  1  is notified to the user H by a lighting state or blinking state of the LED  3 . 
     The communication device  1  is connected to the AP  90  by Wi-Fi communication, and is connected to the Internet N via the AP  90 . Since the server  70  is connected to the Internet N, the electronic musical instrument  30  is able to communicate with the server  70  via the communication device  1 . 
     The mobile terminal  50  is an information processing device (computer) that performs a processing according to the instruction inputted from the user H. The mobile terminal  50  is configured to be able to acquire the timbre data from the server  70  to the electronic musical instrument  30  in response to the instruction from the user H, and details thereof will be described later. In the mobile terminal  50 , the timbre data stored on the server  70  can also be acquired via the Internet N and utilized. 
     The server  70  is an information processing device that stores timbre data, wave data, expansion sound source data sets, etc. to be used in the electronic musical instrument  30  and the mobile terminal  50 . The timbre data are data composed of a plurality of variable values (attack, decay, cutoff, etc.) related to the timbre. The wave data are digitally converted from basic waveforms such as sine waves, square waves, triangular waves, sawtoothed waves, and sound waveforms of acoustic instruments collected by a microphone. Based on the wave data selected by the user H as an original sound, the electronic musical instrument  30  processes the sound according to each variable value set in the timbre data similarly selected by the user H and produces a sound of the processed timbre. The respective timbre data may be processed and a sound of the processed timbre may be produced based on only the wave data referred to by each timbre data. The expansion sound source data set is a set of a plurality of timbre data and wave data. 
     In addition to the timbre data, the wave data, and the expansion sound source data sets, the server  70  also stores musical score data or the like to be utilized by the electronic musical instrument  30  or the mobile terminal  50 . Hereinafter, data such as the timbre data stored on the server  70  that can be utilized by the electronic musical instrument  30  or the mobile terminal  50  will be referred to as “resources”. 
     When connecting the communication device  1  to the AP  90 , it is necessary to set information about the AP  90  to be connected and a password for connecting to the AP  90  in the communication device  1 . Since the communication device  1  and the electronic musical instrument  30  to which the communication device  1  is connected are only provided with a display device having the minimum necessary display capability or input capability, it is difficult for the user H to input the information about the AP  90  and the password of the AP  90  by the communication device  1  and the electronic musical instrument  30 . 
     In the present embodiment, in the mobile terminal  50 , a list of APs  90  searched by the communication device  1  is displayed, and the user H selects one AP  90  from the displayed list and inputs the password for connecting to the AP  90 . The information about the selected AP  90  and the inputted password are transmitted to the communication device  1 , and the communication device  1  performs connection to the AP  90  by using the received information about the AP  90  and the received password of the AP  90 . Accordingly, since there is no need for the user H to input the information about the AP  90  or the password of the AP  90  by the communication device  1  and the electronic musical instrument  30 , time and effort in connecting the communication device  1  and the electronic musical instrument  30  to the AP  90  can be reduced. 
     Next, communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  will be described with reference to  FIG.  2    and  FIG.  3 A .  FIG.  2    illustrates the communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  in a setup mode. In the communication system S, in the case where an instruction for a setup mode is given from the user H to the communication device  1  via the operation button  2 , connection to each of the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  is performed. 
     Among them, the communication device  1  is provided with a Wi-Fi communication part  4  that performs communication by Wi-Fi and a BT communication part  5  that performs communication by Bluetooth. The mobile terminal  50  is provided with a BT communication part  60  that performs communication by Bluetooth and a base communication part  61  that communicates with a mobile phone base station  100  (hereinafter abbreviated as “base station  100 ”). 
     The setup mode is a mode for the communication device  1  to acquire from the mobile terminal  50  the information about the AP  90  (one selected as a connection destination by the user H) to be connected by Wi-Fi in order to connect the communication device  1  to the AP  90 . In the setup mode, reception of the information about the AP  90  from the mobile terminal  50  to the communication device  1  is performed by Bluetooth via the BT communication part  5 . In the setup mode, the communication of the information about the AP  90  is not necessarily performed by Bluetooth but may also be performed by other short-range wireless communication standards such as ZigBee®. 
     First, in the case where the communication device  1  is inserted into the electronic musical instrument  30  and the operation button  2  of the communication device  1  is pressed and held (e.g., the operation button  2  is continuously pressed for 5 seconds), the communication device  1  shifts to the setup mode (T 1 ). The user H may be notified that the communication device  1  is in the setup mode by blinking the LED  3  at intervals of a predetermined time (e.g., 0.5 seconds) during execution of the setup mode. 
     The instruction for the setup mode is not limited to the case where the operation button  2  is pressed and held, but it is also possible to shift to the setup mode in the case where the operation button  2  is pressed a predetermined number of times (e.g., three times) in succession. The shift to the setup mode is not necessarily performed by operating the operation button  2  of the communication device  1 . For example, it is also possible to shift to the setup mode in response to an instruction from the electronic musical instrument  30  connected to the communication device  1 . 
     In order to pair the communication device  1  that has shifted to the setup mode by the processing of T 1  with the mobile terminal  50  by Bluetooth, the BT communication part  5  is set to a standby state, that is, a slave (child) state (T 2 ). On the other hand, in the mobile terminal  50 , in the case where the instruction for the setup mode is inputted to the mobile terminal  50 , the BT communication part  60  is set to a transmission state, that is, a master (parent) state (T 3 ). The mobile terminal  50  that has discovered the communication device  1  in the standby state by the processing of T 3  establishes pairing with the communication device  1  (A 1 ). 
     In the pairing between the communication device  1  and the mobile terminal  50  in the processings of T 2  and T 3 , the communication device  1  is set to the standby state and the mobile terminal  50  is set to the transmission state. However, the disclosure is not limited thereto. The mobile terminal  50  may also be set to the standby state and the communication device  1  may also be set to the transmission state. 
     Herein, the mobile terminal  50  registers the user H with the server  70  via the base communication part  61  before the processings of T 3  and A 1  (A 2 ). In response to such user registration, the server  70  creates a user identifier being an identifier unique to each user and registers the user identifier in a user DB  72   b  (see  FIG.  11 A ) of the server  70  (T 4 ). After the processing of T 4 , the mobile terminal  50  logs in to the server  70  by the user H (A 3 ). At the time of login, hypertext transfer protocol secure (HTTPS) access authorization information is transmitted from the server  70  to the mobile terminal  50 , and will be used for subsequent HTTPS protocol communication from the mobile terminal  50  to the server  70 . 
     After the pairing by the processing of A 1  is established, the mobile terminal  50  requests device registration data from the communication device  1  via the BT communication part  60  (A 4 ). The device registration data is composed of a device identifier being an identifier uniquely set for each communication device  1  and product information indicating a product name or the like of the communication device  1 . The device identifier of the communication device  1  like this is registered with the server  70  to be described later. Since the device identifier is uniquely set for each communication device  1 , even if the user H owns multiple electronic musical instruments  30 , by sharing and using one registered communication device  1  in the multiple electronic musical instruments  30 , time and effort to register with the server  70  for each electronic musical instrument  30  can be saved. 
     The device identifier is not limited to an identifier unique to each communication device  1 , but may also be an identifier that identifies the electronic musical instrument  30  connected to the communication device  1 . In this case, the communication device  1  can uniquely identify the electronic musical instrument  30  by acquiring the identifier of the electronic musical instrument  30  from the electronic musical instrument  30  connected to the communication device  1 . 
     In response to the request for device registration data by the processing of A 4 , the communication device  1  transmits the device registration data including its own device identifier and product information to the mobile terminal  50  via the BT communication part  5  (A 5 ). The mobile terminal  50  that has received the device registration data of the communication device  1  by the processing of A 5  transmits the device registration data to the server  70  via the base communication part  61  (A 6 , A 7 ). 
     The server  70  registers the device registration data received by the processing of A 7  in a device DB  72   c  (see  FIG.  11 B ) together with the user identifier corresponding to the user H who has logged in by the above processing of A 3  (T 5 ). Thus, the user identifier of the logged-in user H and the device registration data of the communication device  1  connected to the electronic musical instrument  30  used by the user H are stored in association in the device DB  72   c.    
     After transmission of the device registration data of the communication device  1  by the above processing of A 5 , in order to acquire the list of APs  90  searched by the communication device  1 , the mobile terminal  50  requests the list of APs  90  from the communication device  1  via the BT communication part  60  (A 8 ). The request for the list of APs  90  received by the BT communication part  5  of the communication device  1  by the processing of A 8  is transmitted to the Wi-Fi communication part  4  (A 9 ). The Wi-Fi communication part  4  that has received the request for the list of APs  90  by the processing of A 9  searches for APs  90  capable of communication with the Wi-Fi communication part  4  and creates a list of APs  90  searched (T 6 ). 
     The BT communication part  5  acquires the list of APs  90  created by the Wi-Fi communication part  4  by the processing of T 6  (A 10 ), and the list of APs  90  is transmitted to the mobile terminal  50  via the BT communication part  5  (A 11 ). The mobile terminal  50  that has received the list of APs  90  by the processing of A 11  displays the list of APs  90  and causes the user H to select one of the APs  90 . Then, the selected AP  90  and the password (input PSW) for connecting to the AP  90  are acquired and transmitted to the communication device  1  via the BT communication part  60  (A 12 ). 
     The communication device  1  that has received the selected AP  90  and the input PSW thereof by the processing of A 12  transmits these pieces of information to the Wi-Fi communication part  4  (A 13 ) and stores these pieces of information (T 7 ). After the processing of T 7 , the Wi-Fi communication part  4  connects to the AP  90  in the received information by using the received input PSW (T 8 ). 
     From this point on, or in the case where the communication system S does not shift to the setup mode, the communication device  1  is connected to the AP  90  using the information stored by the processing of T 7 . Accordingly, the communication device  1  and the electronic musical instrument  30  are connected to the AP  90  via the Wi-Fi communication part  4 , and are able to communicate with the server  70  via the AP  90  and the Internet N. 
     In the BT communication part  5  of the communication device  1  and the BT communication part  60  of the mobile terminal  50 , in the case where the transmission by the processing of A 11  is completed, the Bluetooth communication is disconnected and the pairing is canceled (T 9 , T 10 ). In the present embodiment, the device registration data is first registered with the server  70  by the processings of A 4  to A 7 , and after that, the information about the AP  90  or the like is transmitted from the mobile terminal  50  to the communication device  1  by the processings of A 8  to A 13 , T 6 , and T 7 . However, the disclosure is not limited thereto. The processings of A 8  to A 13 , T 6 , and T 7  may also be performed first, followed by the processings of A 4  to A 7 , or the processings of A 4  to A 7  may also be performed in parallel with the processings of A 8  to A 13 , T 6 , and T 7 . 
     As described above, in the setup mode, the information about the AP  90  connected by the Wi-Fi communication part  4  of the communication device  1  is transmitted from the mobile terminal  50  by Bluetooth communication. Accordingly, the AP  90  can be connected without inputting the information about the AP  90 , i.e., the target AP  90  and the input PSW thereof, by the communication device  1  and the electronic musical instrument  30  that are more restricted as input devices as compared with the mobile terminal  50 . Accordingly, the time and effort to be spent by the user H when connecting the communication device  1  and the electronic musical instrument  30  to the AP  90  can be reduced. 
     Herein, when the information about the AP is to be transmitted by Bluetooth communication, it is necessary to pair the BT communication part  5  of the communication device  1  with the BT communication part  60  of the mobile terminal  50 . However, in such pairing, there is no need for the user H to input authentication information or the like. Thus, the time and effort to be spent by the user H when connecting the communication device  1  and the electronic musical instrument  30  to the AP  90  can be reduced. 
     When the pairing between the BT communication part  5  of the communication device  1  and the BT communication part  60  of the mobile terminal  50  is established, the device registration data of the communication device  1  is transmitted to the server  70  via the mobile terminal  50 , and is registered in the device DB  72   c  together with the user identifier of the user H who has logged in to the server  70  from the mobile terminal  50 . Accordingly, the device registration data of the communication device  1  can be reliably registered with the server  70  in association with the user identifier of the user H. 
     Based on the device registration data and the user identifier registered with the server  70  in this way, after the setup mode, resources stored on the server  70  can be accessed from the electronic musical instrument  30 . Further, when the pairing between the BT communication part  5  of the communication device  1  and the BT communication part  60  of the mobile terminal  50  is established, since the device registration data of the communication device  1  is automatically transmitted to the server  70 , the time and effort to be spent by the user H when registering the device registration data with the server  70  can be reduced. 
     Next, communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  after the communication device  1  is connected to the AP  90  by the setup mode of  FIG.  2    will be described.  FIG.  3 A  illustrates the communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  after the setup mode. 
     In the communication system S, after the setup mode, a resource stored on the server  70  is received by the communication device  1 , and the received resource is utilized by the electronic musical instrument  30 . Specifically, first, the device identifier of the communication device  1  is transmitted from the communication device  1  to the server  70  via the Wi-Fi communication part  4  (A 20 ). In the processing of A 20 , the transmission of the device identifier from the communication device  1  to the server  70  is performed by communication using a message queuing telemetry transport (MQTT) protocol. The communication of the communication device  1  with the server  70  in and after A 20  is performed via the Wi-Fi communication part  4 . 
     The server  70  that has received the device identifier by the processing of A 20  acquires the user identifier corresponding to the device identifier from the device DB  72   c  (see  FIG.  11 B ), and creates the HTTPS access authorization information based on the user identifier (T 20 ). The HTTPS access authorization information is information for authorizing the user H to access a resource when the communication device  1  communicates with the server  70  by HTTPS. 
     The HTTPS access authorization information created by the processing of T 20  and the user identifier corresponding to the device identifier transmitted by the processing of A 20  are transmitted to the communication device  1  by communication using the MQTT protocol (A 21 ). The user identifier received by the processing of A 21  will be used for subsequent communication between the communication device  1  and the server  70  using the MQTT protocol. The user identifier and the HTTPS access authorization information received together with the user identifier will be used for subsequent communication between the communication device  1  and the server  70  using an HTTPS protocol. 
     After the processing of A 21 , a request of the user H for accessing the resource is transmitted from the communication device  1  to the server  70  in response to an instruction from the electronic musical instrument  30  (A 22 ). The transmission of the request in the processing of A 22  is performed by communication using the HTTPS protocol, and at that time, the request is transmitted including the user identifier and the HTTPS access authorization information received by the processing of A 21 . 
     In the case where the server  70 , upon receiving the request by the processing of A 22 , determines that the HTTPS access authorization information is valid for the requested resource, the server  70  transmits the resource to the communication device  1  that made the request by the processing of A 22  (A 23 ). The transmission from the server  70  to the communication device  1  by the processing of A 23  is also performed by communication using the HTTPS protocol, like the processing of A 22 . The resource transmitted by the processing of A 23  is transmitted from the communication device  1  to the electronic musical instrument  30 , and is utilized by the electronic musical instrument  30 . In the processing of A 22 , in order to confirm (verify) whether the requested resource belongs to the user H, the user identifier included in the received request may be confirmed, or both the HTTPS access authorization information and the user identifier may be confirmed. 
     After the processing of A 23 , in response to an instruction from the electronic musical instrument  30 , correspondence timbre information of the electronic musical instrument  30  is transmitted from the communication device  1  to the server  70  (A 23 - 2 ).  FIG.  3 B  is a view showing the correspondence timbre information. Specifically, the timbre attribute represents an attribute of the timbre data that can be used by the electronic musical instrument  30 , and includes, for example, “tone”, “rhythm”, and “natural”. The wave data ID is an identifier of the wave data that can be used by the electronic musical instrument  30 , and the wave data that can be used are stored in a wave data memory  32   c  of the electronic musical instrument  30  to be described later with reference to  FIG.  4 A . The expansion sound source data set ID is an identifier of the expansion sound source data set that may be expanded by the electronic musical instrument  30 . The server  70  registers the correspondence timbre information received by the processing of A 23 - 2  in association with the device identifier in the device DB  72   c  (T 20 - 2 ). 
     As described above, after the setup mode, the communication device  1  transmits its own device identifier to the server  70 , and the user identifier corresponding to the device identifier and the HTTPS access authorization information created based on the user identifier are transmitted from the server  70  to the communication device  1 . The communication device  1  acquires the resource from the server  70  by using the received HTTPS access authorization information or the user identifier, and the resource acquired by the communication device  1  is utilized by the electronic musical instrument  30 . That is, when the resource on the server  70  is to be acquired in the electronic musical instrument  30 , the resource can be directly acquired from the server  70  without acquiring via another recording medium or the like. Accordingly, the resource on the server  70  can be easily acquired and utilized on the electronic musical instrument  30 . 
     Further, the communication device  1  receives the user identifier of the user H of the connected electronic musical instrument  30  and the HTTPS access authorization information created based on the user identifier, and acquires the resource of the user H from the server  70  by using these pieces of information. That is, since the resource of the user H corresponding to the communication device  1  is acquired by the electronic musical instrument  30  of the user H, it is possible to prevent the electronic musical instrument  30  of the user H from accessing a resource of another user H. 
     The transmission of the device identifier from the communication device  1  by the processings of A 20  and A 21  and the transmission of the user identifier and the HTTPS access authorization information are performed by communication using the MQTT protocol. Since communication using the MQTT protocol is more lightweight than communication using the HTTPS protocol, the transmission of the device identifier and the transmission of the user identifier and the HTTPS access authorization information by the processings of A 20  and A 21  can be quickly performed. 
     Further, the acquisition of the HTTPS access authorization information and the user identifier from the server  70  by the communication device  1  is performed immediately after each time the communication between the communication device  1  and the server  70  is established, whether the setup mode has been executed or not. Accordingly, since the HTTPS access authorization information in particular will be the latest when communication with the server  70  is established, it is possible to prevent using the same HTTPS access authorization information for a long period of time. 
     For example, by regularly updating the format of the HTTPS access authorization information transmitted by the server  70  to the communication device  1 , even if the HTTPS access authorization information or the request by the processing of A 22  based on the HTTPS access authorization information is leaked, after the HTTPS access authorization information is updated, no more resources can be acquired from the server  70  by the leaked HTTPS access authorization information. Thus, leakage of the resource on the server  70  can be more effectively prevented. 
     The communication of A 20  and A 21  is not limited to communication using the MQTT protocol, but may also be performed according to other communication methods such as communication using the HTTPS protocol. Also, the communication of A 22  and A 23  is not limited to communication using the HTTPS protocol, but may also be performed according to other communication methods such as communication using the MQTT protocol. 
     In addition to utilization of the resource on the server  70  by the electronic musical instrument  30  in response to an instruction of the user H given to the electronic musical instrument  30  in this way, the resource on the server  70  can also be utilized by the electronic musical instrument  30  in response to an instruction of the user H given to the mobile terminal  50 . Such utilization of the resource on the server  70  by the electronic musical instrument  30  in response to the instruction to the mobile terminal  50  will be described. 
     After the setup mode described with reference to  FIG.  2   , the mobile terminal  50  logs in to the server  70  via the base communication part  61  (A 24 ). At the time of login, the HTTPS access authorization information is transmitted from the server  70  to the mobile terminal  50 , and will be used for subsequent HTTPS protocol communication from the mobile terminal  50  to the server  70 . The login by the processing of A 24  may be omitted in the case where the login by the processing of A 3  of  FIG.  2    described above continues (that is, in the case where no logout has occurred). Subsequent communication of the mobile terminal  50  with the server  70  will be performed via the base communication part  61 . 
     After the processing of A 24 , the user identifier of the logged-in user H is requested (A 25 ), the server  70  searches the user DB  72   b  for the requested user identifier (T 21 ), and the searched user identifier is transmitted to the mobile terminal  50  that made the request for the user identifier (A 26 ). The mobile terminal  50  requests from the server  70  the device registration data and the correspondence timbre information corresponding to the user identifier received by the processing of A 26  (A 27 ). 
     The server  70  searches the device DB  72   c  for the device registration data and the correspondence timbre information corresponding to the user identifier requested by the processing of A 27  (T 22 ), and transmits the corresponding device registration data and the correspondence timbre information to the mobile terminal  50  that made the request (A 28 ). 
     The mobile terminal  50  registers the device registration data and the correspondence timbre information received by the processing of A 28  in an owned device list  53   a  (T 24 ). In the case where multiple pieces of device registration data and correspondence timbre information are registered in the owned device list  53   a  by the processing of T 24 , such as where the user H has multiple electronic musical instruments  30 , the user H is caused to select the device registration data corresponding to the communication device  1  of the electronic musical instrument  30  that will utilize the resource on the server  70  according to the instruction to the mobile terminal  50 . 
     After the processing of T 24 , the mobile terminal  50  operates as a user interface (UI) of the electronic musical instrument  30  to which the communication device  1  corresponding to the selected device registration data is connected (T 25 ). A request based on an instruction for the electronic musical instrument  30  or the server  70  and accompanying information, and the user identifier received by the processing of A 26  and the device identifier of the selected device registration data is transmitted from the mobile terminal  50  to the server  70  (A 29 ). 
     The server  70  transmits the request by the processing of A 29  to the communication device  1 , the communication device  1  transmits the request received from the server  70  to the electronic musical instrument  30 , and a processing corresponding to the request is executed in the electronic musical instrument  30  (A 30 ). In the processing of A 30 , the server  70  may perform a necessary processing in response to the request transmitted from the mobile terminal  50 , and transmit a result thereof to the communication device  1 . 
     As a specific example of the processings of A 29  and A 30 , a request (including a target parameter name and a set value after change) for instructing that a change be made to the parameter of the electronic musical instrument  30  is transmitted from the mobile terminal  50  to the server  70  (A 29 ). The server  70  transmits the received request to the communication device  1 . The communication device  1  transmits the request transmitted from the server  70  to the electronic musical instrument  30 . The electronic musical instrument  30  performs a processing (parameter setting) according to the received request (A 30 ). Other requests transmitted by the processing of A 29  include transmission of a parameter value of the electronic musical instrument  30  to the mobile terminal  50 . 
     As another specific example of the processings of A 29  and A 30 , the server  70  may perform a necessary processing in response to the request transmitted from the mobile terminal  50 , and transmit a result thereof to the communication device  1 . In this case, a request (including information for specifying a resource) for instructing that a list of predetermined resources stored on the server  70  be displayed is transmitted from the mobile terminal  50  to the server (A 29 ). In response to the request, the server  70  creates a list of applicable resources and transmits a request (including the created list) instructing that the list be displayed to the communication device  1 . The communication device  1  transmits the received request to the electronic musical instrument  30 , and the electronic musical instrument  30  displays the list on an LCD  36  (see  FIG.  9   ) to be described later (A 30 ). 
     As yet another specific example of the processings of A 29  and A 30 , the electronic musical instrument  30  may transmit a request to the server  70  in response to the request transmitted from the communication device  1 , and acquire a result of processing of the request in the server  70 . In this case, a request (including information for specifying a resource) for instructing that a resource utilized by the electronic musical instrument  30  be acquired from the server  70  is transmitted from the mobile terminal  50  to the server  70  (A 29 ). 
     The server  70  transmits the received request to the communication device  1 , and the communication device  1  transmits the transmitted instruction to the electronic musical instrument  30 . Based on the received instruction, the electronic musical instrument  30  transmits a request to the communication device  1  instructing that the specified resource be transmitted to the electronic musical instrument  30 . The communication device  1  transmits the request to the server  70 . The server  70  transmits the resource specified by the received request to the communication device  1 . The communication device  1  transmits the received resource to the electronic musical instrument  30 . The electronic musical instrument  30  utilizes the resource transmitted from the communication device  1  (A 30 ). 
     As yet another specific example of the processings of A 29  and A 30 , the mobile terminal  50  transmits to the server  70  a request for a list of resources of timbre data, wave data, and expansion sound source data sets stored in the server  70 . Afterwards, the requested list of resources is received and displayed on the LCD  56 . The list to be received includes, as respective resources, the timbre data (excluding the timbre data main body), the wave data (excluding the wave data main body), or the expansion sound source data sets (excluding the timbre data main body and the wave data main body) to be described later with reference to  FIG.  4 B  to  FIG.  4 D . The user H selects the desired timbre data, wave data, or expansion sound source data set from the displayed list of resources, and instructs loading, writing, or installation to be described later with reference to  FIG.  4 A . The mobile terminal  50  transmits a request of loading, writing, or installation to the server  70  (A 29 ). Based on the request, the server  70  performs loading, writing, or installation of all the timbre data and wave data included in the timbre data, the wave data, or the expansion sound source data set that is the instruction target (A 30 ). 
     As yet another specific example of the processings of A 29  and A 30 , the mobile terminal  50  may request an instruction, such as transmission of a remaining memory amount, execution of a virus check, and version upgrade of a mobile control program  52   a , for the electronic musical instrument  30  via the server  70 . In this case, the electronic musical instrument  30  needs to be capable of handling the instruction, and the following processing may be performed. First, although the device registration data transmitted/received by the processing of A 28  and registered in the owned device list  53   a  by the processing of T 24  is composed of the device identifier being an identifier uniquely set for each communication device  1  and the product information indicating the product name or the like of the communication device  1 , herein, the device identifier represents an identifier uniquely set for each electronic musical instrument  30 , and the product information represents the product name or the like of the electronic musical instrument  30 . For that purpose, the device registration data received by the server  70  in A 7  is also composed of an identifier uniquely set for each electronic musical instrument  30  and product information indicating the product name or the like of the electronic musical instrument  30 . Then, when the mobile terminal  50  displays a reception screen for an instruction from the user H, such as transmission of a remaining memory amount, execution of a virus check, and version upgrade of the mobile control program  52   a , a CPU  51  (mobile control program  52   a ) confirms the device identifier uniquely set for each electronic musical instrument  30  or the product information of the electronic musical instrument  30  in the device registration data registered in the owned device list  53   a . Further, the CPU  51  (mobile control program  52   a ) may display on the reception screen only the instructions that the electronic musical instrument  30  is capable of handling based on the device identifier or the product information. At that time, the device identifier or the product information may be associated with the instructions that can be handled and stored separately. 
     As described above, the instruction (request) from the mobile terminal  50  is transmitted from the server  70  to the communication device  1  and the electronic musical instrument  30 . The mobile terminal  50  is equipped with a display device having more abundant functions than the communication device  1  and the electronic musical instrument  30 . In this manner, for example, by transmitting information instructing the resource to be used by the electronic musical instrument  30  from the mobile terminal  50 , usability for the user H concerning resource utilization by the electronic musical instrument  30  can be improved. 
     In the processings of A 24  to A 28 , after the mobile terminal  50  logs in to the server  70 , the user identifier is requested from the server  70 , the requested user identifier is transmitted to the mobile terminal  50 , and the mobile terminal  50  transmits the transmitted user identifier to the server  70 , thereby acquiring the corresponding device registration data and the correspondence timbre information from the server  70 . However, the disclosure is not limited thereto. When the mobile terminal  50  has logged in to the server  70 , the user DB  72   b  may be searched for the user identifier of the logged-in user H, the device DB  72   c  may be searched for the device registration data and the correspondence timbre information corresponding to the searched user identifier, and the searched device registration data and the searched correspondence timbre information may be transmitted to the mobile terminal  50  together with the user identifier. In this case, the processings of A 25  and A 27  performed by the mobile terminal  50  and the processing of A 26  performed by the server  70  may be omitted. 
     Herein, specific examples of the processings of T 25 , A 29 , and A 30  will be described with reference to  FIG.  4 A  to  FIG.  7   .  FIG.  4 A  is a view illustrating an outline of loading, writing, and installation. In the present embodiment, loading, writing, and installation are provided as instructions from the mobile terminal  50  to the electronic musical instrument  30  for using the resources of the server  70 . 
     Loading is an instruction for acquiring a timbre data which is a type of the resources stored in the server  70  and setting as the timbre data to be actually (currently) used for sound production by the electronic musical instrument  30 . Writing is an instruction for acquiring a timbre data stored in the server  70  and storing to the electronic musical instrument  30  so that it can be used for sound production in the electronic musical instrument  30 . Installation is an instruction for acquiring a wave data which is a type of the resources stored in the server  70  and storing to the electronic musical instrument  30  so that it can be used for sound production in the electronic musical instrument  30 . 
     First, a configuration of the communication system S related to loading, writing, and installation will be described. The electronic musical instrument  30  is provided with a work memory  33   a , a timbre data memory  32   b , and a wave data memory  32   c . The work memory  33   a  stores the timbre data used in a current performance of the user H and the attribute information of the timbre data. The work memory  33   a  may store a plurality of timbre data and their attribute information, and among them, the timbre data with which the performance of the user H is directly reflected is referred to as “current”. The user H may select “current” by operating the electronic musical instrument  30 . The timbre data memory  32   b  stores a plurality of timbre data and their attribute information as candidates to be stored in the work memory  33   a  and used for sound production, and the wave data memory  32   c  stores a plurality of wave data and their attribute information. 
     Herein, the attribute information stored together with the timbre data in the work memory  33   a  or the like is configured with information associated with the timbre data and the wave data, such as the creator or acquirer of the timbre data and the wave data, the date/time of creation or acquisition of the timbre data and the wave data, etc. 
     The server  70  is provided with a timbre DB  72   d , an expansion sound source DB  72   d - 2 , management information  72   g , and the device DB  72   c  described above. The timbre DB  72   d  stores a plurality of timbre data (timbre data 1, timbre data 2, . . . ) and a plurality of wave data (wave data 1, wave data 2, . . . ). The expansion sound source DB  72   d - 2  stores a plurality of expansion sound source data sets (expansion sound source data set  100 , expansion sound source data set  200 , . . . ). The management information  72   g  stores information related to the use of the data on the server  70  for each user H, such as information about the timbre data, the wave data, or the expansion sound source data sets purchased by the user H, the subscription authority owned by the user H, etc. 
     The subscription authority indicates the contract type for the user H to use the service such as the timbre data on the server  70 , and is set to multiple levels of authority (specifically, “normal”, “core”, “professional”, and “ultimate”). By purchasing the subscription authority of a desired level, the user H can acquire and use the timbre data or the like that is permitted to be used at this level from the server  70 . In addition to the subscription authority, the user H may also purchase timbre data and wave data separately, and the purchased timbre data or the like may be permanently available regardless of the subscription authority. 
     Next, an outline of a processing of the communication system S in loading will be described. In the case where an instruction for loading to the electronic musical instrument  30  is sent from the mobile terminal  50  to the server  70 , the timbre DB  72   d  is searched for the timbre data instructed for loading. In the case where the timbre data is present in the timbre DB  72   d , it is confirmed whether the timbre data can be used by the user H of the mobile terminal  50 , that is, whether the timbre data has been purchased by the user H or whether the timbre data can be used with the subscription authority of the user H. 
     Then, in the case where it is determined that the timbre data can be used by the user H, the server  70  transmits the timbre data and an instruction for loading the timbre data to the electronic musical instrument  30 . Based on the received instruction, the electronic musical instrument  30  stores the timbre data received together with the instruction to the work memory  33   a . At the time of this storage, the user H may set whether to automatically select the received timbre data as “current”. Therefore, according to the instruction from the mobile terminal  50 , the timbre data that can be used by the user H and stored in the server  70  can be used in the current performance of the electronic musical instrument  30 . 
     In addition to storing the timbre data stored in the server  70  to the work memory  33   a  of the electronic musical instrument  30 , as shown in  FIG.  4 A , loading also includes storing the timbre data stored in the timbre data memory  32   b  to the work memory  33   a . The loading instruction for the electronic musical instrument  30  is not necessarily sent from the mobile terminal  50  via the server  70 , but the user H may also directly input the loading instruction to the electronic musical instrument  30 . 
     Next, an outline of a processing of the communication system S in writing will be described. In the case where an instruction for writing to the electronic musical instrument  30  is sent from the mobile terminal  50  to the server  70 , the timbre DB  72   d  is searched for the instructed timbre data in the same manner as in loading. In the case where the timbre data is present in the timbre DB  72   d , it is confirmed whether the timbre data can be used by the user H of the mobile terminal  50 , that is, whether the timbre data has been purchased by the user H or whether the timbre data can be used with the subscription authority of the user H. 
     Then, in the case where it is determined that the timbre data can be used by the user H, the server  70  transmits the timbre data and an instruction for writing the timbre data to the electronic musical instrument  30 . Based on the received instruction, the electronic musical instrument  30  stores the timbre data received together with the instruction to a predetermined area of the timbre data memory  32   b . Therefore, according to the instruction from the mobile terminal  50 , the timbre data that can be used by the user H and stored in the server  70  can be stored to the timbre data memory  32   b  of the electronic musical instrument  30 , and can be used in the performance of the electronic musical instrument  30  by a subsequent instruction of the user H for the electronic musical instrument  30  or the mobile terminal  50 . 
     In addition to storing the timbre data stored in the server  70  to the timbre data memory  32   b  of the electronic musical instrument  30 , as shown in  FIG.  4 A , writing also includes storing the timbre data stored in the work memory  33   a  to the timbre data memory  32   b  in response to an instruction for writing from the mobile terminal  50  described above. The instruction for writing to the electronic musical instrument  30  is not necessarily sent from the mobile terminal  50  via the server  70 , but the user H may also directly input the instruction for writing to the electronic musical instrument  30 . 
     Next, an outline of a processing of the communication system S in installation will be described. In the case where an instruction for installation to the electronic musical instrument  30  is sent from the mobile terminal  50  to the server  70 , the timbre DB  72   d  is searched for the instructed wave data. In the case where the wave data is present in the timbre DB  72   d , it is confirmed whether the wave data can be used by the user H of the mobile terminal  50 , that is, whether the wave data has been purchased by the user H or whether the wave data can be used with the subscription authority of the user H. 
     Then, in the case where it is determined that the wave data can be used by the user H, the server  70  transmits the wave data and an instruction for installing the wave data to the electronic musical instrument  30 . Based on the received instruction, the electronic musical instrument  30  stores the wave data received together with the instruction to a predetermined area of the wave data memory  32   c . The wave data stored in the wave data memory  32   c  will be appropriately used in performance according to an instruction of the user H for the electronic musical instrument  30 . Therefore, according to the instruction from the mobile terminal  50 , the wave data that can be used by the user H and is stored in the server  70  is stored to the wave data memory  32   c  of the electronic musical instrument  30 , and will be used in subsequent performance of the electronic musical instrument  30 . 
     The wave data to be used in a performance of the electronic musical instrument  30  is not necessarily set according to an instruction of the user H to the electronic musical instrument  30 , but may also be set according to an instruction to the electronic musical instrument  30  via the mobile terminal  50  and the server  70 . The above processing is repeated also in the case of writing or installation of the timbre data and the wave data included in an expansion sound source data set. 
     In the case where loading, writing, or installation is performed in the electronic musical instrument  30  in this manner, the contents of the work memory  33   a , the timbre data memory  32   b , and the wave data memory  32   c  are changed, and a processing is performed for the server  70  and the mobile terminal  50  to learn about the changed contents. 
     Specifically, the server  70  is provided with a load history  72   f  and sync data  72   e . The load history  72   f  stores a count of a timbre data being stored to the work memory  33   a  of the electronic musical instrument  30 . Specifically, a timbre data ID, which is an identifier for identifying a timbre data, and a load count, which is a count of the timbre data being stored to the work memory  33   a  and used for performance, are stored in association with each other for each user in the load history  72   f.    
     In the case where loading has been performed in the electronic musical instrument  30 , the timbre data ID of the loaded timbre data is transmitted to the server  70 . In the server  70 ,  1  is added to the load count of the timbre data ID in the load history  72   f  for the user H of the electronic musical instrument  30  from which the timbre data ID has been transmitted to update the load count. Accordingly, in the case where loading has been performed in the electronic musical instrument  30 , the load count is also reflected in the server  70 . 
     By confirming the load count of such a load history  72   f , in the server  70 , it is possible to learn about the preferred timbre data of the user H that were frequently loaded by the user H in the past. Further, by transmitting the load count of such a load history  72   f  to the mobile terminal  50 , and displaying the timbre data in a sequence of loading frequency, i.e., in a sequence of preference of the user H, on the mobile terminal  50 , the user H can preferentially load the preferred timbre data into the electronic musical instrument  30 . 
     On the other hand, by confirming the load count of the load history  72   f , in the server  70 , it is also possible to learn about the timbre data rarely loaded by the user H in the past. Such rarely loaded timbre data may not be recognized by the user H as timbre data that are available. Therefore, by displaying the rarely loaded timbre data on the mobile terminal  50 , it is possible to allow the user H to recognize that the timbre data are available and prompt the user H to use the timbre data. 
     The update of the load history  72   f  of the server  70  is not limited to when loading has been performed in the electronic musical instrument  30 . For example, the load history  72   f  may also be updated at regular time intervals (e.g., every 10 minutes) or when the power of the electronic musical instrument  30  is turned on. 
     Herein, in the case where the load history  72   f  of the server  70  is updated only when loading has been performed in the electronic musical instrument  30 , the processing of the electronic musical instrument  30  for the update (e.g., a communication processing with the server  70 ) may coincide with a processing related to the performance of the electronic musical instrument  30 , and the processing of the electronic musical instrument  30  may be delayed as a whole. As a result, the user H who is about to perform with the newly loaded timbre data has to wait. 
     In contrast, by setting the timing for updating the load history  72   f  at regular time intervals or to turn-on of the power of the electronic musical instrument  30 , it is possible to prevent the processing of the update from coinciding with the processing related to the performance of the electronic musical instrument  30 . Accordingly, the response of the electronic musical instrument  30  can be improved, so that the newly loaded timbre data can be quickly used for the performance of the user H, and further, the load count of the loaded timbre data can be appropriately reflected in the load history  72   f  of the server  70 . 
     The sync data  72   e  store information about the timbre data and the wave data stored in the timbre data memory  32   b  and the wave data memory  32   c  of the electronic musical instrument  30 . The sync data  72   e  store the timbre data ID and attribute information as well as the wave data ID and attribute information for each electronic musical instrument  30  and each user H of the electronic musical instrument  30 . 
     In the case where writing or installation has been performed in the electronic musical instrument  30 , the target timbre data ID and attribute information or the target wave data ID and attribute information stored in the timbre data memory  32   b  or the wave data memory  32   c  are transmitted to the server  70 . In the server  70 , the transmitted timbre data ID and its attribute information or the transmitted wave data ID and its attribute information are stored to an area in the sync data  72   e  corresponding to the electronic musical instrument  30  from which the timbre data ID or the wave data ID has been transmitted and the user H of the electronic musical instrument  30 . Accordingly, the information about the timbre data or the wave data written or installed in the electronic musical instrument  30  is also reflected in the server  70 . 
     With the sync data  72   e , in the server  70 , it is possible to learn about the timbre data and the wave data stored in the timbre data memory  32   b  and the wave data memory  32   c  of the electronic musical instrument  30 . Further, such sync data  72   e  are transmitted to the mobile terminal  50 . Then, when the timbre data or the wave data that may be written or installed are displayed on the mobile terminal  50  in the case where writing or installation is to be performed, among these data, the timbre data or the wave data determined according to the sync data  72   e  to have been written or installed may be displayed in gray or attached with a strikethrough to change the display mode. Accordingly, the user H is allowed to recognize that the timbre data or the wave data have been written or installed, and it is possible to prevent the timbre data or the wave data from being repeatedly written or installed. 
     When writing or installation has been performed, the ID and attribute information of the target timbre data or the like stored in the timbre data memory  32   b  or the wave data memory  32   c  are transmitted to the server  70 , but the disclosure is not limited thereto. For example, the timbre data ID and attribute information as well as the wave data ID and attribute information stored in the timbre data memory  32   b  and the wave data memory  32   c  may all be transmitted to the server  70  at regular time intervals (e.g., every 10 minutes), at the time of turn-on of the power of the electronic musical instrument  30 , or after the correspondence timbre information of the electronic musical instrument  30  has been transmitted from the communication device  1  to the server  70  (A 23 - 2 ). Accordingly, the timbre data ID and attribute information as well as the wave data ID and attribute information acquired by the electronic musical instrument  30  via a storage medium such as a USB memory can also be transmitted to the server  70  in the same manner as the timbre data and the wave data acquired from the server  70 . 
     Herein, in the case where the reflection to the sync data  72   e  of the server  70  is performed only when writing or installation has been performed in the electronic musical instrument  30 , the processing of the electronic musical instrument  30  for the reflection (e.g., a communication processing with the server  70 ) may coincide with a processing related to the performance of the electronic musical instrument  30 , and the processing of the electronic musical instrument  30  may be delayed as a whole. In contrast, by setting the timing of the reflection to the sync data  72   e  at regular time intervals, to the turn-on of the power of the electronic musical instrument  30 , or to after the correspondence timbre information of the electronic musical instrument  30  has been transmitted from the communication device  1  to the server  70  (A 23 - 2 ), it is possible to prevent the processing of the reflection from coinciding with the processing related to the performance of the electronic musical instrument  30 . Accordingly, the response of the electronic musical instrument  30  can be improved, and the written or installed loaded timbre data ID and attribute information or wave data ID and attribute information can be appropriately reflected in the sync data  72   e  of the server  70 . 
     Next, configurations of the timbre data, the wave data, and the expansion sound source data sets will be described with reference to  FIG.  4 B  to  FIG.  4 D .  FIG.  4 B  is a view showing each timbre data (timbre data 1, timbre data 2, timbre data 3).  FIG.  4 C  is a view showing each wave data (wave data 1, wave data 2, wave data 3).  FIG.  4 D  is a view showing each expansion sound source data set (expansion sound source data set  100 , expansion sound source data set  200 ). 
     In the timbre data of  FIG.  4 B , the timbre data ID represents an identifier of the timbre data, and the timbre attribute represents an attribute of the timbre data, such as “tone”, “rhythm”, and “natural”. The reference wave data ID represents an identifier of the wave data referred to by the timbre data. Further, the timbre data main body depends on the timbre attribute. In the wave data of  FIG.  4 C , the wave data ID represents an identifier of the wave data. Further, the wave data main body also depends on the timbre attribute of the timbre data that refers to the wave data. In the expansion sound source data set of  FIG.  4 D , the expansion sound source data set ID represents an identifier of the expansion sound source data set, the timbre attribute represents an attribute of the expansion sound source data set, and the reference wave data ID represents an identifier of the wave data referred to by the timbre data included in the expansion sound source data set. The contents of the wave data ID and below are the same as in  FIG.  4 B  and  FIG.  4 C . In the case where an expansion sound source data set, which is a type of resources stored in the server  70 , is acquired and transmitted to the electronic musical instrument  30 , all the timbre data included in the expansion sound source data set are written and all the wave data are installed. 
     Herein, in the processings of T 25 , A 29 , and A 30 , the mobile terminal  50  transmits to the server  70  a request for a list of resources of the timbre data, the wave data, and the expansion sound source data sets stored in the server  70 , receives the requested list of resources, displays the list on the LCD  56 , and the user H selects the desired timbre data, wave data, or expansion sound source data set from the displayed list of resources to instruct loading, writing, or installation. Another specific example of the above case will be described. 
     In the processings of A 28  and T 24 , the mobile terminal  50  receives the correspondence timbre information of the electronic musical instrument  30  and registers the correspondence timbre information in the owned device list  53   a  of  FIG.  10   . Further, the list received by the mobile terminal  50  from the server  70  includes the timbre data (excluding the timbre data main body), the wave data (excluding the wave data main body), or the expansion sound source data sets (excluding the timbre data main body and the wave data main body) as respective resources. Therefore, when the CPU  51  (mobile control program  52   a ) displays the list of resources received from the server  70  on the LCD  56 , by comparing the list with the correspondence timbre information of the electronic musical instrument  30 , it is possible to display only the timbre data and the expansion sound source data sets that can be handled by the electronic musical instrument  30  and not display the resources that cannot be handled. 
     That is, it is possible to display only the timbre data and the expansion sound source data sets included in the timbre attribute of the correspondence timbre information. As an example further defining the resources to be displayed, as for the timbre data, it is possible to display only the timbre data of which the reference wave data ID is included in the wave data ID of the correspondence timbre information; as for the expansion sound source data sets, it is possible to display only the expansion sound source data sets of which the expansion sound source data set ID is included in the expansion sound source data set ID of the correspondence timbre information. 
     Further, in place of not displaying the resources that cannot be handled, an image may be displayed, and a purchase guide or a sound production possible upon purchase may be noted together. 
     Next, communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  in loading, writing, and installation will be described with reference to  FIG.  5    to  FIG.  7   . First, the communication in loading will be described.  FIG.  5    is a view showing the communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  in loading. 
     In the loading, first, at the mobile terminal  50 , the user H is caused to select the timbre data to be loaded into the electronic musical instrument  30  (T 30 ). After the processing of T 30 , the mobile terminal  50  transmits the timbre data ID of the timbre data selected by the processing of T 30  and an instruction for loading the timbre data to the server  70  by communication using the MQTT protocol (A 40 ). 
     The server  70  that has received the MQTT data by the processing of A 40  acquires, from the timbre DB  72   d , the timbre data corresponding to the timbre data ID of the timbre data included in the received MQTT data (T 31 ). After the processing of T 31 , the server  70  transmits the instruction for loading the timbre data received by the processing of A 40  and the timbre data acquired by the processing of T 31  to the communication device  1  by communication using the MQTT protocol (A 42 ). 
     The communication device  1  that has received the instruction for loading the timbre data and the timbre data by the processing of A 42  transmits the instruction and the timbre data to the electronic musical instrument  30 , and then, in the electronic musical instrument  30 , the received timbre data is stored to the work memory  33   a  (T 32 ). Accordingly, the timbre data instructed from the mobile terminal  50  is loaded into the electronic musical instrument  30 . 
     In the following, the electronic musical instrument  30  is also communicated with the server  70  via the communication device  1 , but the reference to the communication device  1  will be omitted for the sake of brevity. Therefore, for example, “transmitting a data A from the electronic musical instrument  30  to the server  70 ” means that the data A is transmitted from the electronic musical instrument  30  to the communication device  1 , and the data A is transmitted from the communication device  1  to the server  70 . Similarly, “transmitting a data B from the server  70  to the electronic musical instrument  30 ” means that the data B is transmitted from the server  70  to the communication device  1 , and the data B is transmitted from the communication device  1  to the electronic musical instrument  30 . 
     After the processing of T 32 , the electronic musical instrument  30  transmits the timbre data ID of the timbre data loaded by the processing of T 32  to the server  70  by communication using the MQTT protocol (A 43 ). The server  70  that has received the timbre data ID of the timbre data loaded by the processing of A 43  adds 1 to the load count corresponding to the timbre data ID in the load history  72   f  for the user H of the electronic musical instrument  30  from which the timbre data ID has been transmitted (T 33 ). 
     As described above, in the loading of the communication system S, in the case where the timbre data ID of the timbre data and the instruction for loading the timbre data have been transmitted from the mobile terminal  50  to the server  70  by the processing of A 40 , the server  70  acquires the timbre data corresponding to the timbre data ID of the timbre data from the timbre DB  72   d , and transmits the timbre data together with the received instruction to the electronic musical instrument  30 . In the electronic musical instrument  30 , in response to the instruction received from the server  70 , the received timbre data is stored to the work memory  33   a . Accordingly, the data on the server  70  can be used in the electronic musical instrument  30  without connecting another storage medium to the electronic musical instrument  30 . 
     At this time, since the timbre data acquired in advance in the server  70  by the processing of T 31  is transmitted together with the instruction to the electronic musical instrument  30 , after receiving the instruction, the electronic musical instrument  30  does not need to request the timbre data from the server  70  again. Accordingly, the data on the server  70  can be quickly used by the electronic musical instrument  30 . 
     Further, the instruction for the electronic musical instrument  30  is transmitted from the mobile terminal  50 . Since the mobile terminal  50  is provided with more abundant input devices and display devices than the electronic musical instrument  30 , usability for using the timbre data on the server  70  in the electronic musical instrument  30  can be improved. 
     Further, the loading instruction from the mobile terminal  50  to the server  70  and the loading instruction from the server  70  to the electronic musical instrument  30  are sent by communication using the MQTT protocol. By performing communication using the MQTT protocol which is more lightweight than communication using the HTTPS protocol, these instructions can be communicated quickly. Accordingly, it is possible to reduce the time required from sending a loading instruction at the mobile terminal  50  until loading is actually completed at the electronic musical instrument  30 . 
     In the case where the timbre data ID of the timbre data and the instruction for loading the timbre data have been transmitted to the server  70  by the processing of A 40 , the server  70  acquires the timbre data corresponding to the timbre data ID of the timbre data from the timbre DB  72   d  (T 31 ) and transmits the timbre data together with the received instruction to the electronic musical instrument  30  (A 42 ), but the disclosure is not limited thereto. For example, the processing of T 31  of the server  70  may be omitted, the server  70  may directly transmit the timbre data ID and the loading instruction of the processing of A 40  to the electronic musical instrument  30 , and the electronic musical instrument  30  may request the server  70  for the corresponding timbre data. 
     Further, the processing of T 31  may be omitted in the server  70 , and instead, a URL may be created as a data request destination for acquiring the timbre data corresponding to the timbre data ID of the processing of A 40  from the timbre DB  72   d , and the URL and the loading instruction may be transmitted to the electronic musical instrument  30 . The electronic musical instrument  30  may transmit a request for timbre data based on the received URL to the server  70  by communication using the HTTPS protocol, and the timbre data corresponding to the request may be transmitted from the server  70  to the electronic musical instrument  30  by communication using the HTTPS protocol. At this time, the request for timbre data transmitted from the electronic musical instrument  30  may be transmitted including the HTTPS access authorization information received by the processing of A 21  in  FIG.  3 A . 
     Next, communication in writing will be described.  FIG.  6    is a view showing the communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  in writing. In the writing, first, at the mobile terminal  50 , the user H is caused to select the timbre data to be written to the electronic musical instrument  30  (T 40 ). After the processing of T 40 , the mobile terminal  50  transmits the timbre data ID of the timbre data selected by the processing of T 40  and an instruction for writing the timbre data to the server  70  by communication using the MQTT protocol (A 50 ). 
     The server  70  that has received the MQTT data by the processing of A 50  creates a URL for acquiring the timbre data corresponding to the timbre data ID of the timbre data included in the received MQTT data from the timbre DB  72   d  (T 41 ). After the processing of T 41 , the server  70  transmits the instruction for writing the timbre data received by the processing of A 50  and the URL acquired by the processing of T 41  to the electronic musical instrument  30  by communication using the MQTT protocol (A 51 ). 
     The electronic musical instrument  30  that has received the URL and the writing instruction by the processing of A 51  acquires the timbre data from the URL and writes the acquired timbre data (T 42 ). Specifically, the electronic musical instrument  30  transmits a request for timbre data based on the received URL to the server  70  by communication using the HTTPS protocol (A 52 ). At this time, the HTTPS access authorization information received by the processing of A 21  in  FIG.  3 A  is also transmitted. 
     The server  70  from which the timbre data has been requested by the processing of A 52  acquires the corresponding timbre data from the timbre DB  72   d , and transmits the acquired timbre data to the electronic musical instrument  30  by communication using the HTTPS protocol. The electronic musical instrument  30  stores the transmitted timbre data to the timbre data memory  32   b  (A 53 ). 
     In this manner, the transmission of the timbre data from the server  70  to the electronic musical instrument  30  in the processing of A 53  is performed by communication using the HTTPS protocol. Since communication using the HTTPS protocol can transmit a larger amount of data than communication using the MQTT protocol, the timbre data of various capacities stored in the server  70  can be directly acquired by the electronic musical instrument  30  from the server  70  to be used. Therefore, the time and effort to be spent by the user H when writing the timbre data to the electronic musical instrument  30  can be reduced, and the electronic musical instrument  30  can perform with rich expression. 
     Further, in addition to transmitting the URL created by the server  70  by the processings of T 41  and A 51  to the electronic musical instrument  30 , a request for timbre data of the server  70  is also sent from the electronic musical instrument  30  by the processings of A 52  and A 53 . That is, in the transmission of resources such as timbre data from the server  70  to the electronic musical instrument  30 , the resources may be directly transmitted from the server  70  to the electronic musical instrument  30  (A 23 , A 42 ), or the resources may be transmitted from the server  70  in response to a request from the electronic musical instrument  30  (A 52 , A 53 ). By appropriately using these means, resources can be flexibly transmitted from the server  70  to the electronic musical instrument  30 . 
     Along with the processings of A 52  and A 53  described above, a progress rate (0 to 100%) of the writing of the timbre data is transmitted from the electronic musical instrument  30  to the server  70  by communication using the MQTT protocol (A 54 ), and the progress rate is transmitted from the server  70  to the mobile terminal  50  (A 55 ). After the processing of A 55 , the mobile terminal  50  displays the received progress rate on the LCD  56  (see  FIG.  10   ) (T 44 ), so that the user H is notified of the estimated time required for the writing to be completed. 
     In the case where the writing by the processings of A 52  and A 53  is completed, the electronic musical instrument  30  transmits the timbre data ID and attribute information of the written timbre data and a sync instruction to the server  70  by communication using the HTTPS protocol (A 56 ). At this time, the HTTPS access authorization information received by the processing of A 21  in  FIG.  3 A  is also transmitted. 
     The server  70  that has received the sync instruction by the processing of A 56  stores the timbre data ID and the attribute information received together with the instruction to the sync data  72   e  (T 43 ). After the processing of T 43 , a notification that the storage to the sync data  72   e  is completed is transmitted to the electronic musical instrument  30  and the mobile terminal  50  by communication using the MQTT protocol (A 57 , A 58 ). 
     The mobile terminal  50  that has received the notification that the storage to the sync data  72   e  is completed by the processing of A 58  transmits a request to the server  70  for the sync data  72   e  by communication using the HTTPS protocol (A 59 ). At this time, the HTTPS access authorization information received by the processing of A 3  in  FIG.  2    is also transmitted. 
     The server  70  that has received the request for the sync data  72   e  by the processing of A 59  transmits the sync data  72   e  to the mobile terminal  50  by communication using the HTTPS protocol (A 60 ). The mobile terminal  50  that has received the sync data  72   e  by the processing of A 60  performs display on the LCD  56  based on the sync data  72   e  (T 45 ). 
     In the case where the timbre data ID of the timbre data and the instruction for writing the timbre data have been transmitted to the server  70  by the processing of A 50 , the server  70  creates a URL for acquiring the timbre data corresponding to the timbre data ID of the timbre data from the timbre DB  72   d  (T 41 ), and transmits the URL together with the received instruction to the electronic musical instrument  30  (A 51 ), but the disclosure is not limited thereto. For example, the server  70  may omit the processing of T 41 , acquire the timbre data corresponding to the timbre data ID of the processing of A 50  from the timbre DB  72   d , and transmit the timbre data together with the received instruction to the electronic musical instrument  30 . Further, the processing of T 41  may be omitted, and the server  70  may transmit the timbre data ID and the writing instruction of the processing of A 50  directly to the electronic musical instrument  30 , and the electronic musical instrument  30  may request the server  70  for the corresponding timbre data. 
     Next, communication in installation will be described.  FIG.  7    is a view showing the communication performed by the communication device  1 , the electronic musical instrument  30 , the mobile terminal  50 , and the server  70  in installation. In the installation, first, at the mobile terminal  50 , the user H is caused to select the wave data to be installed to the electronic musical instrument  30  (T 50 ). 
     After the processing of T 50 , the mobile terminal  50  transmits to the server  70  a request for confirming whether the wave data selected by the processing of T 50  can be installed by communication using the MQTT protocol (A 70 ), and the server  70  transmits the received request to the electronic musical instrument  30  by communication using the MQTT protocol (A 71 ). At this time, a size of the wave data to be installed is also transmitted. 
     The electronic musical instrument  30  that has received the request for confirming whether installation is possible by the processing of A 71  confirms a free space of the wave data memory  32   c , and confirms whether the wave data of the transmitted size can be installed (T 51 ). After the processing of T 51 , the result of the processing of T 51  is transmitted to the server  70  by communication using the MQTT protocol (A 72 ), and the server  70  transmits the received result to the mobile terminal  50  by communication using the MQTT protocol (A 73 ). 
     After the processing of A 73 , if the result received by the processing of A 73  is “installable”, the mobile terminal  50  transmits a request for creating a URL of the wave data specified by the user H to the server  70  by communication using the HTTPS protocol (A 74 ). At this time, the HTTPS access authorization information received by the processing of A 3  in  FIG.  2    is also transmitted. The server  70  that has been requested to create a URL of the wave data by the processing of A 74  creates a URL for acquiring the corresponding wave data from the timbre DB  72   d , and transmits the created URL to the mobile terminal  50  by communication using the HTTPS protocol (A 75 ). 
     After the processing of A 75 , the mobile terminal  50  transmits the received URL and an installation instruction to the server  70  by communication using the MQTT protocol (A 76 ), and the server  70  transmits the received URL and the installation instruction to the electronic musical instrument  30  by communication using the MQTT protocol (A 77 ). 
     The electronic musical instrument  30  that has received the URL and the installation instruction by the processing of A 77  acquires the wave data from the URL and installs the acquired wave data (T 52 ). Specifically, the electronic musical instrument  30  transmits a request for wave data based on the received URL to the server  70  by communication using the HTTPS protocol (A 78 ). At this time, the HTTPS access authorization information received by the processing of A 21  in  FIG.  3 A  is also transmitted. 
     The server  70  that has been requested for the wave data by the processing of A 78 , acquires the corresponding wave data from the timbre DB  72   d , and transmits the acquired wave data to the electronic musical instrument  30  by communication using the HTTPS protocol. The electronic musical instrument  30  stores the transmitted wave data to the wave data memory  32   c  (A 79 ). 
     Along with the processings of A 78  and A 79 , a progress rate (0 to 100%) of the installation of the wave data is transmitted from the electronic musical instrument  30  to the server  70  by communication using the MQTT protocol (A 80 ), and the progress rate is transmitted from the server  70  to the mobile terminal  50  (A 81 ). After the processing of A 81 , the mobile terminal  50  displays the received progress rate on the LCD  56  (T 53 ), so that the user H is notified of the estimated time required for the installation to be completed. 
     In the case where the installation by the processings of A 78  and A 79  is completed, the electronic musical instrument  30  transmits the wave data ID and attribute information of the installed wave data and a sync instruction to the server  70  by communication using the HTTPS protocol (A 82 ). At this time, the HTTPS access authorization information received by the processing of A 21  in  FIG.  3 A  is also transmitted. 
     The server  70  that has received the sync instruction by the processing of A 82  stores the wave data ID and the attribute information received together with the instruction to the sync data  72   e  (T 54 ). After the processing of T 54 , a notification that the storage to the sync data  72   e  is completed is transmitted to the electronic musical instrument  30  and the mobile terminal  50  by communication using the MQTT protocol (A 83 , A 84 ). 
     The mobile terminal  50  that has received the notification that the storage to the sync data  72   e  is completed by the processing of A 84  transmits a request for the sync data  72   e  to the server  70  by communication using the HTTPS protocol (A 85 ). The server  70  that has received the request for the sync data  72   e  by the processing of A 85  transmits the sync data  72   e  to the mobile terminal  50  by communication using the HTTPS protocol (A 86 ). At this time, the HTTPS access authorization information received by the processing of A 3  in  FIG.  2    is also transmitted. The mobile terminal  50  that has received the sync data  72   e  by the processing of A 86  performs display on the LCD  56  based on the sync data  72   e  (T 55 ). 
     In the processing of A 74 , the mobile terminal  50  transmits a request for creating a URL of the wave data specified by the user H to the server  70  by communication using the HTTPS protocol. However, instead of this, the mobile terminal  50  may also transmit the wave data ID of the specified wave data and an instruction for installing the wave data to the server  70  by communication using the MQTT protocol. 
     Next, functions of the server  70  will be described with reference to  FIG.  8   .  FIG.  8    is a functional block diagram of the server  70 . As shown in  FIG.  8   , the server  70  includes a data storage means  300 , an instruction receiving means  301 , an information creating means  302 , and an instruction transmitting means  303 . 
     The data storage means  300  is a means for storing data used for sound reproduction in the electronic musical instrument  30 , and is realized by a hard disk drive (HDD)  72  to described later with reference to  FIG.  10   . The instruction receiving means  301  is a means for receiving an instruction from the mobile terminal  50  to the electronic musical instrument  30  to instruct the electronic musical instrument  30  to receive and store data of the data storage means  300 , and the instruction receiving means  301  is realized by a CPU  71  to be described later with reference to  FIG.  10   . The information creating means  302  is a means for creating a data or a data request destination for a target data of the instruction received by the instruction receiving means  301 , and the information creating means  302  is realized by the CPU  71 . The instruction transmitting means  303  is a means for transmitting, to the electronic musical instrument  30 , the data or the data request destination and an instruction for receiving and storing the target data of the instruction received by the instruction receiving means  301 , and the instruction transmitting means  303  is realized by the CPU  71 . 
     The server  70  receives an instruction for data use sent from the mobile terminal  50  to the electronic musical instrument  30 , and transmits the instruction and information related to the data of the data storage means  300  to be used by the instruction to the electronic musical instrument  30 . Accordingly, by executing a processing according to the instruction received from the server  70  in the electronic musical instrument  30 , the data on the server  70  can be used by the electronic musical instrument  30  without connecting another storage medium to the electronic musical instrument  30 . 
     Further, together with the instruction received from the mobile terminal  50 , information related to the data to be used by the instruction is transmitted from the server  70  to the electronic musical instrument  30 . For example, after receiving the instruction, the electronic musical instrument  30  does not need to transmit a request to the server  70  for information related to the data to be used by the instruction. Therefore, the data on the server  70  can be quickly used by the electronic musical instrument  30 . 
     Further, since the instruction for the electronic musical instrument  30  is transmitted from the mobile terminal  50 , with the mobile terminal  50  being equipped with more abundant input devices and display devices than the electronic musical instrument  30 , usability for using the data on the server  70  by the electronic musical instrument  30  can be improved. 
     Next, an electrical configuration of the communication system S will be described with reference to  FIG.  9    to  FIG.  11 D . First, electrical configurations of the communication device  1  and the electronic musical instrument  30  will be described with reference to  FIG.  9   .  FIG.  9    is a block diagram showing electrical configurations of the communication device  1  and the electronic musical instrument  30  in the communication system S. The communication device  1  includes a CPU  10 , a flash ROM  11 , and a RAM  12  each of which is connected to an input/output (I/O) port  14  via a bus line  13 . The operation button  2 , the LED  3 , the Wi-Fi communication part  4 , and the BT communication part  5  described above and an external IF  15  are further connected to the I/O port  14 . 
     The CPU  10  is an arithmetic unit that controls each part connected by the bus line  13 . The flash ROM  11  is a rewritable non-volatile storage device storing programs executed by the CPU  10 , fixed value data, etc., and includes a control program  11   a , a device identifier  11   b  in which the device identifier of the communication device  1  is stored, product information  11   c  in which product information of the communication device  1  is stored, AP information  11   d  in which the information about the selected AP  90  acquired from the mobile terminal  50  is stored, and an AP password  11   e  in which the input PSW of the selected AP  90  is stored. When the control program  11   a  is executed by the CPU  10 , a communication device main processing of  FIG.  12 A  is executed. The RAM  12  is a memory rewritably storing various work data, flags, etc. when the CPU  10  executes a program. 
     The external IF  15  is a device for connecting to an external device, and is connected to an external IF  37  of the electronic musical instrument  30  to be described later. In the present embodiment, the external IF  15  is composed of a device based on USB standards. However, the external IF  15  may also be a device based on a communication standard other than USB. Communication between the communication device  1  and the electronic musical instrument  30  is performed via the external IF  15  and the external IF  37 . 
     The Wi-Fi communication part  4  and the BT communication part  5  are connected to a duplexer  16 . The duplexer  16  is a device that integrates radio waves transmitted and received by the Wi-Fi communication part  4  with radio waves transmitted and received by the BT communication part  5 . An antenna  17  is connected to the duplexer  16 . The radio waves transmitted by the Wi-Fi communication part  4  and the radio waves transmitted by the BT communication part  5  are integrated and transmitted from the antenna  17 . The radio waves received by the antenna  17  are appropriately distributed to the Wi-Fi communication part  4  and the BT communication part  5 . By connecting the Wi-Fi communication part  4  and the BT communication part  5  to the duplexer  16 , transmission and reception of the radio waves of these two communication parts can be realized by one antenna  17 . The duplexer  16  may be omitted, and an antenna may be provided in each of the Wi-Fi communication part  4  and the BT communication part  5 . 
     Next, an electrical configuration of the electronic musical instrument  30  will be described. The electronic musical instrument  30  includes a CPU  31 , a flash ROM  32 , a RAM  33 , a keyboard  34  acquiring performance information according to a performance of the user H, a setting key  35  for the user H to input various settings, the LCD  36  displaying a setting state of the electronic musical instrument  30  or the like, the external IF  37 , a sound source  38 , and a digital signal processor  39  (hereinafter referred to as “DSP  39 ”) each of which is connected via a bus line  40 . 
     The CPU  31  is an arithmetic unit that controls each part connected by the bus line  40 . The flash ROM  32  is a rewritable non-volatile storage device storing programs executed by the CPU  31 , fixed value data, etc., and includes a control program  32   a , the above timbre data memory  32   b  and the wave data memory  32   c , and a correspondence timbre information memory  32   d . When the control program  32   a  is executed by the CPU  31 , an electronic musical instrument workflow processing of  FIG.  19    is executed. The RAM  33  is a memory for rewritably storing various work data, flags, etc. when the CPU  31  executes a program, and includes the above work memory  33   a.    
     The correspondence timbre information memory  32   d  stores timbre information that can be handled by the electronic musical instrument  30 . The timbre information that can be handled includes a timbre attribute and an expansion sound source data set ID. The timbre attribute represents an attribute of a timbre data that can be used by the electronic musical instrument  30 , and includes, for example, “tone”, “rhythm”, and “natural”. The expansion sound source data set ID is an identifier of an expansion sound source data set that can be expanded by the electronic musical instrument  30 . When transmitting the correspondence timbre information of the electronic musical instrument  30  from the communication device  1  to the server  70  in response to the instruction from the electronic musical instrument  30  in the processing of A 23 - 2 , the timbre attribute and the expansion sound source data set ID stored in the correspondence timbre information memory  32   d , and the wave data ID being an identifier of the wave data stored in the wave data memory  32   c  are transmitted. 
     The external IF  37  is a device for connecting to an external device, and is mainly connected to the external IF  15  of the communication device  1  described above. In the present embodiment, like the external IF  15 , the external IF  37  is configured by a device based on a USB standard. However, the external IF  37  may also be a device based on a communication standard other than USB as long as it is of the same communication standard as the external IF  15 . 
     The sound source  38  is a device that outputs waveform data based on the timbre data of the current of the work memory  33   a  and the wave data of the wave data memory  32   c  according to the performance information inputted from the keyboard  34 . The DSP  39  is an arithmetic unit for arithmetically processing the waveform data inputted from the sound source  38 . The sound source  38  and a digital-to-analog converter (DAC)  41  are connected to the DSP  39 , an amplifier  42  is connected to the DAC  41 , and a speaker  43  is connected to the amplifier  42 . 
     Next, electrical configurations of the mobile terminal  50  and the server  70  in the communication system S will be described with reference to  FIG.  10    to  FIG.  11 D .  FIG.  10    is a block diagram showing the electrical configurations of the mobile terminal  50  and the server  70  in the communication system S. 
     The mobile terminal  50  includes a CPU  51 , a flash ROM  52 , and a RAM  53  each of which is connected to an I/O port  55  via a bus line  54 . The BT communication part  60  and the base communication part  61  described above, an LCD  56  displaying a setting state of the mobile terminal  50  or the like, and a touch panel  57  to which an instruction from the user H is inputted are further connected to the I/O port  55 . 
     The CPU  51  is an arithmetic unit that controls each part connected by the bus line  54 . The flash ROM  52  is a rewritable non-volatile storage device storing programs executed by the CPU  51 , fixed value data, etc., in which a mobile control program  52   a  is stored. When the mobile control program  52   a  is executed by the CPU  51 , a mobile terminal main processing of  FIG.  12 B  is executed. The RAM  53  is a memory for rewritably storing various work data, flags, etc. when the CPU  51  executes a program, and the owned device list  53   a  stores the device registration data and the correspondence timbre information registered by the processing of T 24 . 
     The server  70  includes the CPU  71 , the HDD  72 , and a RAM  73  each of which is connected to an I/O port  75  via a bus line  74 . A communication part  76  that communicates with the Internet N is further connected to the I/O port  75 . 
     The CPU  71  is an arithmetic unit that controls each part connected by the bus line  74 . The HDD  72  is a rewritable non-volatile storage device storing programs executed by the CPU  71 , fixed value data, etc., and includes a server control program  72   a , the user DB  72   b , the device DB  72   c , the above timbre DB  72   d , the expansion sound source DB  72   d - 2 , the sync data  72   e , the load history  72   f , and the management information  72   g . When the server control program  72   a  is executed by the CPU  71 , a server main processing of  FIG.  12 C  is executed. 
     The user DB  72   b  stores login-related information and the user identifier of the user H who has been registered. The device DB  72   c  stores the device identifier and the product information of the communication device  1 , the user identifier of the user H who utilizes the communication device  1  (electronic musical instrument  30 ), and the correspondence timbre information. The user DB  72   b , the device DB  72   c , the sync data  72   e , and the load history  72   f  will be described with reference to  FIG.  11 A  to  FIG.  11 D . 
       FIG.  11 A  schematically illustrates the user DB  72   b . As shown in  FIG.  11 A , the user DB  72   b  stores an account (e-mail address) and a password being the login-related information of the user H who has been registered in association with the user identifier created when the user H is registered. The account stored in the user DB  72   b  is not limited to an e-mail address, but may also be a name of the user H or a uniquely set arbitrary character string. 
       FIG.  11 B  schematically illustrates the device DB  72   c . As shown in  FIG.  11 B , the device DB  72   c  stores the device identifier and product information of the communication device  1  that has been registered, the user identifier of the user H who utilizes the communication device  1  (electronic musical instrument  30 ), and the correspondence timbre information in association with each other. Among them, the device identifier is registered in the device DB  72   c  at the time of factory shipment of the communication device  1 , and the product information and the user identifier are registered in the device DB  72   c  in the setup mode described above. Further, the correspondence timbre information is registered in the processing of T 20 - 2 . 
       FIG.  11 C  is a view schematically showing the sync data  72   e . As shown in  FIG.  11 C , the sync data  72   e  stores the timbre data ID or the wave data ID in association with the attribute information for each user identifier and device identifier. Further,  FIG.  11 D  is a view schematically showing the load history  72   f . As shown in  FIG.  11 D , the load history  72   f  stores the timbre data ID and the load count in association with each other for each user identifier. 
     Returning to  FIG.  10   , the RAM  73  is a memory for rewritably storing various work data, flags, etc. when a program is executed by the CPU  71 . 
     The server  70  performs two types of communication, namely, the communication using the HTTPS protocol and the communication using the MQTT protocol, with the communication device  1  and the mobile terminal  50 . Specifically, in the communication using the MQTT protocol, the communication with the communication device  1  and the mobile terminal  50  is performed by exchanging a “topic” being a character string including a user identifier and a device identifier of a target to and from which a data is to be transmitted and received. Examples of the “topic” include “topic/{user identifier}/{device identifier}/# (#: any command such as data request)”. 
     A “subscribe” function is provided for the communication using the MQTT protocol. In the “subscribe” function, by registering (hereinafter referred to as “subscription registration”) the user identifier and device identifier for each communication device  1  and mobile terminal  50  with the server  70  in advance, when a topic is transmitted to the server  70 , the server  70  transmits the topic to the communication device  1  and the mobile terminal  50  that correspond to the user identifier and the device identifier of the topic among multiple communication devices  1  and mobile terminals  50 . 
     Accordingly, in the subscription registration of each of the communication device  1  (electronic musical instrument  30 ) and the mobile terminal  50  used by the user H with respect to the server  70 , by registering the device identifier of the communication device  1  and the user identifier of the user H, a result obtained by transmitting the topic from the communication device  1  to the server  70  is transmitted to the communication device  1  and also to the mobile terminal  50 , and a result obtained by transmitting the topic from the mobile terminal  50  to the server  70  is transmitted to the mobile terminal  50  and also to the communication device  1 . By doing so, the communication device  1  and the mobile terminal  50  become able to exchange necessary information via the server  70 . 
     In the subscription registration of the communication device  1 , a character string indicating “for the communication device  1 ” may be registered in addition to the user identifier and the device identifier. In the subscription registration of the mobile terminal  50 , a character string indicating “for the mobile terminal  50 ” may be registered in addition to the user identifier and so on. If registration is performed without addition of these character strings, in the case where a certain topic is processed by the server  70 , a processing result is transmitted as well, and the topic transmitted by each of the communication device  1  and the mobile terminal  50  is transmitted (returned) to both of them. Therefore, even if a processing result according to the topic only needs to be transmitted to one of the communication device  1  and the mobile terminal  50 , the processing result will always be transmitted to the other of them as well. In order to avoid this, in the subscription registration of the communication device  1 , the character string indicating “for the communication device  1 ” is registered in addition to the user identifier and so on. In the subscription registration of the mobile terminal  50 , the character string indicating “for the mobile terminal  50 ” is registered in addition to the user identifier and so on. 
     Then, the communication device  1  transmits a topic including the character string indicating “for the communication device  1 ”, and the mobile terminal  50  transmits a topic including the character string indicating “for the mobile terminal  50 ”. Further, the server  70  transmits a topic including the character string “for the communication device  1 ” in a processing result with respect to the topic including the character string indicating “for the communication device  1 ”. On the other hand, the server  70  transmits a topic including the character string “for the mobile terminal  50 ” in a processing result with respect to the topic including the character string indicating “for the mobile terminal  50 ”. By doing so, the communication device  1  and the mobile terminal  50  are able to receive only a topic directed to themselves and a processing result according to the topic. 
     On the contrary, when instructing transmission of a processing result according to a topic for the mobile terminal  50  from the communication device  1 , the communication device  1  may transmit a topic including a character string indicating “for the mobile terminal  50 ”. When instructing transmission of a processing result according to a topic for the communication device  1  from the mobile terminal  50 , the mobile terminal  50  may transmit a topic including a character string indicating “for the communication device  1 ”. 
     Next, processings executed by the CPU  10  of the communication device  1 , the CPU  51  of the mobile terminal  50 , the CPU  71  of the server  70 , and the CPU  31  of the electronic musical instrument  30  will be described with reference to  FIG.  12 A  to  FIG.  30   . First, main processings of the communication device  1 , the mobile terminal  50 , and the server  70  will be described with reference to  FIG.  12 A  to  FIG.  12 C .  FIG.  12 A  is a flowchart of a communication device main processing,  FIG.  12 B  is a flowchart of a mobile terminal main processing, and  FIG.  12 C  is a flowchart of a server main processing. 
     The communication device main processing is a processing executed in the case where power of the communication device  1  is turned on. As shown in  FIG.  12 A , in the communication device main processing, first, it is confirmed whether an instruction for the setup mode has been given by a long pressing operation on the operation button  2  (S 1 ). In the processing of S 1 , if there is an instruction for the setup mode (S 1 : Yes), a BT communication part setup processing (S 2 ) is executed; if there is no instruction for the setup mode (S 1 : No), the BT communication part setup processing (S 2 ) is skipped. A Wi-Fi main processing (S 3 ) is executed in parallel with the processings of S 1  and S 2 . In the BT communication part setup processing, a processing concerning the BT communication part  5  in the setup mode is performed, and details thereof will be described later with reference to  FIG.  13   . 
     In the Wi-Fi main processing, a processing (specifically, a Wi-Fi setup processing to be described later with reference to  FIG.  15   ) concerning the Wi-Fi communication part  4  in the setup mode and a processing (specifically, a Wi-Fi communication part workflow processing to be described later with reference to  FIG.  18   ) concerning the Wi-Fi communication part  4  after the setup mode are performed. Details thereof will be described later. 
     After the processings of S 1  to S 3 , other processings (S 4 ) concerning the communication device  1  are executed, and after that, the processings of S 1  to S 3  onwards are repeated. The processings of S 1  and S 2  and the processing of S 3  are not necessarily executed in parallel. The processing of S 3  may be executed after the processings of S 1  and S 2 , or the processings of S 1  and S 2  may be executed after the processing of S 3 . 
     The mobile terminal main processing is a processing executed in the case where an application program for the communication system S is launched on the mobile terminal  50 . As shown in  FIG.  12 B , in the mobile terminal main processing, first, it is confirmed whether there is an instruction for the setup mode via the touch panel  57  (S 10 ). In the processing of S 10 , if there is an instruction for the setup mode (S 10 : Yes), a mobile terminal setup processing (S 11 ) is executed; if there is no instruction for the setup mode (S 10 : No), a mobile terminal workflow processing (S 12 ) is executed. 
     The mobile terminal setup processing of S 11  is a processing in the setup mode of the mobile terminal  50 , and details thereof will be described later with reference to  FIG.  16   . The mobile terminal workflow processing of S 12  is a processing of the mobile terminal  50  after the setup mode, and details thereof will be described later with reference to  FIG.  20   . After the processings of S 11  and S 12 , other processings (S 13 ) concerning the mobile terminal  50  are executed, and after that, the processing of S 10  onwards is repeated. 
     The server main processing is a processing executed in the case where power of the server  70  is turned on. As shown in  FIG.  12 C , in the server main processing, first, a server setup processing (S 20 ), an HTTPS workflow processing (S 21 ), and an MQTT workflow processing (S 22 ) are executed in parallel. 
     The server setup processing of S 20  is a processing in the setup mode of the server  70 , and details thereof will be described later with reference to  FIG.  17   . The HTTPS workflow processing of S 21  is a processing concerning HTTPS protocol communication of the server  70  after the setup mode, and details thereof will be described later with reference to  FIG.  21   . The MQTT workflow processing of S 22  is a processing concerning MQTT protocol communication of the server  70  after the setup mode, and details thereof will be described later with reference to  FIG.  22   . After the processings of S 20  to S 22 , other processings (S 23 ) concerning the server  70  are executed, and after that, the processings of S 20  to S 22  onwards are repeated. 
     The three processings of S 20  to S 22  are not necessarily executed in parallel. For example, the processing of S 20 , the processing of S 21 , and the processing of S 22  may be executed one by one in this order. Two of the processings of S 20  to S 22  may be executed in parallel, followed by the remaining processing; for example, the processing of S 20  and the processing of S 21  are executed in parallel, followed by the processing of S 22 . Alternatively, one of the processings of S 20  to S 22  may be executed, followed by the remaining processings in parallel; for example, the processing of S 21  and the processing of S 22  are executed in parallel after the processing of S 20 . 
     First, a processing of the setup mode of the communication device  1  will be described.  FIG.  13    is a flowchart of the BT communication part setup processing (S 2 ). In the BT communication part setup processing, first, the BT communication part  5  is set to a standby state (S 30 ). After the processing of S 30 , it is confirmed whether pairing with the mobile terminal  50  has been established (S 31 ). In the processing of S 31 , if the pairing has not been established (S 31 : No), the processing of S 30  onwards is repeated. 
     In the processing of S 31 , if the pairing with the mobile terminal  50  has been established (S 31 : Yes), it is confirmed whether a request for the device registration data from the mobile terminal  50  has been received by the BT communication part  5  (S 32 ). In the processing of S 32 , if the request for the device registration data has been received (S 32 : Yes), the device registration data of the communication device  1 , that is, the device identifier of the device identifier  11   b  and the product information of the product information  11   c , are transmitted to the mobile terminal  50  by the BT communication part  5  (S 33 ). After the processing of S 33 , the processing of S 32  onwards is repeated. 
     In the processing of S 32 , if no request for the device registration data has been received (S 32 : No), it is confirmed whether a request for the list of APs  90  has been received from the mobile terminal  50  by the BT communication part  5  (S 34 ). In the processing of S 34 , if the request for the list of APs  90  has been received (S 34 : Yes), standby is performed until the list of APs  90  is created by the processing of S 51  of the Wi-Fi communication part setup processing (see  FIG.  15   ) to be described later (S 35 ). After the processing of S 35 , the created list of APs  90  is transmitted to the mobile terminal  50  from the BT communication part  5  (S 36 ). After the processing of S 36 , the processing of S 32  onwards is repeated. 
     In the processing of S 34 , if no request for the list of APs  90  has been received (S 34 : No), it is confirmed whether the information (AP information) about the AP  90  selected by the user H and the input PSW (AP password) of the AP  90  have been received from the mobile terminal  50  (S 37 ). In the processing of S 37 , if the information about the AP  90  and the input PSW have been received (S 37 : Yes), the received information about the AP  90  and the received input PSW are acquired (S 38 ). 
     The information about the AP  90  and the input PSW acquired by the processing of S 38  are respectively stored in the AP information  11   d  and the AP password  11   e . The information about the AP  90  and the input PSW stored in the AP information  11   d  and the AP password  11   e  will be used in the connection to the AP  90  after the setup mode. 
     In the processing of S 37 , if the information about the AP  90  and the input PSW have not been received (S 37 : No), the processing of S 32  onwards is repeated. After the processing of S 38 , the BT communication part setup processing is ended. The end of the BT communication part setup processing after the processing of S 38  may be on standby until the connection of the Wi-Fi communication part  4  to the AP  90  succeeds in the processings of S 54  and S 55  to be described later. 
     After the processing of S 38 , the communication device  1  may notify the electronic musical instrument  30  that the information about the AP  90  and the input PSW have been acquired. Upon receiving the notification, the electronic musical instrument  30  may restart the communication device  1 . The restarted communication device  1  may connect to the AP  90  based on the information about the AP  90  and the input PSW stored in the AP information  11   d  and the AP password  11   e , and may execute the processings after the setup mode. 
       FIG.  14    is a flowchart of the Wi-Fi main processing (S 3 ). In the Wi-Fi main processing, first, it is confirmed whether the operation button  2  of the communication device  1  has been pressed and held and there is an instruction for the setup mode (S 40 ). In the processing of S 40 , if there is an instruction for the setup mode (S 40 : Yes), the Wi-Fi communication part setup processing (S 41 ) is executed. Herein, the Wi-Fi communication part setup processing will be described with reference to  FIG.  15   . 
       FIG.  15    is a flowchart of the Wi-Fi communication part setup processing (S 41 ). In the Wi-Fi communication part setup processing, first, it is confirmed whether the request for the list of APs  90  has been received from the mobile terminal  50  by the BT communication part  5  (S 50 ). In the processing of S 50 , if the request for the list of APs  90  has been received (S 50 : Yes), a search is performed for the APs  90  that can be connected by the Wi-Fi communication part  4  and a list of the searched APs  90  is created (S 51 ). After the processing of S 51 , the processing of S 50  onwards is repeated. 
     In the processing of S 50 , if no request for the list of APs  90  has been received (S 50 : No), it is confirmed whether the information (AP information) about the AP  90  selected by the user H and the input PSW (AP password) of the AP  90  have been received from the mobile terminal  50  by the BT communication part  5  (S 52 ). In the processing of S 52 , if the information about the AP  90  and the input PSW have been received (S 52 : Yes), the AP  90  corresponding to the received information about the AP  90  is connected by the Wi-Fi communication part  4  by using the received input PSW (S 53 ). In the processing of S 52 , if the information about the AP  90  and the input PSW have not been received (S 52 : No), the processing of S 50  onwards is repeated. 
     After the processing of S 53 , it is confirmed whether the connection to the AP  90  by the Wi-Fi communication part  4  has succeeded (S 54 ). In the processing of S 54 , if the connection to the AP  90  has succeeded (S 54 : Yes), the fact (“connection successful”) that the connection has succeeded is transmitted from the BT communication part  5  to the mobile terminal  50  (S 55 ). 
     On the other hand, in the processing of S 54 , if the connection to the AP  90  has failed (S 54 : No), the fact (connection error) that the connection has failed is transmitted from the BT communication part  5  to the mobile terminal  50  (S 56 ). After the processing of S 56 , the processing of S 50  onwards is repeated. After the processing of S 55 , the Wi-Fi communication part setup processing is ended. 
     Next, a processing of the setup mode of the mobile terminal  50  will be described.  FIG.  16    is a flowchart of the mobile terminal setup processing (S 11 ). In the mobile terminal setup processing, first, it is confirmed whether user registration of the user H with the server  70  has been completed (S 60 ). In the processing of S 60 , if the user registration of the user H with the server  70  has not been completed (S 60 : No), the user registration of the user H is performed by transmitting the account (i.e., e-mail address) and password of the user H to the server  70  (S 61 ). After the processing of S 61 , the processing of S 60  onwards is repeated. 
     In the processing of S 60 , if the user registration of the user H with the server  70  has been completed (S 60 : Yes), login to the server  70  is performed by transmitting the account and password of the user H to the server  70  by communication using the HTTPS protocol (S 62 ). After the processing of S 62 , it is confirmed whether a response to the login received from the server  70  by communication using the HTTPS protocol is “OK” (S 63 ). 
     In the processing of S 63 , if the response to the login is not “OK” (S 63 : No), display (error display) indicating that the login has failed is performed on the LCD  56  (S 64 ). After the processing of S 64 , the processing of S 62  onwards is repeated. 
     In the processing of S 63 , if the response to the login is “OK” (S 63 : Yes), the HTTPS access authorization information is received from the server  70 . Then, pairing with the communication device  1  is performed by searching for the communication device  1  by the BT communication part  60  (S 65 ). After the processing of S 65 , it is confirmed whether pairing with the communication device  1  has been established (S 66 ). In the processing of S 66 , if the pairing has not been established (S 66 : No), the processing of S 65  onwards is repeated. 
     In the processing of S 66 , if the pairing has been established (S 66 : Yes), the device registration data is requested from the communication device  1  by the BT communication part  60  (S 67 ). After the processing of S 67 , it is confirmed whether the device registration data has been received from the communication device  1  by the BT communication part  60  (S 68 ). In the processing of S 68 , if the device registration data has not been received (S 68 : No), the processing of S 68  is repeated. 
     In the processing of S 68 , if the device registration data has been received (S 68 : Yes), the received device registration data is transmitted to the server  70  from the base communication part  61  by communication using the HTTPS protocol (S 69 ). At this time, the HTTPS access authorization information received by the processing of S 63  is included in the transmission. 
     After the processing of S 69 , it is confirmed whether a response to the transmission of the device registration data received from the server  70  by communication using the HTTPS protocol is “OK” (S 70 ). In the processing of S 70 , if the response to the transmission of the device registration data is not “OK” (S 70 : No), display (error display) indicating that the transmission has failed is performed on the LCD  56  (S 71 ). After the processing of S 71 , the processing of S 67  onwards is repeated. On the other hand, in the processing of S 70 , if the response to the transmission of the device registration data is “OK” (S 70 : Yes), a list of APs  90  is requested from the communication device  1  by the BT communication part  60  (S 72 ). 
     After the processing of S 72 , it is confirmed whether the list of APs  90  has been received from the communication device  1  by the BT communication part  60  (S 73 ). In the processing of S 73 , if the list of APs  90  has not been received (S 73 : No), the processing of S 73  is repeated. On the other hand, in the processing of S 73 , if the list of APs  90  has been received (S 73 : Yes), the received list of APs  90  is displayed on the LCD  56  (S 74 ). 
     After the processing of S 74 , it is confirmed whether an AP  90  on the list displayed on the LCD  56  has been selected via the touch panel  57  and the input PSW (AP password) thereof has been inputted (S 75 ). In the processing of S 75 , if the AP  90  has not been selected and the input PSW has not been inputted (S 75 : No), the processing of S 75  is repeated. On the other hand, in the processing of S 75 , if the AP  90  has been selected and the input PSW has been inputted (S 75 : Yes), the information about the AP  90  and the input PSW are transmitted to the communication device  1  by the BT communication part  60  (S 76 ). 
     After the processing of S 76 , it is confirmed whether a result of connection to the AP  90  has been received from the communication device  1  by the BT communication part  60  (S 77 ). In the processing of S 77 , if the result of connection to the AP  90  has not been received (S 77 : No), the processing of S 77  is repeated. On the other hand, in the processing of S 77 , if the result of connection to the AP  90  has been received (S 77 : Yes), it is confirmed whether the received result of connection is “connection successful” (S 78 ). 
     In the processing of S 78 , if the received result of connection is “connection error” (S 78 : No), display (error display) indicating that the connection has failed is performed on the LCD  56  (S 79 ), and the processing of S 74  onwards is repeated. On the other hand, in the processing of S 78 , if the received result of connection is “connection successful” (S 78 : Yes), the mobile terminal setup processing is ended. 
     Next, a processing of the setup mode of the server  70  will be described.  FIG.  17    is a flowchart of the server setup processing (S 20 ). In the server setup processing, first, standby is performed until communication using the HTTPS protocol occurs (S 80 ). After the processing of S 80 , it is confirmed whether user registration has been requested from the mobile terminal  50  by communication using the HTTPS protocol (S 81 ). 
     In the processing of S 81 , if the user registration has been requested (S 81 : Yes), it is confirmed whether the account received from the mobile terminal  50  is not registered in the user DB  72   b  (see  FIG.  11 B ) (S 82 ). In the processing of S 82 , if the account received from the mobile terminal  50  is not registered in the user DB  72   b  (S 82 : Yes), the account and password received from the mobile terminal  50  and a uniquely created user identifier are registered in the user DB  72   b  (S 83 ). After the processing of S 83 , the fact (“OK”) that the received account has been registered in the user DB  72   b  is transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 84 ). 
     On the other hand, in the processing of S 82 , if the account received from the mobile terminal  50  has been registered in the user DB  72   b  (S 82 : No), the fact (ERROR) that the received account has already been registered in the user DB  72   b  is transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 85 ). After the processings of S 84  and S 85 , the processing of S 80  onwards is repeated. 
     In the processing of S 81 , if no request for user registration has been made (S 81 : No), it is confirmed whether login has been requested from the mobile terminal  50  by communication using the HTTPS protocol (S 86 ). In the processing of S 86 , if login has been requested (S 86 : Yes), login is executed, and it is confirmed whether the login has succeeded (S 87 ). In the processing of S 87 , if the login has succeeded (S 87 : Yes), the HTTPS access authorization information of the logged-in user H is created (S 88 ). 
     After the processing of S 88 , the created HTTPS access authorization information and the fact (“OK”) that the login has succeeded are transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 89 ). 
     On the other hand, in the processing of S 87 , if the login has failed (S 87 : No), the fact (ERROR) is transmitted by communication using the HTTPS protocol (S 90 ). After the processings of S 89  and S 90 , the processing of S 80  onwards is repeated. 
     In the processing of S 86 , if it is not a login request (S 86 : No), it is confirmed whether the device registration data has been received from the mobile terminal  50  by communication using the HTTPS protocol (S 91 ). In the processing of S 91 , if the device registration data has been received (S 91 : Yes), it is confirmed whether a device identifier in the received device registration data exists in the device DB  72   c  (S 92 ). 
     In the processing of S 92 , if the device identifier in the received device registration data exists in the device DB  72   c  (S 92 : Yes), product information of the received device registration data and the user identifier of the logged-in user H acquired from the user DB  72   b  are stored to an area for the device identifier of the received device registration data in the device DB  72   c  (S 93 ). After the processing of S 93 , the fact (“OK”) that the received device registration data has been successfully registered in the device DB  72   c  is transmitted by communication using the HTTPS protocol (S 94 ). 
     On the other hand, in the processing of S 92 , if the device identifier in the received device registration data does not exist in the device DB  72   c  (S 92 : No), the fact (“ERROR”) that the device registration data is not one belonging to a regular communication device  1  is transmitted by communication using the HTTPS protocol (S 95 ). After the processings of S 94  and S 95 , the server setup processing is ended. 
     Next, processings of the communication device  1 , the mobile terminal  50 , and the server  70  after the setup mode will be described. First, a processing of the communication device  1  after the setup mode will be described with reference to  FIG.  14    and  FIG.  18   . 
     In the processing of S 40  of  FIG.  14   , if there is no instruction for the setup mode (S 40 : No), the AP  90  is connected by the Wi-Fi communication part  4  by using the information about the AP  90  and the input PSW acquired by the processing of  FIG.  13    described above (S 42 ). After the processing of S 42 , it is confirmed whether connection to the AP  90  can be established (S 43 ). 
     In the processing of S 43 , if the AP  90  can be connected (S 43 : Yes), a Wi-Fi communication part workflow processing (S 44 ) is performed. Details of the Wi-Fi communication part workflow processing will be described later. 
     On the other hand, if the AP  90  cannot be connected (S 43 : No), it is confirmed whether the number of attempts to connect to the AP  90  has reached an upper limit of the number (e.g., 10 times) of retries (S 45 ). In the processing of S 45 , if the number of attempts to connect to the AP  90  has not reached the upper limit of the number of retries (S 45 : No), the processing of S 42  onwards is repeated; if the upper limit of the number of retries has been reached (S 45 : Yes), an error is displayed by blinking the LED  3  (S 46 ). After the processings of S 41 , S 44 , and S 46 , the Wi-Fi main processing is ended. 
     Herein, the Wi-Fi communication part workflow processing of S 44  will be described with reference to  FIG.  18   .  FIG.  18    is a flowchart of the Wi-Fi communication part workflow processing (S 44 ). In the Wi-Fi communication part workflow processing, first, the server  70  is connected in order to perform communication using the MQTT protocol (S 100 ). 
     After the processing of S 100 , it is confirmed whether the server  70  can be connected by the processing of S 100  (S 101 ). In the processing of S 101 , if the server  70  cannot be connected (S 101 : No), the processing of S 100  onwards is repeated. 
     On the other hand, in the processing of S 101 , if the server  70  can be connected (S 101 : Yes), a request topic of authorization information (i.e., the user identifier and the HTTPS access authorization information) is transmitted to the server  70  by the Wi-Fi communication part  4  by using MQTT protocol communication (S 102 ). Such a request topic includes the device identifier of the communication device  1 . The processings of S 100  and S 102  are not necessarily executed according to a judgment made by the communication device  1 . For example, in the case where the electronic musical instrument  30  recognizes that the communication device  1  is connected to the server  70 , the processings of S 100  and S 102  may also be executed by giving instructions to the communication device  1  from the electronic musical instrument  30 . 
     After the processing of S 102 , it is confirmed whether the user identifier and the HTTPS access authorization information have been received from the server  70  by the Wi-Fi communication part  4  by communication using the MQTT protocol (S 103 ). In the processing of S 103 , if the user identifier and the HTTPS access authorization information have not been received (S 103 : No), the processing of S 103  is repeated. 
     On the other hand, in the processing of S 103 , if the user identifier and the HTTPS access authorization information have been received (S 103 : Yes), the received user identifier and HTTPS access authorization information are transmitted to the electronic musical instrument  30  via the external IF  15  (S 104 ). Hereinafter, communication between the communication device  1  and the electronic musical instrument  30  in the Wi-Fi communication part workflow processing is assumed to be performed via the external IF  15 . 
     The HTTPS access authorization information is not necessarily transmitted to the electronic musical instrument  30 , but may, for example, be stored in the communication device  1 . At that time, if the HTTPS access authorization information is required for communication using the HTTPS protocol, the electronic musical instrument  30  may instruct the communication device  1  to add the HTTPS access authorization information to the transmission. By doing so, since the HTTPS access authorization information can be prevented from leaking from the external IFs  15  and  37 , security in the communication between the electronic musical instrument  30  and the server  70  can be improved. 
     In the electronic musical instrument  30 , an instruction for utilizing a resource such as timbre data is created for the server  70  by using the user identifier and the HTTPS access authorization information received from the communication device  1 . Details thereof will be described with reference to  FIG.  19    in the electronic musical instrument workflow processing to be described later. 
     After the processing of S 104 , subscription registration is performed with respect to the server  70  by the user identifier received by the processing of S 103  and the device identifier of the device identifier  11   b  (S 105 ). From this point on, the communication device  1  becomes able to receive MQTT data including the topic “topic/{user identifier}/{device identifier}/#”. 
     By transmitting the MQTT data including the topic from the mobile terminal  50  to the server  70 , the communication device  1  receives the MQTT data from the server  70 . A result obtained by receiving the MQTT data from the communication device  1  or the mobile terminal  50  and processing the same by the server  70  is transmitted to the communication device  1  as the MQTT data including the topic. In this way, the communication device  1  becomes able to exchange commands or data with the server  70  or with the mobile terminal  50  via the server  70 . 
     After the processing of S 105 , various events in the communication device  1  are confirmed (S 106 ). In the processing of S 106 , if the MQTT data, i.e., a topic from the server  70  and a payload transmitted together with the topic, are received from the server  70  (S 106 : receive MQTT data from server), the MQTT data is transmitted to the electronic musical instrument  30  via the external IF  15  (S 107 ). Herein, the MQTT data refers to a topic and a payload transmitted together with the topic. This payload includes information accompanying instructions for the electronic musical instrument  30  or the server  70 , a resource such as timbre data requested from the server  70 , a result of processing by the server  70 , etc. 
     In the processing of S 106 , if the MQTT data is received from the electronic musical instrument  30  (S 106 : receive MQTT data from electronic musical instrument), the MQTT data is transmitted to the server  70  by communication using MQTT (S 108 ). 
     In the processing of S 106 , if an HTTPS request is received from the electronic musical instrument  30  (S 106 : receive HTTPS request from electronic musical instrument), the HTTPS request is transmitted to the server  70  by communication using the HTTPS protocol (S 109 ). 
     In the processing of S 106 , if an HTTPS response is received from the server  70  (S 106 : receive HTTPS response from server), the HTTPS response is transmitted to the electronic musical instrument  30  (S 110 ). On the other hand, if no event has been received in the processing of S 106  (S 106 : “no event”), or, after the processings of S 107  to S 110 , the processing of S 106  onwards is repeated. 
     Next, the electronic musical instrument workflow processing will be described with reference to  FIG.  19   .  FIG.  19    is a flowchart of the electronic musical instrument workflow processing. The electronic musical instrument workflow processing is a processing executed after power of the electronic musical instrument  30  is turned on. 
     In the electronic musical instrument workflow processing, first, it is confirmed whether the user identifier and the HTTPS access authorization information have been received from the communication device  1  via the external IF  37  (S 130 ). Hereinafter, communication between the electronic musical instrument  30  and the communication device  1  in the electronic musical instrument workflow processing is assumed to be performed via the external IF  37 . 
     In the processing of S 130 , if the user identifier and the HTTPS access authorization information have been received (S 130 : Yes), the received user identifier and HTTPS access authorization information are acquired (S 131 ). Afterwards, the electronic musical instrument  30  transmits the correspondence timbre information of the electronic musical instrument  30  to the server  70  (S 131 - 2 ). On the other hand, in the processing of S 130 , if the user identifier and the HTTPS access authorization information have not been received (S 130 : No), the processing of S 131  is skipped. 
     After the processings of S 130  and S 131 , various events are confirmed in the electronic musical instrument  30  (S 132 ). In the processing of S 132 , if there is an event (S 132 : “there is event”), an electronic musical instrument event processing (S 133 ) is executed; if there is no event (S 132 : “no event”), the processing of S 132  onwards is repeated. The electronic musical instrument event processing of S 133  will be described later with reference to  FIG.  28   . 
     Next, a processing of the mobile terminal  50  after the setup mode will be described with reference to  FIG.  20   .  FIG.  20    is a flowchart of the mobile terminal workflow processing (S 12 ). In the mobile terminal workflow processing, first, the user H logs in to the server  70  by communication using the HTTPS protocol (S 140 ). 
     After the processing of S 140 , it is confirmed whether a response to the login received from the server  70  by communication using the HTTPS protocol is “OK” (S 141 ). In the processing of S 141 , if the response to the login is not “OK” (S 141 : No), display (error display) indicating that the login has failed is performed on the LCD  56  (S 142 ). After the processing of S 142 , the processing of S 140  onwards is repeated. 
     On the other hand, in the processing of S 141 , if the response to the login is “OK” (S 141 : Yes), the HTTPS access authorization information received from the server  70  is acquired together with the response to the login (S 143 ). The acquired HTTPS access authorization information will be used in subsequent HTTPS protocol communication from the mobile terminal  50  to the server  70 . After the processing of S 143 , the user identifier of the user H is requested from the server  70  by communication using the HTTPS protocol (S 144 ). At this time, the HTTPS access authorization information received by the processing of S 63  in  FIG.  16    is also transmitted. After the processing of S 144 , it is confirmed whether a response to the request for the user identifier is “OK” (S 145 ). 
     In the processing of S 145 , if the response to the request for the user identifier is not “OK” (S 145 : No), display (error display) indicating that the request for the user identifier has failed is performed on the LCD  56  (S 146 ). After the processing of S 146 , the processing of S 144  onwards is repeated. In the processing of S 145 , if the response to the request for the user identifier is “OK” (S 145 : Yes), the user identifier is acquired from the server  70  (S 147 ). 
     After the processing of S 147 , a device identifier and correspondence timbre information corresponding to the acquired user identifier are requested from the server  70  by communication using the HTTPS protocol (S 148 ). At this time, the HTTPS access authorization information received by the processing of S 63  in  FIG.  16    is also transmitted. After the processing of S 148 , it is confirmed whether a response to the request for the device identifier and the correspondence timbre information is “OK” (S 149 ). In the processing of S 149 , if the response to the request for the device identifier and the correspondence timbre information is not “OK” (S 149 : No), display (error display) indicating that the request for the device identifier and the correspondence timbre information has failed is performed on the LCD  56  (S 150 ). After the processing of S 150 , the processing of S 148  onwards is repeated. In the processing of S 149 , if the response to the request for the device identifier and the correspondence timbre information is “OK” (S 149 : Yes), the device identifier and the correspondence timbre information are acquired from the server  70  and registered to the owned device list  53   a  (S 151 ). 
     After the processing of S 151 , the server  70  is connected in order to perform communication using the MQTT protocol (S 152 ). After the processing of S 152 , it is confirmed whether the server  70  can be connected by the processing of S 152  (S 153 ). In the processing of S 153 , if the server  70  cannot be connected (S 153 : No), the processing of S 152  onwards is repeated. 
     In the processing of S 153 , if the server  70  can be connected (S 153 : Yes), subscription registration is performed with respect to the server  70  by the user identifier received by the processing of S 147  and the device identifier received by the processing of S 151  (S 154 ). From this point on, the mobile terminal  50  becomes able to receive MQTT data including the topic “topic/{user identifier}/{device identifier}/# (#: any command such as data request or data)”. 
     By transmitting the MQTT data including the topic from the communication device  1  to the server  70 , the mobile terminal  50  receives the MQTT data from the server  70 . A result obtained by receiving the MQTT data from the communication device  1  or the mobile terminal  50  and processing the same by the server  70  is transmitted to the mobile terminal  50  as the MQTT data including the topic. In this way, the mobile terminal  50  becomes able to exchange commands or data with the server  70  or with the communication device  1  via the server  70 . 
     After the processing of S 154 , various events of the mobile terminal  50  are confirmed (S 155 ). In the processing of S 155 , if there is an event (S 155 : “there is event”), a mobile terminal event processing (S 156 ) is executed; if there is no event (S 155 : “no event”), the processing of S 155  onwards is repeated. The mobile terminal event processing of S 156  will be described later with reference to  FIG.  23   . 
     Next, a processing of the server  70  after the setup mode will be described with reference to  FIG.  21    and  FIG.  22   .  FIG.  21    is a flowchart of the HTTPS workflow processing (S 21 ). In the HTTPS workflow processing, first, it is confirmed whether login has been requested from the mobile terminal  50  by communication using the HTTPS protocol (S 160 ). 
     In the processing of S 160 , if login has been requested (S 160 : Yes), login is executed, and it is confirmed whether the login has succeeded (OK) (S 161 ). In the processing of S 161 , if the login has succeeded (S 161 : Yes), the HTTPS access authorization information of the logged-in user H is created (S 162 ). After the processing of S 162 , a response of “OK” to the login is transmitted together with the created HTTPS access authorization information to the mobile terminal  50  by communication using the HTTPS protocol (S 163 ). 
     On the other hand, in the processing of S 161 , if the login has failed (S 161 : No), a response of “ERROR” to the login is transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 164 ). After the processings of S 163  and S 164 , the processing of S 160  onwards is repeated. 
     In the processing of S 160 , if it is not a login request (S 160 : No), it is confirmed whether a request for a user identifier has been made from the mobile terminal  50  by communication using the HTTPS protocol (S 165 ). In the processing of S 165 , if a request for the user identifier has been made (S 165 : Yes), a user identifier corresponding to the account of the user H of the mobile terminal  50  that made the request is acquired from the user DB  72   b  (S 166 ). After the processing of S 166 , the acquired user identifier and a response of “OK” to the request for the user identifier are transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 167 ). After the processing of S 167 , the processing of S 160  onwards is repeated. 
     In the processing of S 165 , if it is not a request for the user identifier (S 165 : No), it is confirmed whether a request for a device identifier has been made from the mobile terminal  50  by communication using the HTTPS protocol (S 168 ). In the processing of S 168 , if a request for the device identifier has been made (S 168 : Yes), a user identifier corresponding to the account of the user H of the mobile terminal  50  that made the request is acquired from the user DB  72   b , and a device identifier corresponding to the user identifier is further acquired from the device DB  72   c  (S 169 ). 
     After the processing of S 169 , the acquired device identifier and a response of “OK” to the request for the device identifier are transmitted to the mobile terminal  50  by communication using the HTTPS protocol (S 170 ). After the processing of S 170 , the processing of S 160  onwards is repeated. 
     In the processing of S 168 , if it is not a request for the device identifier (S 168 : No), a server HTTPS event processing (S 171 ) is executed, and the processing of S 160  onwards is repeated. The server HTTPS event processing of S 171  will be described later with reference to  FIG.  26   . 
       FIG.  22    is a flowchart of the MQTT workflow processing (S 22 ). In the MQTT workflow processing, first, standby is performed until communication connection using the MQTT protocol occurs (S 190 ). After the processing of S 190 , it is confirmed whether a connection has been made by communication using the MQTT protocol (S 191 ). In the processing of S 191 , if no connection has been made by communication using the MQTT protocol (S 191 : No), the processing of S 190  onwards is repeated. 
     On the other hand, in the processing of S 191 , if a connection has been made by communication using the MQTT protocol (S 191 : Yes), it is further confirmed whether an MQTT data has been received (S 192 ). 
     In the processing of S 192 , if the MQTT data has been received (S 192 : Yes), a topic of the received MQTT data is acquired (S 193 ). After the processing of S 193 , the MQTT data received by the processing of S 192  is transmitted to a terminal (i.e., the communication device  1  or the mobile terminal  50 ) that subscribes to the acquired topic (S 194 ). 
     Accordingly, since the MQTT data received from the communication device  1  or the mobile terminal  50  is transmitted to the mobile terminal  50  or the communication device  1  used by the same user H, the MQTT data transmitted from the communication device  1  or the mobile terminal  50  can be utilized and managed at the terminals of both devices. 
     After the processing of S 194 , it is confirmed whether the topic acquired by the processing of S 193  includes a command that needs to be processed by the server  70  (S 195 ). In the processing of S 195 , if the acquired topic includes a command that needs to be processed by the server  70  (S 195 : Yes), it is confirmed whether the command of the topic relates to a request for authorization information (i.e., user identifier and HTTPS access authorization information) from the communication device  1  (S 196 ). 
     In the processing of S 196 , if it relates to a request for authorization information from the communication device  1  (S 196 : Yes), a user identifier corresponding to the device identifier of the communication device  1  that received the request is acquired from the device DB  72   c , and the HTTPS access authorization information is created from the acquired user identifier (S 197 ). After the processing of S 197 , the user identifier acquired and the HTTPS access authorization information created by the processing of S 197  are transmitted to the communication device  1  that made the request by communication using the MQTT protocol (S 198 ). 
     On the other hand, in the processing of S 196 , if it is not related to the request for authorization information from the communication device  1  (S 196 : No), the server MQTT event processing (S 199 ) is executed. The server MQTT event processing of S 199  will be described later with reference to  FIG.  25   . 
     Next, the event processing in each of the mobile terminal  50 , the server  70 , and the electronic musical instrument  30  will be described. In the event processing, the loading, the writing, and the installation described with reference to  FIG.  4 A  to  FIG.  7    are mainly processed. First, the event processing of the mobile terminal  50  will be described with reference to  FIG.  23   . 
       FIG.  23    is a flowchart of the mobile terminal event processing (S 156 ). In the mobile terminal event processing, first, a mobile terminal loading processing (S 210 ), a mobile terminal writing processing (S 211 ), and a mobile terminal installation processing (S 212 ) are executed. These processings will be described with reference to  FIG.  24 A  to  FIG.  24 C . 
       FIG.  24 A  is a flowchart of the mobile terminal loading processing (S 210 ). The mobile terminal loading processing is a processing related to loading in the mobile terminal  50 . In the mobile terminal loading processing, first, it is confirmed whether loading has been instructed via the touch panel  57  (S 230 ). In the processing of S 230 , if loading has been instructed (S 230 : Yes), an MQTT data is created with the topic being “instruction for loading timbre data” and the payload being “timbre data ID” specified via the touch panel  57 . The topic of such an MQTT data includes the user identifier of the user H and the device identifier of the device registration data of the communication device  1  acquired by the processing of S 67  of  FIG.  16   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 231 ). 
     In the processing of S 230 , if loading has not been instructed (S 230 : No), the processing of S 231  is skipped. After the processings of S 230  and S 231 , the mobile terminal loading processing is ended. 
       FIG.  24 B  is a flowchart of the mobile terminal writing processing (S 211 ). The mobile terminal writing processing is a processing related to writing in the mobile terminal  50 . In the mobile terminal writing processing, first, it is confirmed whether writing has been instructed via the touch panel  57  (S 240 ). In the processing of S 240 , if writing has been instructed (S 240 : Yes), an MQTT data is created with the topic being “instruction for writing timbre data” and the payload being “timbre data ID” specified via the touch panel  57 . The topic of such an MQTT data includes the device identifier of the device registration data of the communication device  1  and the user identifier of the user H. The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 241 ). 
     In addition, “identifier indicating writing destination area” may also be included in the payload of the MQTT data transmitted by the processing of S 241 . Such an MQTT data is also transmitted from the server  70  to the electronic musical instrument  30  in the processing of S 270  to be described later. Then, when the electronic musical instrument  30  stores the timbre data received from the server  70  by the processing of S 335  to be described later, the timbre data received from the server  70  may be stored to an area of the timbre data memory  32   b  corresponding to “identifier indicating writing destination area” included in the payload of the MQTT data received by the processing of S 270 . 
     In the processing of S 240 , if writing has not been instructed (S 240 : No), the processing of S 241  is skipped. After the processings of S 240  and S 241 , the mobile terminal writing processing is ended. 
       FIG.  24 C  is a flowchart of the mobile terminal installation processing (S 212 ). The mobile terminal installation processing is a processing related to installation in the mobile terminal  50 . In the mobile terminal installation processing, first, it is confirmed whether installation has been instructed via the touch panel  57  (S 250 ). 
     In the processing of S 250 , if installation has been instructed (S 250 : Yes), an MQTT data is created with the topic being “installability of wave data” and the payload being “size of wave data (specified via touch panel  57 )”. The topic of such an MQTT data includes the device identifier of the device registration data of the communication device  1  and the user identifier of the user H. The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 251 ). In the processing of S 250 , if installation has not been instructed (S 250 : No), the processing of S 251  is skipped. 
     After the processings of S 250  and S 251 , it is confirmed whether the topic of the MQTT data received from the server  70  is “installability” (S 252 ). Specifically, it is confirmed whether the device identifier of the device registration data of the communication device  1 , the user identifier of the user H, and “installability” are all included in the topic of the received MQTT data. In the processing of S 252 , if the topic of the received MQTT data is “installability” (S 252 : Yes), it is confirmed whether the payload of the MQTT data received by the processing of S 252  is “installable” (S 253 ). 
     In the processing of S 253 , if the payload is “installable” (S 253 : Yes), an HTTPS request requesting creation of a URL of the wave data (specified via the touch panel  57 ) is transmitted to the server  70  by communication using the HTTPS protocol (S 254 ). At this time, the HTTPS access authorization information acquired by the processing of S 143  in  FIG.  20    is also transmitted. 
     After the processing of S 254 , the URL of the wave data requested by the processing of S 254  is received from the server  70  (S 255 ). After the processing of S 255 , an MQTT data is created with the topic being “instruction for installing wave data” and the payload being “URL of wave data” received by the processing of S 255 , and the created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 256 ). 
     In the processing of S 253 , if the payload is not “installable” (S 253 : No), display (error display) indicating that the wave data cannot be installed is performed on the LCD  56  (S 257 ). In the processing of S 252 , if the topic of the received MQTT data is not “installability” (S 252 : No), or, after the processings of S 256  and S 257 , the mobile terminal installation processing is ended. 
     Returning to  FIG.  23   , after the mobile terminal installation processing of S 212 , it is confirmed whether the topic of the MQTT data received from the server  70  is “progress notification” (S 213 ). Specifically, it is confirmed whether the device identifier of the device registration data of the communication device  1 , the user identifier of the user H, and “progress notification” are all included in the topic of the received MQTT data. In the processing of S 213 , if the topic of the received MQTT data is “progress notification” (S 213 : Yes), a progress rate is acquired from the payload of the received MQTT data (S 214 ), and the progress rate is confirmed (S 215 ). 
     In the processing of S 215 , if the progress rate is 100% (S 215 : “100%”), display indicating that the writing or installation is completed is performed on the LCD  56  (S 216 ). In the processing of S 215 , if the progress rate is 0 to 99% (S 215 : “0 to 99%”), the progress rate is displayed on the LCD  56  (S 217 ). In the processing of S 215 , if “error” is stored instead of the progress rate (S 215 : “ERROR”), display (error display) indicating that the writing or installation has failed is performed on the LCD  56  (S 218 ). 
     In the processing of S 213 , if the topic of the received MQTT data is not “progress notification” (S 213 : No), or, after the processings of S 216  to S 218 , it is confirmed whether the topic of the MQTT data received from the server  70  is “sync completed” (S 219 ). Specifically, it is confirmed whether the device identifier of the device registration data of the communication device  1 , the user identifier of the user H, and “sync completed” are all included in the topic of the received MQTT data. 
     In the processing of S 219 , if the topic of the received MQTT data is “sync completed” (S 219 : Yes), an HTTPS request requesting the sync data  72   e  is transmitted to the server  70  by communication using the HTTPS protocol (S 220 ). At this time, the HTTPS access authorization information acquired by the processing of S 143  in  FIG.  20    is also transmitted. After the processing of S 220 , the sync data  72   e  is received from the server  70  (S 221 ), and display based on the received sync data  72   e  is performed on the LCD  56  (S 222 ). 
     In the processing of S 219 , if the topic of the received MQTT data is not “sync completed” (S 219 : No), or, after the processing of S 222 , other processings (S 223 ) are executed, and the mobile terminal event processing is ended. Examples of other processings of S 223  include: creating an MQTT data or an HTTPS request corresponding to an instruction inputted to the mobile terminal  50  and transmitting to the server  70 ; analyzing an MQTT data received by the mobile terminal  50  and performing a processing according to the MQTT data; and performing a processing according to an HTTPS response from the server  70 . 
     Next, the event processing in the communication using the MQTT protocol of the server  70  will be described with reference to  FIG.  25   .  FIG.  25    is a flowchart of the server MQTT event processing (S 199 ). In the server MQTT event processing, first, it is confirmed whether an MQTT data with the topic being “instruction for loading timbre data” has been received (S 260 ). 
     In the processing of S 260 , if an MQTT data with the topic being “instruction for loading timbre data” has been received (S 260 : Yes), it is confirmed whether the timbre data corresponding to the timbre data ID included in the payload of the received MQTT data can be loaded (used) by the user identifier of the user H who has transmitted the MQTT data (S 261 ). Specifically, with reference to the management information  72   g , it is confirmed whether the user H has already purchased the timbre data corresponding to the timbre data ID included in the payload of the received MQTT data, or whether the timbre data can be used with the subscription authority of the user H. 
     In the processing of S 261 , if the timbre data can be loaded (S 261 : Yes), the timbre data corresponding to the timbre data ID of the payload of the MQTT data received by the processing of S 260  is acquired from the timbre DB  72   d  (S 262 ). After the processing of S 262 , an MQTT data is created with the topic being “instruction for loading timbre data” and the payload being “timbre data” acquired by the processing of S 262 . The topic of such an MQTT data includes the device identifier and the user identifier of the topic received by the processing of S 260 . The created MQTT data is transmitted to the devices (i.e., the electronic musical instrument  30  and the mobile terminal  50 ) registered for subscription by the device identifier and the user identifier of the topic received by the processing of S 260  (S 263 ). 
     If an MQTT data with the topic being “instruction for loading timbre data” has not been received in the processing of S 260  (S 260 : No), if the timbre data cannot be loaded in the processing of S 261  (S 261 : No), or, after the processing of S 263 , it is confirmed whether an MQTT data with the topic being “update of load history” has been received (S 264 ). In the processing of S 264 , if an MQTT data with the topic being “update of load history” has been received (S 264 : Yes), the timbre data ID of the payload of the received MQTT data is acquired (S 265 ). 
     After the processing of S 265 , 1 is added to the load count corresponding to the user identifier of the topic of the MQTT data and the acquired timbre data ID of the timbre data in the load history  72   f  (S 266 ). 
     In the processing of S 264 , if an MQTT data with the topic being “update of load history” has not been received (S 264 : No), or, after the processing of S 266 , it is confirmed whether an MQTT data with the topic being “instruction for writing timbre data” has been received (S 267 ). In the processing of S 267 , if an MQTT data with the topic being “instruction for writing timbre data” has been received (S 267 : Yes), it is confirmed whether the timbre data corresponding to the timbre data ID included in the payload of the received MQTT data can be written (used) by the user identifier of the user H who has transmitted the MQTT data (S 268 ). 
     Specifically, with reference to the management information  72   g , it is confirmed whether the user H has already purchased the timbre data corresponding to the timbre data ID included in the payload of the received MQTT data, or whether the timbre data can be used with the subscription authority of the user H. In the processing of S 268 , if the timbre data can be written (S 268 : Yes), a URL is created for acquiring the timbre data of the timbre data ID of the payload of the received MQTT data from the timbre DB  72   d  (S 269 ). 
     After the processing of S 269 , an MQTT data is created with the topic being “instruction for writing timbre data” and the payload being “URL” created by the processing of S 269 . The topic of such an MQTT data includes the device identifier and the user identifier of the topic received by the processing of S 267 . The created MQTT data is transmitted to the devices (i.e., the electronic musical instrument  30  and the mobile terminal  50 ) registered for subscription by the device identifier and the user identifier of the topic received by the processing of S 267  (S 270 ). 
     If an MQTT data with the topic being “instruction for writing timbre data” has not been received in the processing of S 267  (S 267 : No), if the timbre data cannot be written in the processing of S 268  (S 268 : No), or after the processing of S 270 , other processings (S 271 ) are executed, and the server MQTT event processing is ended. Examples of other processings of S 271  include transmitting an MQTT data other than the above received from the communication device  1  (the electronic musical instrument  30 ) or the mobile terminal  50  to another device registered for subscription. 
     As described above, in the server MQTT event processing, if the topic of a specific MQTT data is received in the processings of S 260 , S 264 , and S 267 , the server  70  executes a necessary processing in advance, and the processing result and the topic of the received MQTT data are transmitted to another device registered for subscription. Accordingly, in the electronic musical instrument  30  or the mobile terminal  50  to which the MQTT data is transmitted, after receiving the MQTT data, since it is not necessary to request the server  70  to perform a processing according to the topic of the MQTT data, resources on the server  70  can be used more quickly. 
     Further, the processing result of a specific command is registered to the server  70  for subscription without being transmitted to another device, and by transmitting an MQTT data with the command as the topic to the server  70 , it is possible to have the server  70  perform only the processing according to the specific command. Thereby, the MQTT data can be used as a processing request for the server  70  (not intended to be transmitted to another device). 
     Next, the event processing in the communication using the HTTPS protocol of the server  70  will be described with reference to  FIG.  26    and  FIG.  27   .  FIG.  26    is a flowchart of the server HTTPS event processing (S 171 ). In the server HTTPS event processing, first, it is confirmed whether an HTTPS request being an acquisition request using a URL of a timbre data or a wave data has been received (S 280 ). 
     In the processing of S 280 , if an HTTPS request being an acquisition request has been received (S 280 : Yes), it is confirmed whether there is no problem with the HTTPS access authorization information received together with the URL in the HTTPS request (S 281 ). In the processing of S 281 , the user identifier may be confirmed instead of the HTTPS access authorization information, or both the HTTPS access authorization information and the user identifier may be confirmed. In the processing of S 281 , if there is no problem with the HTTPS access authorization information and the user identifier (S 281 : Yes), together with a response “OK”, the timbre data or the wave data specified by the URL is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 282 ). 
     On the other hand, in the processing of S 281 , if there is a problem with the HTTPS access authorization information or the user identifier (S 281 : No), a response “NG” is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 283 ). 
     In the processing of S 280 , if an HTTPS request being an acquisition request has not been received (S 280 : No), or, after the processings of S 282  and S 283 , it is confirmed whether an HTTPS request being a request for creating a URL of a wave data has been received (S 284 ). In the processing of S 284 , if an HTTPS request being a request for creating a URL of a wave data has been received (S 284 : Yes), it is confirmed whether there is no problem with the HTTPS access authorization information received in the HTTPS request (S 285 ). In the processing of S 285 , the user identifier may be confirmed instead of the HTTPS access authorization information, or both the HTTPS access authorization information and the user identifier may be confirmed. 
     In the processing of S 285 , if there is no problem with the HTTPS access authorization information and the user identifier (S 285 : Yes), together with a response “OK” to the request source of the HTTPS request, a URL for acquiring the specified wave data from the timbre DB  72   d  is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 286 ). On the other hand, in the processing of S 285 , if there is a problem with the HTTPS access authorization information or the user identifier (S 285 : No), a response “NG” is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 287 ). 
     In the processing of S 284 , if an HTTPS request being a request for creating a URL of a wave data has not been received (S 284 : No), or, after the processings of S 286  and S 287 , a server sync processing (S 288 ) is executed. Herein, the server sync processing will be described with reference to  FIG.  27   . 
       FIG.  27    is a flowchart of the server sync processing (S 288 ). The server sync processing is a processing related to the update of the sync data  72   e  in the server  70 . In the server sync processing, first, it is confirmed whether an HTTPS request being a sync instruction request has been received (S 300 ). In the processing of S 300 , if an HTTPS request being a sync instruction request has been received (S 300 : Yes), it is confirmed whether there is no problem with the HTTPS access authorization information received in the HTTPS request (S 301 ). 
     In the processing of S 301 , if there is no problem with the HTTPS access authorization information (S 301 : Yes), by storing the timbre data ID and attribute information or the wave data ID and attribute information received in the HTTPS request to the sync data  72   e , the sync data  72   e  is updated (S 302 ). 
     After the processing of S 302 , an MQTT data is created with the topic being “sync completed” and the payload being “COMPLETED”. The topic of such an MQTT data includes the device identifier and the user identifier of the request source of the HTTPS request received by the processing of S 300 . The created MQTT data is transmitted to a device registered for subscription by the device identifier and the user identifier of the request source of the HTTPS request (S 303 ). 
     On the other hand, in the processing of S 301 , if there is a problem with the HTTPS access authorization information (S 301 : No), a response “NG” is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 304 ). 
     In the processing of S 300 , if an HTTPS request being a sync instruction request has not been received (S 300 : No), or, after the processings of S 303  and S 304 , it is confirmed whether an HTTPS request being a request for the sync data  72   e  has been received (S 305 ). In the processing of S 305 , if an HTTPS request being a request for the sync data  72   e  has been received (S 305 : Yes), it is confirmed whether there is no problem with the HTTPS access authorization information received in the HTTPS request (S 306 ). In the processing of S 306 , the user identifier may be confirmed instead of the HTTPS access authorization information, or both the HTTPS access authorization information and the user identifier may be confirmed. 
     In the processing of S 306 , if there is no problem with the HTTPS access authorization information and the user identifier (S 306 : Yes), together with a response “OK”, the sync data  72   e  is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 307 ). On the other hand, in the processing of S 306 , if there is a problem with the HTTPS access authorization information or the user identifier (S 306 : No), a response “NG” is transmitted to the request source of the HTTPS request by communication using the HTTPS protocol (S 308 ). In the processing of S 305 , if an HTTPS request being a request for the sync data  72   e  has not been received (S 305 : No), or, after the processings of S 307  and S 308 , the server sync processing is ended. 
     Returning to  FIG.  26   , after the server sync processing of S 288 , other processings (S 289 ) are executed, and the server HTTPS event processing is end. Examples of other processings of S 289  include a processing of performing a processing for an HTTPS request other than the above received from the communication device  1  or the mobile terminal  50 , and transmitting the result as an HTTPS response by communication using the HTTPS protocol. 
     Finally, the event processing in the electronic musical instrument  30  will be described with reference to  FIG.  28    to  FIG.  30   .  FIG.  28    is a flowchart of the electronic musical instrument event processing (S 133 ). In the electronic musical instrument event processing, first, it is confirmed whether the topic of an MQTT data received from the server  70  is “instruction for loading timbre data” (S 320 ). Specifically, it is confirmed whether the device identifier of the device registration data of the communication device  1 , the user identifier received by the processing of S 131  in  FIG.  19   , and “instruction for loading timbre data” are all included in the topic of the received MQTT data. 
     In the processing of S 320 , if the topic of the received MQTT data is “instruction for loading timbre data” (S 320 : Yes), the timbre data is acquired from the payload of the received MQTT data and stored to the work memory  33   a  (S 321 ). After the processing of S 321 , an MQTT data is created with the topic being “update of load history” and the payload being “timbre data ID of timbre data” stored in the work memory  33   a . The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 322 ). 
     In the processing of S 320 , if the topic of the received MQTT data is not “instruction for loading timbre data” (S 320 : No), or, after the processing of S 322 , an electronic musical instrument writing processing (S 323 ) and an electronic musical instrument installation processing (S 324 ) are executed. Herein, these processings will be described with reference to  FIG.  29    and  FIG.  30   . 
       FIG.  29    is a flowchart of the electronic musical instrument writing processing (S 323 ). The electronic musical instrument writing processing is a processing related to the writing in the electronic musical instrument  30 . In the electronic musical instrument writing processing, first, it is confirmed whether the topic of an MQTT data received from the server  70  is “instruction for writing timbre data” (S 330 ). Specifically, it is confirmed whether the device identifier of the device registration data of the communication device  1 , the user identifier received by the processing of S 131  in  FIG.  19   , and “instruction for writing timbre data” are all included in the topic of the received MQTT data. 
     In the processing of S 330 , if the topic of the received MQTT data is “instruction for writing timbre data” (S 330 : Yes), an HTTPS request being an acquisition request for a timbre data of a URL of the payload of the received MQTT data is transmitted to the server  70  by communication using the HTTPS protocol (S 331 ). At this time, the HTTPS access authorization information acquired by the processing of S 131  in  FIG.  19    is also transmitted. 
     After the processing of S 331 , it is confirmed whether a response to the acquisition request of the processing of S 331  is “OK” (S 332 ). In the processing of S 332 , if the response is “OK” (S 332 : Yes), an MQTT data is created with the topic being “progress notification” and the payload being a value (0 to 99%) according to a rate of receiving the timbre data. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 333 ). 
     After the processing of S 333 , it is confirmed whether reception of the timbre data is completed (S 334 ). In the processing of S 334 , if reception of the timbre data is not completed (S 334 : No), the processing of S 333  onwards is repeated. On the other hand, in the processing of S 334 , if reception of the timbre data is completed (S 334 : Yes), the received timbre data is stored to the timbre data memory  32   b  (S 335 ). 
     After the processing of S 335 , an MQTT data is created with the topic being “progress notification” and the payload being “100%”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 336 ). 
     After the processing of S 336 , an HTTPS request being a sync instruction request is transmitted to the server  70  by communication using the HTTPS protocol (S 337 ). At this time, the timbre data ID and attribute information of the written timbre data and the HTTPS access authorization information acquired by the processing of S 131  in  FIG.  19    are also transmitted. 
     In the processing of S 332 , if the response is not “OK” (S 332 : No), an MQTT data is created with the topic being “progress notification” and the payload being “ERROR”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 338 ). 
     In the processing of S 330 , if the topic of the received MQTT data is not “instruction for writing timbre data” (S 330 : No), or, after the processings of S 337  and S 338 , the electronic musical instrument writing processing is ended. 
       FIG.  30    is a flowchart of the electronic musical instrument installation processing (S 324 ). The electronic musical instrument installation processing is a processing related to the installation in the electronic musical instrument  30 . In the electronic musical instrument installation processing, first, it is confirmed whether the topic of an MQTT data received from the server  70  is “installability” (S 350 ). Specifically, it is confirmed whether the device identifier of the communication device  1 , the user identifier received by the processing of S 131  in  FIG.  19   , and “installability” are all included in the topic of the received MQTT data. 
     In the processing of S 350 , if the topic of the received MQTT data is “installability” (S 350 : Yes), it is confirmed whether a wave data in a size set in the payload of the received MQTT data can be stored to the wave data memory  32   c  (S 351 ). In the processing of S 351 , if the wave data can be stored to the wave data memory  32   c  (S 351 : Yes), an MQTT data is created with the topic being “installability” and the payload being “installable”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 352 ). 
     On the other hand, in the processing of S 351 , if the wave data cannot be stored to the wave data memory  32   c  (S 351 : No), an MQTT data is created with the topic being “installability” and the payload being “not installable”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 353 ). 
     In the processing of S 350 , if the topic of the received MQTT data is not “installability” (S 350 : No), or, after the processings of S 352  and S 353 , it is confirmed whether the topic of the MQTT data received from the server  70  is “instruction for installing wave data” (S 354 ). Specifically, it is confirmed whether the device identifier of the communication device  1 , the user identifier received by the processing of S 131  in  FIG.  19   , and “instruction for installing wave data” are all included in the topic of the received MQTT data. 
     In the processing of S 354 , if the topic of the received MQTT data is “instruction for installing wave data” (S 354 : Yes), an acquisition request for the wave data of the URL of the payload of the received MQTT data is transmitted to the server  70  by communication using the HTTPS protocol (S 355 ). At this time, the HTTPS access authorization information acquired by the processing of S 131  in  FIG.  19    is also transmitted. 
     After the processing of S 355 , it is confirmed whether a response to the acquisition request of the processing of S 355  is “OK” (S 356 ). In the processing of S 356 , if the response is “OK” (S 356 : Yes), an MQTT data is created with the topic being “progress notification” and the payload being a value (0 to 99%) according to a rate of receiving the wave data. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 357 ). 
     After the processing of S 357 , it is confirmed whether reception of the wave data is completed (S 358 ). In the processing of S 358 , if reception of the wave data is not completed (S 358 : No), the processing of S 357  onwards is repeated. On the other hand, in the processing of S 358 , if reception of the wave data is completed (S 358 : Yes), the received wave data is stored to the wave data memory  32   c  (S 359 ). 
     After the processing of S 359 , an MQTT data is created with the topic being “progress notification” and the payload being “100%”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 360 ). 
     After the processing of S 360 , an HTTPS request being a sync instruction request is transmitted to the server  70  by communication using the HTTPS protocol (S 361 ). At this time, the wave data ID and attribute information of the installed wave data and the HTTPS access authorization information acquired by the processing of S 131  in  FIG.  19    are also transmitted. 
     In the processing of S 356 , if the response is not “OK” (S 356 : No), an MQTT data is created with the topic being “progress notification” and the payload being “ERROR”. The topic of such an MQTT data includes the device identifier of the communication device  1  and the user identifier received by the processing of S 131  in  FIG.  19   . The created MQTT data is transmitted to the server  70  by communication using the MQTT protocol (S 362 ). 
     In the processing of S 354 , if the topic of the received MQTT data is not “instruction for installing wave data” (S 354 : No), or, after the processings of S 361  and S 362 , the electronic musical instrument installation processing is ended. 
     Returning to  FIG.  28   , after the electronic musical instrument installation processing of S 324 , other processings (S 325 ) are executed, and the electronic musical instrument event processing is ended. Examples of other processings of S 325  include: in the case where an instruction for the server  70  is inputted from the user H via the setting key  35  of the electronic musical instrument  30 , creating an MQTT data or an HTTPS request according to the instruction and transmitting to the communication device  1 ; in the case where another MQTT data is received from the server  70 , analyzing the received MQTT data and performing a processing according to the analyzed MQTT data; and in the case where an HTTPS response is received from the server  70 , performing a processing according to the received HTTPS response. 
     Although the disclosure has been described based on the above embodiments, obviously various improvements or modifications may be made. 
     In the above embodiments, the communication device  1  is configured to be connected to the electronic musical instrument  30 . However, the disclosure is not limited thereto. The communication device  1  may also be built in the electronic musical instrument  30 , and the processing concerning the communication device  1  may also be executed by the electronic musical instrument  30 . In this case, the device identifier is set as an identifier uniquely set for each electronic musical instrument  30 , and such a device identifier or product information (i.e., device registration data) may be stored in the electronic musical instrument  30 . 
     In the above embodiments, the communication device  1  is provided with the AP information  11   d  and the AP password  11   e , and the AP  90  is connected by using the information about the AP  90  and the input PSW stored in the AP information  11   d  and the AP password  11   e . However, the disclosure is not limited thereto. For example, the information about the AP  90  and the input PSW received from the mobile terminal  50  may be stored to the electronic musical instrument  30  (e.g., the flash ROM  32 ). When the communication device  1  is connected to the AP  90 , the information about the AP  90  and the input PSW stored in the electronic musical instrument  30  may be acquired from the electronic musical instrument  30 , and the AP  90  may be connected by using the acquired information about the AP  90  and the acquired input PSW. 
     In the above embodiments, the communication device  1  is provided with the operation button  2  and the LED  3 , and by pressing and holding the operation button  2 , the communication device  1  is caused to shift to the setup mode, and the LED  3  is caused to blink at this time. However, the disclosure is not limited thereto. For example, by a predetermined operation of the setting key  35  of the electronic musical instrument  30 , the communication device  1  may be caused to shift to the setup mode, and the LCD  36  may display that the communication device  1  is in the setup mode. In this case, the operation button  2  and the LED  3  may be omitted from the communication device  1 . 
     In the above embodiments, the server  70  creates the HTTPS access authorization information based on the user identifier of the user H and transmits the same to the communication device  1  and the mobile terminal  50 , and reception of resources is performed by communication using the HTTPS protocol based on the HTTPS access authorization information from the communication device  1  and the mobile terminal  50 . However, the authorization information created by the server  70  is not limited to the HTTPS access authorization information. The server  70  may create authorization information in other communication protocols and transmit the same to the communication device  1  and the mobile terminal  50 , and the communication device  1  and the mobile terminal  50  may receive resources from the server  70  by using the authorization information transmitted from the server  70 . 
     In the above embodiments, the AP  90  to be connected by Wi-Fi by the communication device  1  is selected by the user H by the mobile terminal  50 , and the input PSW is inputted by the user H by the mobile terminal  50 . However, the disclosure is not limited thereto. For example, in the case where the AP  90  that can be connected by the mobile terminal  50  is selected by the user H from the list of the APs  90  received from the communication device  1 , input of the input PSW by the user H by the mobile terminal  50  may be omitted, and a password used by the mobile terminal  50  for connecting the AP  90  may be transmitted as the input PSW to the communication device  1 . Further, in the case where the AP  90  that can be connected by the mobile terminal  50  is included in the list of APs  90  received from the communication device  1 , selection of the AP  90  by the user H by the mobile terminal  50  may be omitted, the AP  90  that can be connected by the mobile terminal  50  may be automatically selected, and the information about the AP  90  concerning the AP  90  that can be connected by the mobile terminal  50  and a password used for connecting the AP  90  may be transmitted to the communication device  1 . 
     In the above embodiments, the load history  72   f  stores a load count of the timbre data, but the disclosure is not limited thereto. Instead of a load count, the date and time when the timbre data is stored to the work memory  33   a  may be stored. Accordingly, for example, when the user H instructs from the mobile terminal  50  to load the electronic musical instrument  30 , by preferentially displaying on the LCD  56  the timbre data frequently used on the date and time period of loading, it is possible to prompt the user H to use the timbre data preferred by the user H on this date and time period. 
     In the above embodiments, the communication system S is composed of the electronic musical instrument  30  to which the communication device  1  is connected, the mobile terminal  50 , and the server  70 . However, the disclosure is not limited thereto. The mobile terminal  50  may be equipped with the function of the server  70 , and the server  70  may be omitted from the communication system S. Alternatively, the server  70  may be equipped with the function of the mobile terminal  50 , and the mobile terminal  50  may be omitted from the communication system S. 
     In the above embodiments, by connecting the communication device  1  to the AP  90  by Wi-Fi, and by connecting the AP  90  to the Internet N, the communication device  1  communicates with the server  70  via the Internet N. However, the disclosure is not limited thereto. For example, the communication device  1  may be connected to the base station  100  and be connected to the Internet N via the base station  100  in the same manner as the mobile terminal  50 . In this case, the base station  100  to which the communication device  1  is connected and the base station  100  to which the mobile terminal  50  is connected do not have to be the same base station. The communication device  1  may be connected to the AP  90  by a wireless communication standard other than Wi-Fi, or the communication device  1  and the Internet N may be connected by wired communication. 
     By connecting the mobile terminal  50  to the base station  100  and connecting the base station  100  to the Internet N, the mobile terminal  50  communicates with the server  70  via the Internet N. However, the disclosure is not limited thereto. For example, the mobile terminal  50  may be connected to the AP  90  by Wi-Fi and may be connected to the Internet N via the AP  90 . In this case, the AP  90  to which the communication device  1  is connected and the AP  90  to which the mobile terminal  50  is connected do not have to be the same access point. The mobile terminal  50  and the Internet N may also be connected by wired communication. 
     In the above embodiments, the communication device  1  and the mobile terminal  50  communicate with each other by Bluetooth. However, the disclosure is not limited thereto. For example, the communication device  1  and the mobile terminal  50  may be communicated by other short-range wireless communication standards such as ZigBee, or the communication device  1  and the mobile terminal  50  may be wire-connected for communication. 
     In the above embodiments, the mobile terminal  50  has been described as an example of the terminal to which an instruction is inputted from the user H. However, the disclosure is not limited thereto. For example, a personal computer or a tablet terminal may also serve as the terminal to which an instruction is inputted from the user H. 
     In the above embodiments, the electronic musical instrument  30  has been described as the electronic device to which the communication device  1  is connected. However, the disclosure is not limited thereto. A video device for processing a video may also serve as the electronic device to which the communication device  1  is connected. At this time, as resources, video data or audio data, and data concerning editing such as scene switching may be stored on the server  70 , and data according to an instruction from the video device may be transmitted to the communication device  1 .