JP7589587B2 - Communication device, control program, and service provision system - Google Patents

Description

The present invention relates to technology for communicating with a server.

Patent Document 1 describes a server that provides a specified service and a communication device that can communicate with this server. In Patent Document 1, prior to the provision of the service, the communication device stores in memory identification information of the communication device that is necessary for receiving the service from the server. Then, the communication device receives the service from the server using the identification information stored in the memory.

JP 2014-178984 A

For example, in a communication device, after deleting information stored in memory, re-registering with a server to receive services may be performed. In such a case, there is a concern that adverse effects may be caused on the communication device or server. However, Patent Document 1 does not state anything about the processing of the communication device when the information stored in memory is reset.

The present invention has been made in consideration of the above problems, and aims to minimize adverse effects on a communication device or server when re-registering with a server to receive services after resetting information stored in memory.

In order to solve the above problems, the present invention relates to a communication device that includes a communication interface, a memory, and a controller, and that is capable of communicating with a server that provides a specified service via the communication interface. Identification information that allows the server to identify the communication device when providing the specified service is stored in the memory of the communication device, and the controller executes an instruction reception process for receiving an instruction to reset the memory, a reset process for deleting information other than the identification information from the memory when the reset instruction is received, an update request process for requesting the server to update the identification information when re-registering with the server to receive the specified service after the reset process has been executed, and a storage process for storing the updated identification information in the memory based on the update request process.

In the above configuration, when the controller of the communication device receives an instruction to reset the memory, it executes a reset process that deletes information other than the identification information from the memory. After the reset process is executed, when re-registration is performed to receive a specified service from the server, the controller requests the server to update the identification information. As a result, the identification information is maintained until the communication device is re-registered to receive a service from the server after the memory is reset. On the other hand, when re-registration is performed to receive a service from the server, the identification information of the communication device is updated, so that a decrease in security can be suppressed compared to when the same identification information is continuously used for the communication device. As a result, when the memory is reset, adverse effects on the communication device or server can be minimized compared to when all information stored in the memory is deleted.

The present invention can be realized in various forms, and in addition to being an invention of a communication device, it can also be realized as a control program executed by a controller of the communication device, or a service provision system including a communication device.

According to the present invention, when re-registering with a server to receive services after resetting information stored in memory, adverse effects on the communication device or server can be minimized.

FIG. 1 is a diagram showing the configuration of a printing system. FIG. 4 is a diagram for explaining a management table. 4 is a timing chart showing a procedure for registering a service. 4 is a timing chart illustrating a procedure for executing a service. 6 is a timing chart illustrating the processing of each device after a factory reset. 6 is a flowchart illustrating the process executed in S32 of FIG. 5 . 10 is a timing chart illustrating the processing of each device after a factory reset according to the second embodiment.

First Embodiment
A printing system according to the present embodiment will be described with reference to the drawings.

The printing system 100 shown in FIG. 1 includes a terminal 10, a printer 30, and a server 50. The terminal 10, the printer 30, and the server 50 are connected to a network 200. In this embodiment, the network 200 may be the Internet, a local area network (LAN), or a combination of a LAN and the Internet. The network 200 may be wired, wireless, or a combination of wired and wireless. In this embodiment, the printer 30 is an example of a communication device.

The configuration of the terminal 10 will be described. The terminal 10 is a smartphone or a tablet terminal. The terminal 10 comprises a bus 11, a terminal side CPU 12, a memory 13, a user IF 17, and a communication IF 20. These components are connected to each other via the bus 11 so that they can communicate with each other. IF is an abbreviation for Interface.

The user IF 17 includes operation keys 18 and a touch panel 19. The touch panel 19 has a touch sensor and outputs a signal according to the detection result by the touch sensor. Note that "touch" in this embodiment includes the general operation of bringing an input medium into contact with the display screen of the touch panel 19. In addition, the concept of "touch" described above may also include bringing the input medium close to a position where the distance between the input medium and the touch panel 19 is very small. Furthermore, the input medium may be the user's finger, a touch pen, etc.

The communication IF 20 connects the terminal 10 to the network 200 in accordance with a specific communication protocol. The communication IF 20 is capable of performing wireless communication of the Wi-Fi(R) (registered trademark) system based on the IEEE 802.11 standard and standards equivalent thereto. The communication IF 20 may also perform short-range wireless communication with the printer 30 using Bluetooth (registered trademark) or the like. The communication IF 20 may also perform wireless communication using a mobile communication system via a base station.

The terminal side CPU 12 controls each part of the terminal 10 by executing the programs stored in the memory 13. The memory 13 stores an OS (abbreviation of Operating System), a print application program 14, a mail program 15, and a billing application program 16 (not shown). Hereinafter, the application program is simply referred to as an "application". The terminal side CPU 12 executes each program 14, 15, and 16 under the execution of the OS, thereby enabling communication between the printer 30 and the server 50 via the network 200. For example, the terminal side CPU 12 executes the print application 14 to instruct the printer 30 to perform a print process. The terminal side CPU 12 executes the mail program 15 to send and receive mail data to and from the server 50. The terminal side CPU 12 executes a billing application to receive services that involve billing from the server 50. Hereinafter, the CPU that executes a program may be referred to simply as the program name. For example, the phrase "the print application 14" may mean "the terminal side CPU 12 that executes the print application 14."

In this embodiment, the processing is mainly performed by the CPU according to the instructions written in the program. In other words, the processes such as "judging", "extracting", "selecting", "calculating", "deciding", "identifying", "obtaining", "receiving", and "controlling" in the following description represent the processing of the CPU or the controller. Processing by the CPU also includes hardware control via the OS. Note that "obtaining" is used as a concept that does not require a request. In other words, the process of receiving data without a request from each program is also included in the concept of "the CPU obtaining data". In addition, "data" in this specification is expressed in a computer-readable format. Data with the same substantial meaning but different formats are treated as the same data. The same applies to "information" in this specification.

Next, the configuration of the server 50 will be described. The server 50 includes a communication IF 52, a server-side CPU 53, and a memory 54, which are connected to each other via a bus 51 so that they can communicate with each other. The server 50 is capable of providing various services to the terminal 10. In this embodiment, the services that can be provided by the server 50 include an email service, an email print, and a billing service. The email service is a service for sending and receiving email data with a specified address between the terminal 10 and the server 50. The email print is a service for sending an email data with a print file attached thereto, thereby causing the printer 30 to print the print file. Note that, in this embodiment, various services are provided by one server 50, but this is not limiting, and multiple servers may each provide their own service.

A management table KT is stored in the memory 54 of the server 50. As shown in FIG. 2, the management table KT is information that associates and stores various information on services that the server 50 can provide. The management table KT includes the items of "device ID", "service ID", "account", "client number", "email address", and "billing information". The "device ID" is information for identifying a device used by the server 50 to provide a service, and is information that can uniquely identify the device. In FIG. 2, "dv1" is the device ID of the printer 30. The "service ID" is information for identifying a service that the server 50 can provide. Of these, "sv1" is the service ID of the mail print, and "sv2" is the service ID of the billing service. The "account" is information that the user inputs to receive each service. In addition, in the management table KT, the service ID (sv1) of the mail print is associated with an "email address" (xxx@print) and stored. The "client number" is information that the server 50 uses to identify the address of the device. In this embodiment, this information corresponds to the XMPP protocol. In the management table KT, the service ID (sv2) of the billing service is associated with "billing information" and stored. The billing information is information required when a user who receives the billing service makes a payment to the server, such as a credit card number.

In the management table KT shown in FIG. 2, two service IDs (sv1, sv2) are stored in association with the device ID (dv1) of the printer 30. This indicates that mail print and billing services are registered for the printer 30.

Next, the hardware configuration of the printer 30 will be described. The printer 30 includes a bus 31, a communication IF 32, a printing unit 33, a user IF 34, a controller 35, a memory 36, and an ink tank 38. Each component of the printer 30 is connected to be able to communicate with each other via the bus 31.

The communication IF 32 is similar to the communication IF 20 in the terminal 10. The user IF 34 is similar to the user IF 17 in the terminal 10, and is equipped with a touch panel and operation keys as physical keys.

The printing unit 33 executes a printing operation to print an image on a recording medium such as a sheet or a disk. The printing unit 33 is an inkjet type unit that ejects ink as a recording medium onto the recording medium. An ink tank 38 that stores ink is connected to the printing unit 33. The printing unit 33 may also be an electrophotographic type unit that forms a toner image on a photoreceptor and transfers the formed toner image to the recording medium. In this case, a toner cartridge that stores toner is connected to the printing unit instead of the ink tank 38.

The controller 35 is composed of a CPU, an ASIC (abbreviation for Application Specific Integrated Circuit), etc., and controls the operations of the print unit 33 and the user IF 34. The memory 36 stores various programs and data. In this embodiment, the memory 36 includes an NVRAM (abbreviation for Non-Volatile RAM) 37. In addition, the memory 36 may be composed of, for example, a combination of RAM, ROM, and flash memory. The memory 36 may also include a storage medium that can be read by the controller 35, which is a computer. Storage media also include recording media such as CD-ROM and DVD-ROM.

Firmware 40 is stored in memory 36. Controller 35 can execute print processing by executing firmware 40, which is a control program. Information used in various services is stored in memory 36. Specifically, a "service ID," a "device ID," an "email address," and a "protection flag" are stored. Each piece of information stored in memory 36 includes the same information as the information stored in association with device ID (dv1) in management table KT. In FIG. 1, device ID (dv1) is stored in NVRAM 37. Each piece of information stored in memory 36 is stored in memory 36 in the process shown in FIG. 3, which will be described later.

Next, using FIG. 3, the process of registering the printer 30 as a printer to be used for "mail print," a service that the server 50 can provide, will be described. Of the processes shown in FIG. 3, the processes executed by the printer 30 are executed by the firmware 40. It is assumed that a network connection between the printer 30 and the server 50 has already been established.

The user operates the user IF 34 of the printer 30 to register the printer 30 as a printer to be used for email printing. Specifically, the user switches the standby screen displayed on the user IF 34 to an email printing setting screen, and selects to execute email printing on this setting screen. When the firmware 40 accepts the selection of email printing, in step 10 (hereinafter referred to as S10), it transmits a registration request to the server 50 to register the printer 30 as a printer to be used for email printing.

When the server-side CPU 53 of the server 50 receives the registration request via the communication IF 52, in S11 it issues a device ID to the printer 30. In S12, the server-side CPU 53 stores the issued device ID in the management table KT, thereby registering the printer 30 as a printer to be used for email printing. Specifically, it stores a service ID (sv1) indicating "email printing" in association with the issued device ID (dv1) in the management table KT.

In S13, the server-side CPU 53 sends the "device ID" and authentication token issued in S11 to the printer 30. After this, the printer 30 and the server 50 are in a constant connection state according to the XMPP protocol. When the firmware 40 of the printer 30 receives the device ID, in S14, it stores the received device ID and authentication token in the NVRAM 37. This enables the server 50 to identify the printer 30 as a printer to be used for email printing. For example, if a service ID "sv2" that requires billing information such as a flat-rate printing service or a consumables ordering service is registered with the server 50, the firmware 40 of the printer 30 sets the protection flag stored in the memory 36 to 1.

In S15, the firmware 40 sends an address acquisition request to the server 50 along with the device ID (dv1) of the own device. The address acquisition request sent by the firmware 40 is a request to have the server 50 issue an email address associated with the printer 30 in "email print." Note that in S15, an authentication token capable of identifying the printer 30 may be sent instead of the device ID.

When the server-side CPU 53 receives the address acquisition request from the printer 30, in S16 it issues an email address to the printer 30. Specifically, the server-side CPU 53 issues the email address "xxx@print". In S17, the server-side CPU 53 associates the email address issued in S16 with the device ID (dv1) of the printer 30 and stores it in the management table KT.

In S18, the server-side CPU 53 sends the issued email address to the printer 30. In S19, the firmware 40 stores the email address received from the server 50 in the memory 36. After processing S19, the firmware 40 can display the email address stored in the memory 36 on the user IF 34 in response to an operation received via the user IF 34.

Next, the procedure for a user to print a print file stored in the terminal 10 using "Mail Print" will be described with reference to FIG. 4. The print file is, for example, a file created by the print application 14. However, it may also be a file created by another application, such as a word processing application or a table creation application. The process executed by the terminal 10 is a process executed by the mail program 15.

In response to a user's operation via user IF 17, mail program 15 causes user IF 17 to display a new creation screen. The user performs an operation on the new creation screen to attach a print file to the mail data, and inputs an email address stored in printer 30 as the destination. As a result, in S20, mail program 15 sends the mail data and the print file attached to the mail data to server 50, with the email address stored in printer 30 as the destination.

When the server-side CPU 53 of the server 50 receives the email data, it converts the file attached to the email data into a file that can be interpreted by the printer 30 as appropriate. Then, in S21, it references the device ID associated with the email address in the management table KT. In S22, the server-side CPU 53 transmits the print file attached to the email data to the printer 30 associated with the device ID referenced in S20 in the management table KT. For example, the server-side CPU 53 identifies the client number associated with the device ID according to the XMPP protocol, and transmits the print file to the printer 30 identified by that client number.

When the firmware 40 receives the print file from the server 50, in S23 it performs a save process to store the print file in the memory 36. For example, the print file may be stored in the memory 36 in association with the email address specified as the destination and the time the email address was received. In S24, the firmware 40 notifies the server 50 that the save of the print file has been completed.

In S25, the firmware 40 accepts a print operation of the print file by the user via the user IF 34. In this embodiment, the firmware 40 can display the print file received from the server 50 on the user IF 34 in association with the email address. Therefore, the user can specify the print file associated with the desired email address from among the print files displayed on the user IF 34 and perform a print operation on the firmware 40. In addition, when the firmware 40 receives a print file from the server 50, it may immediately print the print file without accepting an operation on the user IF 34 by the user. In this case, the process of S25 in FIG. 4 may be omitted.

In S26, the firmware 40 performs printing processing on the print file in response to the printing operation received in S25.

Next, the procedure of the process executed by each device when a factory reset is performed on the printer 30 will be described with reference to FIG. 5. The factory reset is a process for returning the printer 30 to the state it was in when it was shipped from the factory by deleting various data stored in the memory 36. Prior to executing the factory reset, when the terminal CPU 12 receives an operation from the user via the user IF 17 to display a setting screen for configuring various settings for the printer 30, the terminal CPU 12 sends a request to display the setting screen to the printer 30. The firmware 40 of the printer 30 uses its web server function to send web page data for displaying the setting screen to the terminal 10.

When the terminal CPU 12 receives the web page data, in S30 it displays a settings screen on the user IF 17 and accepts an operation to execute a factory reset. When the terminal CPU 12 accepts an operation to execute a factory reset by the user, in S31 it sends an instruction to execute a factory reset to the printer 30. In this embodiment, the process executed by the terminal CPU 12 in S30 is an example of an instruction acceptance process.

When the firmware 40 receives an instruction to execute a factory reset, it executes the reset process in S32. Figure 6 is a flowchart showing the details of the reset process executed in S32, and is mainly executed by the firmware 40.

In S50, it is determined whether or not a billing service has been registered for the printer 30. For example, if the "protection flag" stored in memory 36 is set to "1", it is determined that a billing service has been registered for the printer 30. The "protection flag" is information that is set to "1" when a constant connection is established between the printer 30 and the server 50 in order to receive the billing service. Alternatively, the server 50 may be queried as to whether or not the printer 30 is currently registered for the billing service, and the determination may be made based on the reply from the server 50.

If a billing service is not registered and a negative judgment is made in S50, the process proceeds to S51 and a factory reset is executed. In the factory reset, connection information such as the authentication token and protection flag used between the printer 30 and the server 50 are deleted. On the other hand, the device ID stored in the NVRAM 37 is not deleted in the factory reset in S51.

In S52, the reset flag is set to "0." The reset flag is information indicating whether or not a factory reset has been performed; "0" indicates that a factory reset has been performed, and "1" indicates that a factory reset has not been performed. This makes it possible to determine that a factory reset has been performed by referencing the value of the reset flag. Then, the process proceeds to S33 in FIG. 5.

On the other hand, if a billing service has already been registered, S50 is judged as positive and the process proceeds to S53. In this case, a factory reset is not executed. This is because, when a billing service is provided by the server 50, an authentication token is stored in the memory 36 in order to maintain a constant connection between the printer 30 and the server 50. However, if a factory reset is executed and the authentication token stored in the memory 36 is deleted, the constant connection between the server 50 and the printer 30 is released, and it becomes impossible to maintain the billing service for which payment has already been made. To avoid this, if a billing service has been registered, a factory reset is not executed in order to maintain a constant connection.

In S53, the reset flag is set to "1." If the reset flag is already set to "1," it remains set to "1." When the process of S53 ends, the process proceeds to S33 in FIG. 5.

In S33, the firmware 40 executes a notification process for the terminal 10. In this notification process, the firmware 40 sends the result of the reset process to the terminal 10. Specifically, if the reset flag is "0", the firmware 40 sends a factory reset completion notification to the terminal 10. On the other hand, if the reset flag is "1", the firmware 40 notifies the terminal 10 that a billing service is registered on the printer 30 and that a factory reset cannot be performed. This allows the user to recognize that a billing service is registered and therefore a factory reset cannot be performed.

The following describes an example in which a user re-registers the printer 30 in "Mail Print" after a factory reset has been performed.

When the firmware 40 of the printer 30 receives a registration operation via the user IF 34 to register the printer 30 as a printer to be used for "email printing," the firmware 40 determines in S34 whether a factory reset has been performed. Specifically, the firmware 40 refers to the reset flag, and if the reset flag is "0," it determines that a factory reset has been performed. On the other hand, if the reset flag is "1," it determines that a factory reset has not been performed.

If the reset flag is "1" and S34 is judged as negative, the firmware 40 ends the process shown in FIG. 5. In this case, the firmware 40 will continue printing emails to the printer 30 using the device ID currently stored in the NVRAM 37.

When the firmware 40 judges S34 as positive, the firmware 40 proceeds to S35 and transmits a device ID update request to the server 50 together with the device ID stored in the NVRAM 37. The update request is a request to the server 50 to update the device ID stored in the NVRAM 37 to a new device ID. In this embodiment, the process executed by the firmware 40 in S35 is an example of an update request process.

By sending the device ID from the printer 30 to the server 50, the server 50 can recognize that the device ID before the update and the device ID newly issued in S36 described below are information that identifies the same printer 30. This allows the server-side CPU 53 to, for example, inherit the information associated with the device ID before the update in the management table KT and store it in association with the newly issued device ID.

When the server-side CPU 53 of the server 50 receives the update request, in S36 it issues a new device ID to the printer 30. In S37, it registers the device ID issued in S36 in association with each piece of information in the management table KT, such as the mail print service ID (sv1).

In S38, the newly issued device ID is sent to the printer 30. When the firmware 40 of the printer 30 receives the device ID, in S39, the firmware 40 updates the device ID by overwriting the device ID already stored in the NVRAM 37 with the received device ID. This allows the printer 30 to be recognized by the server 50 by the updated device ID. In this embodiment, the process executed by the firmware 40 in S39 is an example of a storage process. Thereafter, the processes of S15 to S19 shown in FIG. 3 are executed, whereby the printer 30 can be set as a printer to be used for email printing.

The present embodiment described above can provide the following advantages.
When the controller 35 receives an instruction to execute a factory reset, it deletes information other than the device ID from the memory 36. When the controller 35 re-registers the printer 30 to the server 50 as a printer to be used for mail printing, the controller 35 requests the server 50 to update the device ID, and stores the device ID updated by the server 50 in the NVRAM 37. As a result, the device ID is held until the printer 30 is re-registered after the factory reset is performed. On the other hand, since the device ID is updated after the printer 30 is re-registered, it is possible to prevent a decrease in security compared to when the same device ID is continuously used for the printer 30.

The firmware 40 of the printer 30 requests the server 50 to update the device ID, and transmits the device ID stored in the NVRAM 37 to the server 50. This allows the server 50 to easily store information associated with the updated device ID in the management table KT, for example, by inheriting the data associated with the device ID before the update transmitted from the printer 30.

In response to a device ID update instruction, the firmware 40 causes the server 50 to create a new device ID for the printer 30, and stores the new device ID created by the server 50 in the NVRAM 37 as the updated device ID. This makes it possible to reset a new device ID for the printer 30 using the device ID created by the server 50.

When the firmware 40 receives an operation to execute a factory reset, if the provision of billing services is registered for the printer 30, the firmware 40 does not delete the information stored in the memory 36. On the other hand, when the firmware 40 receives an operation to execute a factory reset, if the provision of billing services is not registered for the printer 30, the firmware 40 deletes information other than the device ID stored in the memory 36. This makes it possible to prevent adverse effects on other services that may result from the inadvertent deletion of information stored in the memory 36.

When the firmware 40 receives a request to execute a factory reset, if the provision of a billing service is registered for the printer 30, it notifies the user that a billing service is registered. This notifies the user that a billing service is registered, so that the user can recognize the reason why a factory reset is not being executed.

Second Embodiment
In the second embodiment, the configuration different from the first embodiment will be mainly described. In the second embodiment, the same components as those in the first embodiment are denoted by the same reference numerals, and the description thereof will not be repeated.

In this embodiment, after a factory reset is performed on the printer 30, the firmware 40 creates a new device ID. Using FIG. 7, the procedure of the processes executed by each device when a factory reset is performed on the printer 30 according to this embodiment will be described. In this embodiment as well, when an instruction to execute a factory reset is sent from the terminal 10 to the printer 30 in S31, the reset process is executed in S32. Then, after the reset process in S32, it is assumed that the user operates the terminal 10 to register the printer 30 as a printer to be used for email printing.

In S34, the firmware 40 of the printer 30 determines whether a factory reset has been performed. If a positive determination is made in S34, the firmware 40 creates a new device ID for the printer itself in S60. The device ID created in S60 has a different value from the device ID stored in NVRAM 37. In S61, the firmware 40 sends to the server 50 a request to update the device ID, along with the old device ID stored in NVRAM 37 and the new device ID created in S60.

When the server-side CPU 53 of the server 50 receives an update request from the printer 30, in S62 it registers the new device ID received from the printer 30. The process of S62 is the same as the process of S37 in FIG. 5. In S63, the server-side CPU 53 notifies the printer 30 that the device ID has been updated. In S39, the firmware 40 updates the device ID by overwriting the old device ID stored in the NVRAM 37 with the device ID created in S60.

In the embodiment described above, the same effects as in the first embodiment can be achieved even when the device ID is created by the printer 30.

Other Embodiments
The technology disclosed in this specification is not limited to the above-described embodiments, and can be modified in various forms without departing from the spirit of the invention. For example, the following modifications are also possible.
In the above-described embodiments, a device ID is used as the identification information. Alternatively, a user ID that uniquely identifies a user may be used instead of the device ID.

When making a request to update the device ID in S35 of FIG. 5, the firmware 40 does not need to send the device ID. In this case, instead of sending the device ID in S35, the firmware 40 may send an authentication token capable of identifying the printer 30 to the server 50. The server-side CPU 53 of the server 50 may then use the authentication token to determine that a request to update the device ID has been made by the printer 30.

The services that the server can provide are not limited to email printing, but can be any service that uses a printer.

The communication device described as a printer 30 is merely an example, and the communication device may be a multifunction device capable of performing scanning processes in addition to printing processes. In this case, the service that the server can provide may be a service that uses scanning processes.

10... terminal, 30... printer, 32... communication IF, 34... user IF, 35... controller, 36... memory, 50... server

Claims (8)

A communication device comprising a communication interface, a memory, and a controller, and capable of communicating with a server that provides a predetermined service via the communication interface,
the memory stores identification information for the server to identify the communication device when providing the predetermined service;
The controller:
An instruction receiving process for receiving an instruction to reset the memory;
a reset process for deleting information other than the identification information from the memory when the reset instruction is received;
an update request process for requesting the server to update the identification information when re-registering with the server to receive the predetermined service after the reset process has been executed;
a storage process of storing the updated identification information in the memory based on the update request process;
A communications device that performs the above. The communication device according to claim 1, wherein the update request process requests the server to update the identification information and transmits the identification information stored in the memory to the server. the update request process causes the server to create new identification information for the communication device in response to a request to update the identification information;
3. The communication device according to claim 1, wherein the storage process stores the identification information created by the server in the memory as the updated identification information. The controller creates new identification information after executing the reset process,
the update request process transmits the newly created identification information to the server as the identification information of the communication device;
3. The communication device according to claim 1, wherein the newly created identification information is stored in the memory in the storage process. The server is capable of providing other services in addition to the predetermined service,
In addition to the identification information, the memory stores connection information for receiving the other service from the server,
In the reset process,
when the reset instruction is received, if the provision of the other service is registered for the communication device, the connection information stored in the memory is not deleted,
A communication device according to any one of claims 1 to 4, wherein when the reset instruction is received, if the provision of the other service is not registered for the communication device, the connection information stored in the memory is deleted. The communication device according to claim 5, which executes a notification process to notify the communication device that the other service is registered when the reset instruction is received and the provision of the other service is registered for the communication device. A control program executable by a controller of a communication device that includes a communication interface and a memory and is capable of communicating with a server that provides a predetermined service via the communication interface, the control program comprising:
The memory includes:
Identification information for the server to identify the communication device in providing the predetermined service is stored,
The controller,
An instruction receiving process for receiving an instruction to reset the memory;
a reset process of deleting information other than the identification information from the memory when the reset instruction is received;
an update request process for requesting the server to update the identification information when re-registering with the server to receive the predetermined service after the reset process has been executed;
a storage process of storing the updated identification information in the memory based on the update request process;
A control program that executes the above. A service providing system including a communication device having a communication interface and a memory, and a server providing a predetermined service, the communication device being capable of communicating with the server via the communication interface,
the memory stores identification information for the server to identify the communication device when providing the predetermined service;
The communication device includes:
An instruction receiving process for receiving an instruction to reset the memory;
a reset process of deleting information other than the identification information from the memory when the reset instruction is received;
an update request process for requesting the server to update the identification information when re-registering with the server to receive the predetermined service after the reset process has been executed;
Run
When the server receives a request to update the identification information, the server updates the identification information;
The communication device is a service providing system that executes a storage process to store the updated identification information in the memory based on the update request process.

Images