JP7762005B2 - Identifier reader and service provision system - Google Patents

Description

The present invention relates to an identifier reader and a service provision system.

In recent years, technology has become known for checking the safety of elderly people using communication devices such as personal computers and smartphones. For example, Patent Document 1 discloses a safety confirmation system in which multiple users use their own user devices to check on each other's safety.

JP 2018-55159 A

However, because the above-mentioned conventional technologies use general-purpose information and communication devices (such as personal computers or smartphones), elderly people who are unfamiliar with operating general-purpose information and communication devices are unable to fully utilize the above-mentioned systems.

There are also known technologies for monitoring elderly people, such as installing motion sensors in homes or providing elderly people with GPS devices. However, these conventional technologies require the effort of installing motion sensors in homes, and have the problem of causing stress to elderly people due to being monitored.

One aspect of the present invention was conceived in consideration of the above-mentioned problems, and aims to provide an identifier reader that can be easily used even by elderly people who are unfamiliar with operating communication terminals, and that encourages voluntary safety confirmation.

To solve the above problem, an identifier reader according to one aspect of the present invention includes a reading unit that reads an exercise identifier corresponding to a user's exercise from an exercise identification object held by the user, and a reader transmitting unit that transmits the exercise identifier read by the reading unit, the user's user identifier, and information indicating that the exercise identifier has been read by the reading unit to a management server.

One aspect of the present invention makes it easy for even elderly people who are unfamiliar with operating communication devices to use, and encourages them to proactively contact others to let them know they are safe.

1 is a block diagram showing an example of a configuration of a main part of a service providing system according to a first embodiment of the present invention; 1 is a schematic diagram illustrating an overview of a service providing system according to a first embodiment of the present invention. 1 is a schematic diagram showing an example of the appearance of a card reader and a service card according to a first embodiment of the present invention; 3 is a schematic diagram showing an example of the configuration of user information, service provider information, and service history information stored in a storage unit in the management server according to the first embodiment of the present invention; FIG. FIG. 2 is a sequence diagram showing an example of a flow in which a user receives a service using the service providing system according to the first embodiment of the present invention. FIG. 10 is a block diagram showing an example of a configuration of a main part of a service providing system according to a second embodiment of the present invention. FIG. 2 is a schematic diagram illustrating an example of the configuration of destination information. FIG. 10 is a diagram illustrating an example of a part of a processing flow of a control unit of the management server. FIG. 10 is a block diagram showing an example of a configuration of a main part of a service providing system according to a third embodiment of the present invention. FIG. 2 is a perspective view showing an example of the configuration of a card reader. FIG. 10 is a block diagram showing an example of a configuration of a main part of a service providing system according to a third embodiment of the present invention. FIG. 10 is a perspective view showing an example of the configuration of a card reader according to a third embodiment of the present invention. FIG. 2 is a schematic diagram showing an example of the configuration of exercise information. FIG. 2 is a schematic diagram showing an example of the configuration of exercise history information. 10 is a flowchart showing the processing of a control unit of a card reader. 10 is a flowchart showing a process of a control unit of a management server. FIG. 10 is a diagram showing a specific example of a display screen displayed on the verifying terminal.

[Embodiment 1]
Hereinafter, one embodiment of the present invention will be described in detail with reference to FIGS.

(Overview of the service provision system)
An overview of the service providing system 1 according to this embodiment will be described with reference to Fig. 2. Fig. 2 is a schematic diagram showing an overview of the service providing system 1.

The service provision system 1 allows users to access various services provided by multiple service providers using a pre-distributed card reader 200 and multiple service cards 100. Users can begin using the service provision system 1 by registering their personal information with the operating company (system operator) that operates the management server 300. Similarly, individual service providers can begin providing services using the service provision system 1 by registering contact information for their own provider server 400 with the management server 300. The operating company of the management server 300 distributes multiple service cards 100 corresponding to each of the multiple service providers and a card reader 200 capable of reading the contents of the multiple service cards 100 to users who wish to use the service provision system 1. The operating company of the management server 300 distributes the card reader 200 to users with information such as the connection destination pre-configured by the operating company of the management server 300. Therefore, after receiving the card reader 200, users can begin using the service provision system 1 without having to configure their communication environment. The card reader 200 is distributed in a state where it can be used over the mobile phone communication network contracted by the system operator, and users do not need to enter into a separate contract with a communication operator or internet service provider to use the service providing system 1.

By using the service provision system 1, a user can receive services from a service provider that corresponds to the service the user desires to receive. More specifically, the user can send a service provision request to the management server 300 by having the card reader 200 read the contents of the service card 100 that corresponds to the service provider that the user desires to receive.

The management server 300 is a server managed by the operating company that provides the service provision system 1. When the management server 300 receives a service provision request from the card reader 200, it identifies the service provider corresponding to the service card 100 read by the card reader 200 from the content of the provision request. The management server 300 then forwards the request content to the provider server 400 owned by the identified service provider. At this time, the management server 300 sends the request content along with personal information registered with the management server 300, including contact information for the requesting user, to the provider server 400.

Service providers are in the business of providing a variety of services. The services provided by a service provider may be of any type; for example, a service provider may provide services such as purchasing goods, making appointments for medical examinations, or arranging taxis. Each service provider operates its own provider server 400, which can accept service requests sent from the user's card reader 200 via the management server 300. When the request content and the user's contact information are transferred from the management server 300 to the provider server 400, the service provider contacts the requesting user. There are no particular limitations on the means of contact, but if the contact information is, for example, a telephone number, the service provider will contact the user by telephone. When contacting the user, the service provider may also explain the specific content and fees of the services to be provided.

When a service provider begins providing services to users using the service provision system 1, the service provider must register information such as the contact information (e.g., email address) of the provider server 400 with the system provider. An example of information that must be registered in advance is the amount to be paid to the system provider when the service provider provides services using the service provision system 1. The service provider may, for example, enter into a contract to pay the system provider an amount based on the number of times the service is provided to users using the service provision system 1. The amount to be paid to the system provider may be managed, for example, by the management server 300, and may be updated as appropriate depending on the situation.

When the user is contacted by the service provider, the service provider explains the specific details of the service, and then the user makes a final decision on whether or not to actually receive the service and notifies the service provider. When the service provider is notified of the user's final decision, it sends the result to the management server 300 using the provider server 400. The management server 300 stores the result received from the provider server 400 as historical information related to the provision of the service.

In this way, the service provision system 1 allows the card reader 200 to read the contents of the service card 100, thereby allowing the service provider to contact the user and provide the service. Because operating the card reader 200 is intuitive and simpler than operating a general-purpose information and communication terminal such as a personal computer or smartphone, even elderly people who are unfamiliar with general-purpose information and communication terminals can receive the same services as if they were using a general-purpose information and communication terminal. Furthermore, because the management server 300 transmits the user's contact information to the provider server 400, unlike conventional technology, the user does not need to enter into individual contracts (including registering contact information) with each service provider in advance.

(Appearance of card reader and service card)
The card reader 200 and the service card 100 according to this embodiment will be described with reference to Fig. 3. Fig. 3 is a schematic diagram showing an example of the appearance of the card reader 200 and the service card 100.

Service card 100 is a card issued by each service provider that stores information that can be read by card reader 200. Service card 100 may be any type of card as long as the information can be read by card reader 200, and may be, for example, a contactless communication IC card compatible with the FeliCa (registered trademark) system.

The card reader 200 (identifier reader) has an area formed in the housing for placing the service card 100, and a pressable operation button 210 is provided in part of the housing. The card reader 200 is equipped with a speaker 240 that provides audio guidance. The user places the service card 100 corresponding to the service provider from which they wish to receive a service in the card reader 200 and presses the operation button 210. When the operation button 210 is pressed, the card reader 200 reads the contents of the service card 100 placed in the housing and can send a service provision request to the service provider corresponding to the contents to the management server 300.

The card reader 200 may further include a display that provides text or visual information about the status of reading the contents of the service card 100 and the status of communication with the management server 300, and/or an LED light that provides information by emitting light.

(Configuration of the service provision system)
The configuration of a service providing system 1 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a block diagram showing an example of the configuration of the main parts of the service providing system 1.

The service provision system 1 is a system in which a user can use a service card 100 and a card reader 200 to receive services from a service provider that provides various services and operates a provider server 400. The service provision system 1 includes a service card 100, a card reader 200, a management server 300, and multiple provider servers 400 corresponding to multiple service providers.

The service card 100 is a card that is associated with a service provider that provides services through the service provision system 1, and whose internal information can be read by the card reader 200. The service card 100 has a card ID 110, which is a service identifier that uniquely identifies the service provider that is associated with the service card 100. In other words, in this embodiment, all of the multiple service cards 100 that can be used with the service provision system 1 are cards that have a card ID 110 and use a common format. The card ID 110 is different for each service provider.

The card reader 200 reads the card ID 110 of the service card 100 and transmits a service request to the service provider corresponding to the card ID to the management server 300. The card reader 200 includes an operation button 210, a memory unit 220, and a control unit 230. The control unit 230 includes a card reading unit 231, a service request unit 233, and an output control unit 235.

Operation button 210 is a button provided on the housing of card reader 200. Operation button 210 may be configured in any way so long as it can be intentionally operated by the user. Operation button 210 may be, for example, a lever.

The memory unit 220 stores various information handled by the card reader 200. The memory unit 220 stores a device ID 221. The memory unit 220 may also store information about the management server 300, to which it is connected, for example. The device ID 221 is a reader identifier for uniquely identifying the card reader 200. The device ID makes it possible to identify the user using the card reader 200.

The control unit 230 controls all the components of the card reader 200. When the control unit 230 detects that the operation button 210 has been pressed, it instructs the card reading unit 231 to read the card ID 110 of the service card 100. When the card reading unit 231 successfully reads the card ID 110, the control unit 230 instructs the service request unit 233 to send a service provision request to the management server 300.

The card reading unit 231 acquires the card ID 110 from the service card 100 installed in the card reader 200 in accordance with instructions from the control unit 230. The card reading unit 231 notifies the control unit 230 of the acquired result.

In accordance with instructions from the control unit 230, the service request unit 233 transmits the card ID 110 read from the service card 100 by the card reading unit 231 together with the device ID 221 to the management server 300 to request the provision of a service. The service request unit 233 may obtain the date and time of transmission, for example, using a timer (not shown), and transmit this together with the card ID 110 and device ID 221.

The output control unit 235 controls the audio output from the speaker 240.

The management server 300 is a server managed by the operating company that operates the service provision system 1. The management server 300 includes a memory unit 310 and a control unit 320. The memory unit 310 stores user information 311, service provider information 313, and service history information 315. The control unit 320 includes a request content analysis unit 321, a request content transfer unit 323, a history registration unit 325, and an information notification unit 327.

The memory unit 310 stores various information handled by the management server 300. User information 311 is information about the user, including personal information about the user that the user registered with the operating company of the service provision system 1 when applying to use the service provision system 1. The memory unit 310 stores, as user information 311, contact information for multiple users and the device IDs 221 of multiple card readers 200 distributed to the multiple users, in association with each other. Service provider information 313 is information about service providers that provide services through the service provision system 1. The memory unit 310 stores, as service provider information 313, multiple card IDs 110 in association with multiple service providers. Service history information 315 is history information about the provision of services in the service provision system 1 based on service provision requests received by the management server 300 from card readers 200. Specific examples of user information 311, service provider information 313, and service history information 315 will be described later using Figure 4.

The control unit 320 controls all parts of the management server 300. Depending on the content of the data sent and received by the management server 300, the control unit 320 instructs the history registration unit 325 to register the history of sending and receiving data in the service history information 315.

When the request content analysis unit 321 receives a service provision request from the card reader 200, it can analyze the received data. More specifically, the request content analysis unit 321 analyzes and extracts the card ID 110 and device ID 221 from the data received from the card reader 200. In other words, the request content analysis unit 321 functions as a receiving unit that receives from the card reader 200 the card ID 110 and device ID 221 that were read from the service card 100 by the card reader 200. If the data received from the card reader 200 contains information indicating the transmission date and time of the data, the request content analysis unit 321 may also extract this information.

Based on the analysis results by the request content analysis unit 321, the request content forwarding unit 323 forwards the request content to the provider server 400 corresponding to the service provider to whom the user has requested service provision. More specifically, the request content forwarding unit 323 identifies the service provider corresponding to the card ID 110 extracted by the request content analysis unit 321 from the service provider information 313. The request content forwarding unit 323 further identifies the user to whom the card reader 200 corresponding to the device ID 221 will be distributed from the user information 311. The request content forwarding unit 323 then transmits information regarding the identified user's contact information to the provider server 400 of the identified service provider. In other words, the request content forwarding unit 323 functions as a transmitting unit that transmits the user's contact information corresponding to the device ID 221 received from the card reader 200 to the provider server 400 of the service provider corresponding to the card ID 110 also received. At this time, the request content forwarding unit 323 may notify the provider server 400 to call the user's contact information. The request content forwarding unit 323 may obtain the transmission date and time using a timer (not shown) and transmit it to the business entity server 400 along with the above-mentioned information.

The history registration unit 325 registers information such as the date and time when processing related to the provision of a service was performed and the results of that processing in the service history information 315 in accordance with instructions from the control unit 320.

The provider server 400 is a server owned by a service provider that provides services to users in response to requests. The provider server 400 has a control unit 410, which has a request presentation unit 411 and a result notification unit 413. Note that while three provider servers 400 are shown in the illustrated example, the number of provider servers 400 is not limited to this. Furthermore, the provider server 400 may have a configuration for providing services in a different form in addition to a configuration for providing services in the service provision system 1. For example, the provider server 400 may further have a configuration for operating as a web server that provides a screen for accepting web reservations via the Internet to general-purpose information and communication terminals such as personal computers and smartphones.

The control unit 410 controls all the units of the provider server 400. When the control unit 410 receives a service provision request from the management server, it instructs the request presentation unit 411 to accept the provision request. The control unit 410 may also accept information input from the service provider using an input unit (not shown), and may output information using a display unit (not shown). For example, the control unit 410 may accept input from the service provider regarding whether or not the service provider has offered to provide a service to a user and the user has actually agreed to receive the service (whether or not consent was given, the date and time the offer was made, etc.), and provide the information to the result notification unit 413.

The request presentation unit 411, in accordance with instructions from the control unit 410, presents the service request received from the management server 300 to the service provider. More specifically, the request presentation unit 411 presents the fact that a new service request has been received, and the information contained in the request regarding the contact details of the requesting user, in a manner that the service provider can understand. The presentation may be by video or audio, or by email or other means sent to a mobile device such as a smartphone carried by the service provider. The service provider can determine the existence of a user who wishes to receive the service from the content presented by the request presentation unit 411, and can contact the user and provide the service. When the request presentation unit 411 accepts a service request from the management server 300, it may return to the management server 300 a notification that the acceptance has been completed, along with the date and time obtained using a timer (not shown).

The service provider offers to provide a service to the user based on the service request, and inputs the progress of the service provision into the provider server 400. The result notification unit 413 notifies the management server 300 of the service provision result (accepted, in progress, completed, or not yet concluded) indicating the progress of the service provision. The result notification unit 413 may also notify the management server 300 of information on the date and time when the service provider actually provided the service to the user, along with the provision result.

(Example of information configuration managed by the management server)
An example of the configuration of information managed by the management server 300 according to this embodiment will be described with reference to Fig. 4. Fig. 4 is a schematic diagram showing an example of the configuration of user information 311, service provider information 313, and service history information 315 stored in the storage unit 310 of the management server 300. Note that Fig. 4 is merely an example, and the user information 311, service provider information 313, and service history information 315 may have any configuration.

In the illustrated example, user information 311 includes three fields: "User ID," "Personal Information," and "Device ID." "Personal Information" is further subdivided into six fields: "Name," "Telephone Number," "Age," "Gender," "Address," and "Region." "User ID" is an identifier (user identifier) used by the management company that operates management server 300 to uniquely identify the person to whom the card reader 200 was distributed, i.e., the user of service provision system 1. "Personal Information" contains the user's personal information: "Name" contains the user's name; "Telephone Number" contains the user's telephone number; "Age" contains the user's current age; "Gender" contains the user's gender; and "Address" contains the user's current address. "Region" contains a regional identifier that can identify a region (e.g., Kanto, Kinki, etc.), prefecture, city, town, village, street, and/or street name. "Device ID" is an identifier that uniquely identifies the card reader 200 distributed to the user. In other words, in the illustrated example, there is a one-to-one correspondence between the "User ID" value and the "Device ID" value. In other words, the device ID also functions as a user identifier.

In the management server 300, the user information 311 is referenced, for example, when the request content forwarding unit 323 sends information about the user to the provider server 400. More specifically, the request content forwarding unit 323 determines whether a record exists whose "Device ID" value matches the device ID 221 extracted from the service request by the request content analysis unit 321. If the target record exists, the request content forwarding unit 323 sets the "Personal Information" value of that record as information about the user to be sent to the provider server 400. When the provider server 400 receives the "Personal Information" value as information about the user, the service provider can offer the service to the user by, for example, calling the phone number set in the "Phone Number" field. Note that the user's phone number, or other information such as an address or email address, may be used as the user's contact information.

The service provider information 313 includes five fields: "Service Provider ID," "Service Provider Name," "Service Notification Destination," "Card ID," and "Billing Data." The "Service Provider ID" is an identifier that uniquely identifies a service provider in the service provision system 1. The "Service Provider Name" is the name of the service provider. The "Service Notification Destination" is the destination (email address in the illustrated example) to which the request content forwarding unit 323 of the management server 300 forwards a service request to the service provider. The "Card ID" is set to the same value as the card ID 110 of the service card 100 corresponding to the service provider specified by the "Service Provider ID." In other words, in the illustrated example, the value of the "Service Provider ID" and the value of the "Card ID" have a one-to-one correspondence. The "Billing Data" sets the fee structure that the service provider specified by the "Service Provider ID" pays to the management server 300's operating company when providing a service using the service provision system 1. The fee structure may be a pay-as-you-go system based on the number of completed service provision transactions, or other systems such as a flat rate system. That is, the storage unit 310 stores, as service provider information 313, information relating to the amounts paid by multiple service providers when services are provided using the service provision system 1, in association with each other. For example, the management server 300 displays the contents of the "billing data" and service history information 315 on a display unit (not shown). The system provider can calculate the usage fees for the service provision system 1 for each service provider based on the displayed contents and bill each service provider.

In the management server 300, the service provider information 313 is referenced, for example, when the request content forwarding unit 323 forwards the request content to the provider server 400. More specifically, the request content forwarding unit 323 determines whether a record exists whose "Card ID" value matches the card ID 110 extracted from the service request by the request content analysis unit 321. If the target record exists, the request content forwarding unit 323 sets the value of the "Service notification destination" of that record as the contact information for the service provider from which the user who made the service request wishes to receive the service. The request content forwarding unit 323 can have the service provider offer to provide the service to the user by forwarding the service request to the forwarding destination set as the contact information for the service provider by email or other means.

Service history information 315 includes the following fields: "Service Management Number," "Service Provider ID," "User ID," "Card Reading Time," "Service Contact Time," "Service Acceptance Time," "Service Provision Time," and "Service Result." The "Service Management Number" is an identifier that uniquely identifies the history of service requests received by management server 300 from card reader 200. The "Service Provider ID" is set to the same value as the item with the same name in service provider information 313. The "User ID" is set to the same value as the item with the same name in user information 311. The "Card Reading Time" is set to the date and time when card reader 200 reads card ID 110 of service card 100. The "Service Contact Time" is set to the date and time when management server 300 received the service request from card reader 200. The "Service Acceptance Time" is set to the date and time when provider server 400 received the service request from management server 300. The "Service Provision Time" is set to the date and time when the service provider contacted the user and offered to provide the service. In other words, service history information 315 stores information about the history of when any processing was performed in at least one of card reader 200, management server 300, and provider server 400 from the time card reader 200 reads card ID 110 until the service provider provides the service to the user. "Service result" is set to the service provision result that indicates the progress of service provision.

The service history information 315 contains the history of processing performed by the card reader 200, management server 300, or business server 400 in the service providing system 1, which is aggregated and stored in the management server 300.

First, a service request is sent from card reader 200 to management server 300 along with the date and time when card ID 110 of service card 100 was read. When management server 300 receives a new service request, it sets a new service management number for the request. The history registration unit 325 adds the user ID of the user who owns card reader 200 that sent the request, identified from the received service request, and the service provider ID corresponding to card ID 110, along with the date and time when card ID 110 was read, as a new record to service history information 315. That is, at this point, values have been set for "service management number," "service provider ID," "user ID," and "card read time," but values have not been set for "service contact time," "service acceptance time," "service provision time," and "service result."

Next, when the request content forwarding unit 323 forwards the service request to the provider server 400, the history registration unit 325 sets the date and time when the service request was forwarded to the "service contact time," for which a value has not been set. After that, when the management server 300 receives a notification from the provider server 400 indicating that the service request has been accepted, the history registration unit 325 sets the date and time when the provider server 400 received the service request, which is included in the notification, to the "service acceptance time," for which a value has not been set.

The service provider then contacts the user and offers to provide the service, and the service provider notifies the management server 300 of the results of the offer using the provider server 400. The history registration unit 325 sets the date and time the service was offered and the progress of the service based on whether the user ultimately agreed to the service in the "Service provision time" and "Service result" fields, respectively, contained in the notification.

In this way, the history registration unit 325 can aggregate and store the processing history in the service providing system 1 in the service history information 315.

(Processing flow)
The flow of processing in the service providing system 1 according to this embodiment will be described with reference to Fig. 5. Fig. 5 is a sequence diagram showing an example of the flow of processing in the service providing system 1.

First, the user places the service card 100 corresponding to the service provider from which they wish to receive a service in the card reader 200 and presses the operation button 210. The card reader 200 reads the card ID 110 of the service card 100 and transmits data including its own device ID 221, the read card ID 110, and the time the card ID was read to the management server 300 (S1: Service provision request).

When the management server 300 receives a service request from the card reader 200, it assigns a new service management number to the request and analyzes the request using the request content analysis unit 321 (S2: Request Content Analysis). The management server 300 then uses the request content forwarding unit 323 to identify the user's personal information and the contact information for the service provider's provider server 400. The management server 300 then transmits the service management number assigned in S2, along with the user's personal information and the date and time the service request is to be forwarded, to the contact information for the service provider's provider server 400 (S3: Request Content Forwarding). At this time, the management server 300 adds a history of the forwarding of the service request to the service history information 315 using the history registration unit 325. Furthermore, once the forwarding of the service request is complete, the management server 300 notifies the card reader 200 of the completion of the forwarding (S4: Forwarding Notification). Based on the notification, the card reader 200 notifies the user, by voice or other means, that the service request has been forwarded to the provider server 400.

On the service provider side, when the provider server 400 receives the service request forwarded from the management server 300, the provider server 400 notifies the service provider of the request contents (S5: Request acceptance). The provider server 400 then notifies the management server 300 of the date and time when the service request was accepted, along with the service management number sent from the management server 300 in S3 (S6: Acceptance notification).

When the management server 300 receives notification from the business server 400 that the service request has been accepted, it notifies the card reader 200 that the service request has been accepted by the business server 400, along with information on the date and time sent from the business server 400 in S6 (S7: Acceptance completion notification). Based on the notification, the card reader 200 notifies the user by voice or other means that the service request has been forwarded to the business server 400.

After S6 and S7, the service provider uses the user's personal information received by the provider server 400 from the management server 300 in S3 to contact the user by telephone or other means and offer to provide the service (S8: Service provision). Note that since the service provider cannot detect that processing in S7 has been completed, processing in S8 may be performed before processing in S7, but this does not pose a problem.

When the user receives a service offer from the service provider through the processing of S8, after receiving a detailed explanation of the service, the user notifies the service provider of their intention to actually use the service (S9: Notification of service use).

When the service provider receives notification from the user regarding whether or not the service will be used through the processing of S9, the service provider uses the provider server 400 to transmit to the management server 300 the service management number received from the management server 300 in S3 along with the user's personal information, along with the date and time the service provision offer was made (service provision time) and the progress of the service provision (service result) (S10: Service provision result notification). Note that if the user notified the service provider in S9 that they will be using the service, the processing of S10 may be performed after the service provider provides the service to the user. In this case, the service provision time may be the date and time the service was actually provided. The management server 300 then uses the history registration unit 325 to add and register the information received from the provider server 400 to the service history information 315.

Through the above process, in the service providing system 1 according to this embodiment, when the card reader 200 reads the card ID 110 of a specific service card 100 selected by the user from multiple service cards 100, the user's contact information is sent to the service provider server 400 of the service provider corresponding to the card ID 110. As a result, the user is contacted by the service provider corresponding to the card ID 110 of the specific service card 100, and can receive services from that service provider. As a result, compared to selecting a desired service provider using a general-purpose information and communications terminal such as a PC or smartphone, the user can receive services from the service provider simply by having the card reader 200 read the selected service card 100.

In addition, because the management server 300 centrally manages contact information for users and service providers, users do not need to enter into individual contracts with each service provider. Therefore, users can receive new services from the corresponding service provider simply by inserting their newly acquired service card 100 into the card reader 200.

In order to participate in the service provision system 1, service providers must register their contact information with the management server 300. Therefore, for example, the operating company of the management server 300 can select service providers to participate in the service provision system 1, thereby creating an environment in which users can use the system with peace of mind and improving the brand image of the system. Therefore, even people who are unfamiliar with operating information and communication terminals can receive the same services from service providers as if they were using an information and communication terminal, making it possible to realize a highly convenient service provision system.

[Modification]
The operating company of the management server 300 may revise the fee structure that the service provider pays to the operating company of the management server 300 based on the history information accumulated in the service history information 315. For example, if the ratio of the number of cases in which the service was actually provided to the number of service provision requests is high, it may be determined that the user is satisfied with the service provided using the service provision system 1, and this may be used as a basis for lowering the fee.

The management server 300 may also analyze the history information stored in the service history information 315 to analyze the trends in services used by each user. Based on the analysis results, for example, the operating company of the management server 300 may send a new service card 100 corresponding to a new service provider depending on the user's trends.

(Business notification information)
The control unit 410 of the business server 400 may transmit, at any timing, notification conditions indicating a specific user and business notification information to be notified to the specific user to the management server 300. For example, the notification conditions may include conditions such as a specific region, a specific age, and/or a specific gender. For example, the business notification information may be an introduction to a product of the business.

The information notification unit 327 of the management server 300 receives business notification information and notification conditions from the business server 400. The information notification unit 327 references the user information 311 stored in the memory unit 310 and determines whether each user's personal information (address, age, gender, etc.) meets the notification conditions. The information notification unit 327 transmits the business notification information to the card reader 200 of the user who meets the notification conditions.

The output control unit 235 of the card reader 200 receives the business notification information from the management server 300. The output control unit 235 outputs the business notification information as audio from the speaker 240. The business notification information may be audio data or text data. If the business notification information is text data, the output control unit 235 converts the text data into audio data and outputs the audio from the speaker 240.

(Personal Notification Information)
The card reader 200 may notify the user of information unrelated to the business by voice. For example, the user is given a personal card (personal identifier object) unique to the user in addition to the service card 100. The personal card records the user's user identifier. The card reader 200 may notify the user of the personal notification information by voice when the user holds the personal card over the card reader 200 and reads the user's user identifier from the personal card.

Specifically, the card reading unit 231 reads the user's user identifier from the personal card. The service request unit 233 associates the user identifier with the device ID 221 and transmits them to the management server 300.

When the information notification unit 327 of the management server 300 receives the user identifier, it references the user information (personal information). The information notification unit 327 determines the personal notification information to be notified to the user based on the area in which the user lives or pre-registered information. The personal notification information may include, for example, the weather in the area in which the user lives, local news, the time the user should take their medication, or the current time. The time the user should take their medication may be registered in advance as user information. The information notification unit 327 may obtain local weather and local news from a server other than the business server 400. The information notification unit 327 transmits the personal notification information to be notified to the user to the card reader 200.

The output control unit 235 of the card reader 200 receives the personal notification information from the management server 300. The output control unit 235 outputs the personal notification information as audio from the speaker 240. The personal notification information may be audio data or text data.

Alternatively, the card reader 200 may notify the user of the personal notification information by voice at a specified time.

Specifically, the time (predetermined time) at which the personal notification information should be notified is stored in advance as user information in the storage unit 310 of the management server 300. The information notification unit 327 transmits the personal notification information to the card reader 200 at the predetermined time. The output control unit 235 of the card reader 200 outputs the personal notification information as sound from the speaker 240.

The management server 300 may also send personal notification information to any number of users. For example, to the card readers 200 of multiple users living in a certain area, the management server 300 may send information about the weather in that area, news about that area, or evacuation information related to that area. For example, to the card readers 200 of multiple users who belong to a certain organization, the management server 300 may send information about that organization. For example, common information may be sent to all users.

Incidentally, a service provided by the management server 300 may be started by first having the card reader 200 read the user identifier of the personal card. The card reader 200 associates the read user identifier with the device ID 221 and transmits it to the management server 300. The management server 300 references pre-stored user information 311 and confirms whether the association between the user identifier and the device ID 221 is correct. If the association is correct, the management server 300 starts the service provided by the service providing system 1.

[Embodiment 2]
Other embodiments of the present invention will be described below. For ease of explanation, the same reference numerals will be used to designate components having the same functions as those described in the above embodiment, and the description thereof will not be repeated.

Figure 6 is a block diagram showing an example of the main configuration of service provision system 1a. In service provision system 1a, users are given a service card for requesting the provision of the above-mentioned services, as well as a service card for informing others of the user's own health status. The other person is, for example, a family member living far away, or a member of a social welfare organization in the user's area (such as a welfare officer or social welfare council employee), who is a person (verifier) responsible for watching over the user. The user can notify the verifier that the user is healthy (in good health) by having card reader 200 read the contents of the service card indicating that the user is healthy (in good health). Service provision system 1a can also monitor users who are, for example, elderly.

The service provision system 1a includes a card reader 200, a management server 300a, and business servers 400, 400a corresponding to multiple service providers. The configurations of the card reader 200 and business server 400 are the same as in embodiment 1, so detailed explanations will be omitted. The processing of the management server 300a and business server 400 when a service card requesting the provision of a service is read by the card reader 200 is the same as in embodiment 1. Note that the business server 400 is omitted from Figure 6.

The card reader 200 obtains the card ID from the service card indicating the health status. The card reader 200 transmits the card ID read from the service card along with the device ID to the management server 300a.

(Management Server Configuration)
The management server 300a includes a memory unit 310a and a control unit 320a. The memory unit 310a stores user information 311, service provider information 313, service history information 315, status history information 316, and destination information 317. The control unit 320a includes a request content analysis unit 321, a request content transfer unit 323, a history registration unit 325, a result acquisition unit 324, an information notification unit 327, a determination unit 328, and a first promotion notification unit 329. The determination unit 328 includes a learning unit 330.

Figure 7 is a schematic diagram showing an example configuration of destination information 317. Figure 7 is merely an example, and destination information 317 may have any configuration. Destination information 317 has the fields "User ID," "Card ID," and "Destination." "Destination" includes information on the service type and the checker's notification destination. The service type indicates the notification method, such as email, messaging app, or short mail. The checker's notification destination is the checker's notification destination corresponding to the service type, and indicates, for example, an email address, messaging app account, or phone number to which short mail notifications will be sent. The card ID of the service card indicating the health status is stored in destination information 317.

The request content analysis unit 321 extracts the card ID and device ID from the data received from the card reader 200. The request content analysis unit 321 outputs the card ID and device ID to the request content transfer unit 323.

The request content forwarding unit 323 determines whether the received card ID indicates a request for the service provider to provide a service or a request to inform the checker of the user's health condition. Specifically, the request content forwarding unit 323 determines whether the received card ID is included in the service provider information 313 or the destination information 317. The request content forwarding unit 323 acquires the destination corresponding to the card ID from the destination information 317. The request content forwarding unit 323 notifies the checker of the user information and the user's health condition via the provider server 400a corresponding to the destination. Specifically, the request content forwarding unit 323 transmits the checker's destination information, the user information, and the user's health condition to the provider server 400a corresponding to the destination's service type. For example, if the destination's service type is a messaging app, the provider server 400a is a server of a provider that provides the messaging app function. If the destination's service type is short message, the provider server 400a is a server of a mobile communications provider that provides the short message function. If the destination service type is email, the carrier server 400a is the mail server of the telecommunications carrier that corresponds to the verifying party's email address.

The result acquisition unit 324 receives information indicating the user (e.g., user ID), the check results for the user's health condition, and information indicating the date and time of the check from the result notification unit 413 of the business operator server 400a. The result acquisition unit 324 outputs the received information indicating the user (e.g., user ID), the check results for the user's health condition, and information indicating the date and time of the check to the history registration unit 325.

The history registration unit 325 associates the service history of the user with the user's user ID and stores it in the storage unit as service history information 315a. The service history includes a history of service requests made by the user or a history of services provided to the user by the service provider.

The history registration unit 325 also registers the history of requests to inform the checker of the user's health condition in the condition history information 316, in association with the user ID. The condition history information 316 includes information regarding the request to inform the checker of the user's health condition, such as the user ID, the user's health condition, the time the card was read, and the time of contact from the management server 300a to the business server 400a. The history registration unit 325 also registers the check results of the user's health condition by the checker and the time (date and time) of the check in the condition history information 316, in association with the user ID. The condition history information 316 includes the history of requests to inform the checker of the user's health condition, and history related to the check results of the user's health condition.

The determination unit 328 determines whether or not the user's health condition needs to be checked based on the service history. The determination unit 328 outputs the determination result to the first promotion notification unit 329.

If it is determined that a health condition check is required, the first prompt notification unit 329 notifies the checker to check the user's health condition. Specifically, the first prompt notification unit 329 obtains the address corresponding to the user ID from the address information 317. If there are multiple addresses corresponding to the user ID, the first prompt notification unit 329 may obtain multiple addresses. The first prompt notification unit 329 transmits information about the checker's address, user information, and a message prompting the checker to check the user's health condition to the business server 400a corresponding to the address. As a result, the first prompt notification unit 329 notifies the checker's checker terminal 500 of the user information and the message prompting the checker to check the user's health condition via the business server 400a corresponding to the address. The checker is notified of the user information and the message by, for example, email, a messaging app, or short mail.

(Configuration of business server)
The business entity server 400a includes a control unit 410. The control unit 410 includes a request presentation unit 411, a result notification unit 413, and a second promotion notification unit 415.

The request presentation unit 411 receives information about the verifyer's address, user information, and the user's health condition from the request content transfer unit 323 of the management server 300a. The request presentation unit 411 transmits the user information and the user's health condition to the verifyer terminal 500 corresponding to the verifyer's address. In addition to "name," the user information notified to the verifyer may also include, for example, "telephone number," "age," "gender," "address," and/or "area."

The result notification unit 413 accepts input of the health status check results and the date and time of the check for the user from the checker's terminal 500. The result notification unit 413 transmits information indicating the user (e.g., user ID), the health status check results for the user, and information indicating the date and time of the check to the management server 300a.

The second prompt notification unit 415 receives information about the checker's address, user information, and a message prompting the user to check their health condition from the first prompt notification unit 329 of the management server 300a. The second prompt notification unit 415 transmits the user information and a message prompting the user to check their health condition to the checker terminal 500 corresponding to the checker's address.

Figure 8 shows an example of part of the processing flow of the control unit 320a of the management server 300a. The history registration unit 325 associates the history of service requests made by users or the history of service provision to users by service providers with the user ID and stores it in the storage unit 310a (S21).

The result acquisition unit 324 acquires the results of the user's health condition check and information indicating the date and time of the check from the business operator server 400a. The history registration unit 325 associates the results of the user's health condition check and information indicating the date and time of the check with the user's user ID and stores them in the storage unit 310a (S22).

The learning unit 330 performs learning using the service history as input and the results of checking the user's health condition as output (S23). Note that learning step S23 can be omitted, as described below.

The determination unit 328 determines whether or not the user's health condition needs to be checked based on the service history (S24). The determination unit 328 makes this determination at a predetermined timing (e.g., periodically).

If it is determined that a health status check is required (Yes in S24), the first prompt notification unit 329 sends a notification to the checker prompting them to check the user's health status (S25).

If it is determined that health status confirmation is not required (No in S24), the first prompt notification unit 329 does not send a notification to the person checking the user's health status.

(Processing of the judgment unit)
For example, if the frequency of service use decreases or the intervals between service use increases, it can be inferred that there may be an abnormality in the user's health condition. The criteria for determining whether or not the determining unit 328 needs to check the user's health condition may be set in advance, or may be learned using the learning unit 330. In the former case, the determining unit 328 does not need to include the learning unit 330.

For example, since no service history has been accumulated for a user who has just started using the service, the judgment unit 328 may determine whether or not the user's health condition needs to be checked based on the condition history information 316. For example, the judgment unit 328 may determine that the user's health condition needs to be checked if the user has not used a service card indicating their health condition for a predetermined period of time or longer.

The determination unit 328 may, for example, determine whether or not the user's health condition needs to be checked by comparing the frequency of the user's use of the service in a first period with the frequency of the user's use of the service in a second period that precedes the first period. For example, if the value obtained by subtracting the frequency of use of the service in the first period from the frequency of use of the service in the second period is equal to or greater than a predetermined value, the determination unit 328 may determine that the frequency of use has decreased and that the health condition needs to be checked.

The determination unit 328 may, for example, determine whether or not the user's health condition needs to be checked by comparing the interval between service usage in a first period with the interval between service usage in a second period that precedes the first period. For example, if the representative value (average value, maximum value, etc.) of the interval between service usage in the first period is larger (longer) by a predetermined value or more than the representative value (average value, maximum value, etc.) of the interval between service usage in the second period, the determination unit 328 may determine that the interval between usage has become longer and that the health condition needs to be checked. The representative value of the interval between service usage in the first period may be the period from the present to the most recent use of the service (i.e., the period during which no service usage has continued up to the present).

In this way, the judgment unit 328 determines that a health check is necessary if there is a change in the characteristics of the user's most recent service usage compared to the characteristics of the user's past service usage, based on the service history. The service history may include any of the time the card was read, the time the service was contacted, the time the service was accepted, and the time the service was provided.

(Processing of decision unit using learning)
The learning unit 330 performs learning using the service history as input and the confirmation result of the user's health status as output. For example, the learning unit 330 uses the service history from the most recent period prior to the time (date and time) when the checker checked the user's health status as input. The learning unit 330 uses the health status confirmation result (healthy, caution required, urgent action required, etc.) from the check as output. This allows the learning unit 330 to learn the relationship between the characteristics of the service history over a certain period and the subsequent health status (generating a learning model). Therefore, the trained learning unit 330 can infer the user's current health status from the service history over the most recent period. The service history may include the card reading time, the service contact time, the service reception time, the service provision time, and the service provider ID (information corresponding to the type of service (shopping, taxi, hospital, etc.)). The learning algorithm can be performed using a known algorithm.

The judgment unit 328 uses the user's service history as input to the learning unit 330 and obtains an estimated result of the user's health condition from the learning unit 330. For example, if the estimated result of the health condition does not indicate health (such as requiring caution or urgent action), the judgment unit 328 determines that the user's health condition needs to be checked, and if the estimated result indicates health, the judgment unit 328 determines that the user's health condition does not need to be checked. For example, the estimated result of the health condition may be expressed as a probability. If the probability of not being healthy in the estimated result is equal to or greater than a predetermined value, the judgment unit 328 may determine that the estimated result of the health condition is "requiring caution" (health condition check required).

A learning model trained using the service history and health status check results of one user may be used to estimate the health status of another user. Furthermore, a learning model trained using the service history and health status check results of one user may be modified (additional learning) using the service history and health status check results of another user.

The first promotion notification unit 329 may obtain the estimated result of the user's health condition from the determination unit 328 and transmit it to the verifying terminal 500 via the business operator server 400a. The first promotion notification unit 329 may change the message sent to the verifying terminal 500 depending on the estimated result of the user's health condition (such as caution or urgent action required).

The service provision system 1a of this embodiment allows for monitoring of users, such as elderly people, based on service history. For example, a social welfare officer or social welfare council employee who is the person in charge of monitoring can efficiently visit the user at an appropriate time and check the user's health condition.

[Embodiment 3]
Further, for the sake of convenience, the same reference numerals will be used to designate components having the same functions as those described in the above embodiment, and the description thereof will not be repeated.

Figure 9 is a block diagram showing an example of the main configuration of service provision system 1b. Figure 10 is a perspective view showing an example of the configuration of card reader 200b. Service provision system 1b includes card reader 200b instead of card reader 200 of service provision system 1. Service provision system 1b also includes management server 300b instead of management server 300 of service provision system 1.

The service provision system 1b is a system in which users can send spoken information to a verifying person using a card reader 200b and multiple service cards 100 that have been distributed to them in advance. Users can begin using the service provision system 1 by registering the verifying person's address, along with their own personal information, with the operating company (system operator) that operates the management server 300. The verifying person (the recipient of the spoken information) is, for example, a local welfare officer or social welfare council employee in the user's area, or the user's family member.

As shown in Figures 9 and 10, card reader 200b differs from card reader 200 in that it further includes a display unit 250 and a microphone 260. Furthermore, control unit 230b of card reader 200b includes an output control unit 235, a service request unit 233, a card reading unit 231, a speech acquisition unit 239, and an operation input unit 237.

The output control unit 235 may display the personal notification information acquired as text data on the display unit 250.

When the operation button 210 is pressed (when the operation unit is operated), the operation input unit 237 instructs the card reading unit 231 to read the card ID 110. Furthermore, when the operation button 210 is pressed (when the operation unit is operated), the control unit 230b instructs the speech acquisition unit 239 to acquire the user's speech.

Here, the operation input unit 237 may instruct the utterance acquisition unit 239 to continue recording the user's utterance while the operation button 210 is being pressed. Alternatively, the operation input unit 237 may instruct the utterance acquisition unit 239 to start recording when the operation button 210 is pressed for the first time, and to end recording when the operation button 210 is pressed for the second time. Alternatively, the operation input unit 237 may instruct the utterance acquisition unit 239 to continue recording the user's utterance for a predetermined period after the operation button 210 is pressed.

The card reading unit 231 reads the card ID 110 (destination identifier) corresponding to the destination from the service card 100 (destination identification object) in accordance with instructions from the operation input unit 237. The card reading unit 231 outputs the read card ID 110 to the service request unit 233.

The speech acquisition unit 239 acquires the user's speech as voice data from the microphone 260 provided in the card reader 200b in accordance with instructions from the operation input unit 237. The speech acquisition unit 239 outputs the acquired voice data to the service request unit 233 as speech information indicating the user's speech. The speech acquisition unit 239 may also convert the acquired voice data into text data and output the text data to the service request unit 233 as speech information indicating the user's speech.

The service request unit 233 (reader transmission unit) acquires the card ID 110 from the card reading unit 231. The service request unit 233 also acquires speech information associated with the card ID 110 from the speech acquisition unit 239. The service request unit 233 transmits to the management server 300b an instruction to transmit the speech information indicating the user's speech acquired by the speech acquisition unit 239, along with the card ID 110 and the device ID 221. Here, the service request unit 233 associates the card ID 110 with the speech information and transmits an instruction to the management server 300b to transmit the speech information.

As shown in FIG. 9, the management server 300b has destination information 317 in the memory unit 310b.

Destination information 317 is information about multiple destinations registered with the operating company of service provision system 1b when the user applied to use service provision system 1b. Note that the destinations here include the service type used by the verifyer to receive the user's speech information and the verifyer's notification destination registered for that service type (see Figure 7). Memory unit 310b stores multiple card IDs 110 associated with multiple destinations as destination information 317.

The request content analysis unit 321 analyzes and extracts the speech information, along with the card ID 110 and device ID 221, from the data received from the card reader 200b.

Based on the analysis results by the request content analysis unit 321, the request content transfer unit 323 transfers an instruction to send utterance information to the business server 400 corresponding to the service type used by the checker. More specifically, the request content transfer unit 323 identifies the checker's address (i.e., the service type used by the checker and the checker's notification destination) corresponding to the card ID 110 extracted by the request content analysis unit 321 from the destination information 317. The request content transfer unit 323 further identifies the user to whom the card reader 200b corresponding to the device ID 221 will be distributed from the user information 311. The request content transfer unit 323 then transmits the identified checker's notification destination, information related to the identified user's contact information, and the utterance information to the business server 400 corresponding to the identified service type.

The operator server 400 is a server that transmits information about the user's contact details and speech information to the recipient of the checker's notification. When the control unit 410 receives an instruction to transmit speech information from the management server 300, it transmits the information about the user's contact details and speech information to the recipient of the checker's notification. For example, if the operator server 400 is a mail server of a telecommunications company, the control unit 410 sends an email to the terminal owned by the checker presenting information about the user's contact details and speech information.

An example of the configuration of information managed by the management server 300b according to this embodiment will be described using Figure 7. Figure 7 is a schematic diagram showing an example of the configuration of destination information 317 stored in the memory unit of the management server 300b.

Destination information 317 has three items: "User ID," "Card ID," and "Confirmer's Address," with "Confirmer's Address" further subdivided into two items: "Service Type" and "Notification Destination." A "User ID" uniquely identifies a user of service provision system 1b, and multiple "Card IDs" corresponding to multiple service cards 100 distributed to that user are set. "Confirmer's Address" is the address to which the user's speech information is sent. "Service Type" is the service type used by the confirmer to receive the user's speech information. "Notification Destination" is the notification destination of the confirmer registered in the business server 400. Destination information 317 associates "Card ID" with "Confirmer's Address," and card ID 110 functions as a destination identifier.

As shown in FIG. 7, the service type is, for example, email, a message app, or a short message. If the service type is email, an email address is stored in the destination information 317 as the recipient of the checker's notification. If the service type is a message app, an account is stored in the destination information 317 as the recipient of the checker's notification. If the service type is a short message, a phone number is stored in the destination information 317 as the recipient of the checker's notification.

In this way, the card reader 200b can transmit speech information indicating the user's speech to a destination corresponding to the card ID 110 of the service card 100. In other words, by simply reading the service card 100 and pressing an operation button (operating the operation unit), the user can send speech information to a specific destination from among multiple destinations. The user can specify a destination by selecting the service card 100 (destination identification object) that corresponds to the destination. Furthermore, the user can issue both a transmission instruction and specify the recording period with a simple operation, which is easy for the user to understand. Furthermore, the verifying person can receive speech information indicating the user's speech using the service type they desire.

[Embodiment 4]
Further, for the sake of convenience, the same reference numerals will be used to designate components having the same functions as those described in the above embodiment, and the description thereof will not be repeated.

(Configuration of card reader 200c)
Fig. 11 is a block diagram showing an example of the configuration of the main parts of the service providing system 1c. Fig. 12 is a perspective view showing an example of the configuration of a card reader 200c. The service providing system 1c includes a card reader 200c (identifier reader) instead of the card reader 200 of the service providing system 1. Furthermore, the service providing system 1c includes a management server 300c instead of the management server 300 of the service providing system 1.

In service provision system 1c, in addition to a service card for requesting the provision of the above-mentioned services, users are also given a service card for informing the verifyer of the user's exercise status. The exercise status may be, for example, a state in which the user is out (exercising, such as walking) or a state in which the user is performing exercises (exercising), such as radio calisthenics. For example, by placing a service card indicating the user's out status in card reader 200, the user can notify the verifyer that the user is out.

As shown in FIG. 11, the control unit 230c of the card reader 200c includes an output control unit 235, a reader transmission unit 232, a card reading unit 231, and an operation input unit 237. Furthermore, as shown in FIG. 12, the card reader 200c is formed with an installation unit 290 for installing the service card 100. The service card 100 is held by the card reader 200c by installing it in the installation unit 290.

The card reading unit 231 (reading unit) reads the card ID 110 (exercise identifier) corresponding to the user's exercise from the service card 100 (exercise identification object) installed in the installation unit 290. The card reading unit 231 also obtains the reading time when the card ID 110 is read using a timer (not shown). The card reading unit 231 notifies the reader transmission unit 232 of the read card ID and reading time.

The card reading unit 231 periodically communicates with the service card 100 while the service card 100 is installed in the installation unit 290. This allows the card reading unit 231 to determine whether the service card 100 has been removed from the installation unit 290. When the card reading unit 231 determines that the service card 100 has been removed, it obtains the removal time of the service card 100 using a timer (not shown). The card reading unit 231 notifies the reader transmission unit 232 that the service card 100 has been removed and the removal time.

The reader transmission unit 232 transmits the card ID 110 read by the card reading unit 231 from the service card 100, the device ID 221 (the user's user identifier), and the read time when the card reading unit 231 read the card ID 110 (information indicating that the card ID 110 was read) to the management server 300c. The reader transmission unit 232 also transmits the removal time when the service card 100 was removed (information indicating that the service card 100 was removed) together with the card ID 110 and the device ID 221 to the management server 300c.

The output control unit 235 controls the speaker 240 and/or the display unit 280 (notification unit). Specifically, the output control unit 235 acquires information indicating whether the service card 100 has been removed from the card reading unit 231 at a predetermined timing after the card reading unit 231 reads the card ID 110. The predetermined timing is, for example, every hour after the card reading unit 231 reads the card ID 110. If the service card 100 has not been removed at the predetermined timing, the output control unit 235 controls the speaker 240 and/or the display unit 280 to notify the user to remove the service card 100. For example, the speaker 240 notifies the user to remove the service card 100 from the installation unit 290 by outputting a voice message saying, "Please remove the card when you get home." Additionally, the display unit 280 may issue a notification urging the user to remove the service card 100 from the installation unit 290 by flashing an LED (light emitting diode) included in the display unit 280.

Here, when the operation button 210 (operation unit) is pressed, the output control unit 235 may stop control of the speaker 240 and/or the display unit 280. For example, from a crime prevention perspective, it is undesirable for the notification unit to continue sending notifications while the user is out. Therefore, when the user is out, the user can stop such notifications from the notification unit by pressing the operation button 210.

Furthermore, the output control unit 235 may use the reading of the card ID 110 by the card reading unit 231 as a trigger to cause the speaker 240 (audio output unit) to output a predetermined sound corresponding to the card ID 110. For example, when the card reading unit 231 reads a service card 100 for notifying that the user is out, the speaker 240 outputs the sound "Take care." Or, when the card reading unit 231 reads a service card 100 for notifying that the user is doing radio calisthenics, the speaker 240 outputs the sound of radio calisthenics. The sound output by the speaker 240 is stored in the memory unit 220 of the card reader 200c. The sound output by the speaker 240 may be obtained from the management server 300c.

(Configuration of management server 300c)
11 , the management server 300c includes a storage unit 310c and a control unit 320c. The storage unit 310c stores user information 311, exercise information 319, and exercise history information 312. The control unit 320 includes an analysis unit 322, an information provision unit 326, a history registration unit 325, and a determination unit 328. The management server 300c according to this embodiment is, for example, a server managed by an operating company that operates the service provision system 1. For example, the management server 300c also functions as a web server.

Figure 13 is a schematic diagram showing an example of the configuration of exercise information 319. Figure 13 is merely an example, and exercise information 319 may have any configuration. Exercise information 319 has the fields "User ID," "Card ID," and "Exercise details." "Exercise details" is information about the type of exercise performed by the user. The exercise details are stored in exercise information 319 in association with card ID 110.

Figure 14 is a schematic diagram showing an example of the configuration of exercise history information 312. Figure 14 is merely an example, and exercise history information 312 may have any configuration. Exercise history information 312 has the following fields: "Sent time," "Personal information," and "Exercise status." "Sent time" is the reading time or removal time sent from the reader transmitting unit 232. "Personal information" includes the user ID and various pieces of information related to the user's personal information. "Exercise status" is information indicating whether the exercise corresponding to card ID 110 has started or ended.

The analysis unit 322 (receiving unit) analyzes and extracts the card ID 110, device ID 221, and read or removal time from the data received from the card reader 200c.

Based on the analysis results by the analysis unit 322, the information providing unit 326 (transmitting unit) transmits the exercise status, the user's contact information, and the reading or removal time to the verifying terminal 500. Specifically, the information providing unit 326 identifies the details of the exercise corresponding to the card ID 110 extracted by the analysis unit 322 from the exercise information 319 (see Figure 13). The information providing unit 326 also identifies the exercise status of the exercise corresponding to the card ID 110 depending on whether the reading time or the removal time was acquired. For example, if the information providing unit 326 acquires the reading time, it determines that the exercise corresponding to the card ID 110 has started. If the information providing unit 326 acquires the removal time, it determines that the exercise corresponding to the card ID 110 has ended (see Figure 14). Furthermore, the information providing unit 326 identifies the user's personal information, including the user's contact information, corresponding to the device ID 221 from the user information 311. The information providing unit 326 stores the reading time or removal time, the exercise status identified using the above method, and the user's contact information in exercise history information 312 on the storage unit 310c via the history registration unit 325 (described below). The checker receives the exercise history information 312 on the storage unit 310c, for example, using a web application installed on the checker terminal 500.

The history registration unit 325 obtains the user's personal information, exercise status, and reading or removal time from the information provision unit 326 and registers them in the exercise history information 312. In other words, the history registration unit 325 registers the exercise history, which is the history of the user's transmission of the card ID 110, in association with the user's personal information, including the user ID, in the exercise history information 312.

The determination unit 328 may determine whether or not the user's health condition needs to be checked based on the exercise history. For example, if the determination unit 328 determines that the health condition needs to be checked, the management company that manages the management server 300c will check the user's health condition. Alternatively, the determination unit 328 may send the determination result to the checker terminal 500, and the checker will check the user's health condition.

(Example of operation of card reader 200c)
15 is a flowchart showing the process of the control unit 230c of the card reader 200c. The process of the control unit 230c transmitting the user's exercise status to the management server 300c will be described below with reference to FIG.

As shown in FIG. 15, first, the card reading unit 231 reads the card ID 110 from the service card 100 installed in the installation unit 290 (S41). The card reading unit 231 also obtains the read time of the card ID 110 using a timer (not shown) (S42). The card reading unit 231 notifies the reader transmission unit 232 of the read card ID 110 and the read time. The reader transmission unit 232 transmits the card ID 110, device ID 221, and the read time to the management server 300c (S43).

Next, the card reading unit 231 determines whether the service card 100 has been removed from the installation unit 290 (S44). If the service card 100 has not been removed from the installation unit 290 (NO in S44), the output control unit 235 controls the speaker 240 and/or the display unit 280 to issue a notification urging the user to remove the service card 100 at a predetermined timing (S45). If the service card 100 has been removed from the installation unit 290 (YES in S44), the card reading unit 231 obtains the removal time of the service card 100 using a timer (not shown) (S46). The card reading unit 231 notifies the reader transmission unit 232 that the service card 100 has been removed and the removal time. The reader transmission unit 232 transmits the card ID 110, the device ID 221, and the removal time to the management server 300c (S47).

(Example of operation of management server 300c)
16 is a flowchart showing the processing of the control unit 320c of the management server 300c. The processing of the control unit 320c transmitting the user's exercise status to the reviewer will be described below with reference to FIG.

As shown in FIG. 16, first, the analysis unit 322 receives the card ID, device ID, and reading or removal time from the reader transmission unit 232 (S51). That is, the analysis unit 322 analyzes and extracts the card ID 110, device ID 221, and reading or removal time from the data received from the card reader 200c. Next, the information providing unit 326 identifies the exercise status and the user's contact information based on the information stored in the memory unit 310c (S52). Next, the information providing unit 326 transmits the exercise status, the user's contact information, and the reading or removal time to the verifying terminal 500 (S53). The information providing unit 326 may transmit this information, such as the exercise status, to the verifying terminal 500 in response to a request from the verifying terminal 500. Furthermore, when the information providing unit 326 receives new data from the card reader 200c, it may transmit this information, such as the exercise status, to the verifying terminal 500. The verifying terminal 500 acquires information such as the status of exercise using a web application or web browser, and displays that information. The verifying person can check the user's health condition by checking the type of exercise (going out, exercising, etc.), frequency, duration, etc. If necessary, the verifying person can also contact the user using the user's contact information.

As described above, card reader 200c can transmit the user's exercise status to checker terminal 500 via management server 300c. In other words, the user can notify the checker of their exercise status by simply installing service card 100 in installation unit 290 of card reader 200c. Furthermore, because the user's exercise status is notified to the checker through the user's voluntary action of installing service card 100 in card reader 200c, the user does not feel stressed about being monitored. Furthermore, card reader 200c can prompt the user to notify the checker of their exercise status by periodically (at predetermined times) notifying the notification unit.

Note that, in this embodiment, the case where card reader 200c acquires the read time when card ID 110 is read or the removal time when service card 100 is removed is described, but this configuration is not limited to this. For example, management server 300c may acquire the time when card ID 110 and device ID 221 are received from card reader 200c as the read time indicating the time when card ID 110 was read by card reading unit 231 or the removal time indicating the time when service card 100 was removed. In this case, card reading unit 231 does not need to acquire the read time or removal time. Reader transmission unit 232 transmits card ID 110, device ID 221, and information indicating that card ID 110 has been read or information indicating that service card 100 has been removed to management server 300c. The information providing unit 326 transmits the time at which it received the card ID 110, the device ID 221, and information indicating that the card ID 110 has been read to the checker terminal 500 as the read time. Similarly, the information providing unit 326 transmits the time at which it received the card ID 110, the device ID 221, and information indicating that the service card 100 has been removed to the checker terminal 500 as the removal time.

(Contact your safety using the operation button)
In the service providing system 1c, a user may operate the operation button 210 during a first predetermined period every day to notify the checker of their safety. In this case, as shown in FIG. 11 , the storage unit 310c of the management server 300c further stores operation history information 314 (described later). The user may operate only the operation button 210 without using the service card 100 to notify the checker of their safety. Alternatively, the user may install the service card 100 described in the first embodiment in the card reader 200 and press the operation button 210 to send a service request and notify the checker of their safety. Alternatively, the user may install the service card 100 described in the fourth embodiment in the card reader 200 and have the card reading unit 231 automatically read the card ID 110 to notify the checker of their safety without pressing the operation button 210.

Here, for a user who has not operated the operation button 210 during a first predetermined period, the card reader 200c sends a notification prompting them to operate the operation button 210 at a predetermined timing during a second predetermined period. The first predetermined period is, for example, from 7:00 AM to 10:00 AM. The second predetermined period is, for example, from 10:00 AM to 11:00 AM. The predetermined timing is, for example, every 15 minutes from 10:00 AM.

When the operation button 210 is pressed, the operation input unit 237 acquires the time when the operation button 210 is pressed using a timer (not shown). The reader transmission unit 232 transmits the device ID 221 and the time when the operation button 210 was pressed to the management server 300c.

Here, the operation input unit 237 determines whether the operation button 210 has been pressed within the first predetermined period. If the operation button 210 has not been pressed within the first predetermined period, the output control unit 235 controls the speaker 240 and/or the display unit 280 to notify the user to operate the operation button 210.

The analysis unit 322 analyzes and extracts the device ID 221 and the time of pressing from the data received from the card reader 200c. The information provision unit 326 identifies the user's personal information, including the user's contact information corresponding to the device ID 221, from the user information 311. The history registration unit 325 registers the user's personal information and the time of pressing in the operation history information 314.

The determination unit 328 determines, for each of multiple users, whether the operation button 210 has been operated during a first predetermined period and a second predetermined period, based on the operation history registered in the operation history information 314. The determination unit 328 may generate a display screen showing users whose operation button 210 has not been operated during the first predetermined period and the second predetermined period. The information providing unit 326 transmits the display screen to the verifying terminal 500. Based on the display screen, the verifying person can verify the safety of users whose operation button 210 has not been operated (by calling, rushing to the location, etc.).

Figure 17 is a diagram showing a specific example of a display screen displayed on the verifyer terminal 500. The display screen shown in Figure 17 shows the user's name and whether or not the user has operated the operation button 210 on each date. In the example shown in Figure 17, if a user has not operated (used) the operation button 210 for three days, the verifyer (business operator) is notified of the user's contact information. Note that the timing of notification to the verifyer is not limited to this; if a user has not operated the operation button 210 for one day, the verifyer may be notified of the user's contact information.

As described above, the card reader 200c can notify a user who has not operated the operation button 210 during a first predetermined period to prompt them to operate the operation button 210 during a second predetermined period. Furthermore, a checker can check the safety of users who have not operated the operation button 210 during the second predetermined period.

(Service Identification Object)
Here, a card (service card) has been used as an example of a service identification object having a service identifier, but the form of the service identification object is not limited to this. Any object having a service identifier can be used as the service identification object, such as a rectangular parallelepiped, a sphere, a coin-shaped object, a ring-shaped object, or a key chain. The service identification object holds the service identifier in any form, such as a wireless tag, a magnetically readable code, or an optically readable code.

The service identification object may have a service identifier and a user ID. In this case, the service identification object is issued exclusively for that user. Card readers 200, 200b, and 200c may read the service identifier and user ID from the service identification object and transmit them to management servers 300, 300a, and 300c. Management servers 300, 300a, and 300c may use the received user ID instead of the device ID to perform the above-mentioned processing.

[Software implementation example]
The control blocks of the card readers 200, 200b, and 200c, the management servers 300, 300a, 300b, and 300c, and the business server 400, 400a (particularly the control units 230, 230b, 230c, 320, 320a, 320c, and 410, the card reading unit 231, the service request unit 233, the output control unit 235, the speech acquisition unit 239, the operation input unit 237, the reader transmission unit 232, the request content analysis unit 32 1. The request content transfer unit 323, result acquisition unit 324, history registration unit 325, information notification unit 327, judgment unit 328, learning unit 330, first promotion notification unit 329, analysis unit 322, information provision unit 326, request presentation unit 411, result notification unit 413, and second promotion notification unit 415 may be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or by software.

In the latter case, card readers 200, 200b, and 200c, management servers 300, 300a, 300b, and 300c, and business server 400 and 400a each include a computer that executes instructions from a program, which is software that realizes each function. This computer may include, for example, one or more processors and a computer-readable recording medium that stores the program. The object of the present invention is achieved when the processor in the computer reads and executes the program from the recording medium. The processor may be, for example, a CPU (Central Processing Unit). The recording medium may be a "non-transitory tangible medium," such as a ROM (Read Only Memory), tape, disk, card, semiconductor memory, or programmable logic circuit. The computer may also include a RAM (Random Access Memory) on which the program is deployed. The program may also be supplied to the computer via any transmission medium capable of transmitting the program (such as a communications network or broadcast waves). Furthermore, one aspect of the present invention can also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied through electronic transmission.

〔summary〕
The identifier reader of aspect 1 of the present invention comprises a reading unit that reads an exercise identifier corresponding to the exercise of a user from an exercise identification object held by the user, and a reader transmitting unit that transmits to a management server the exercise identifier read by the reading unit, the user identifier of the user, and information indicating that the exercise identifier has been read by the reading unit.

With the above configuration, the identifier reader can transmit the user's exercise status to the management server. In other words, the user can communicate their exercise status to a person (verifier) who is responsible for watching over the user via the management server. Furthermore, because the user's exercise status is communicated to theverifier through their own voluntary action, such as having the identifier reader read the exercise identification object, the user does not feel stressed about being monitored.

In the identifier reader according to aspect 2 of the present invention, in the above aspect 1, the identifier reader may be formed with an installation section for installing the motion identification object, the reading section may read the motion identifier from the motion identification object installed in the installation section, and the reader transmission section may transmit information to a management server indicating that the motion identification object has been removed from the installation section.

With the above configuration, the user can notify the inspector of their exercise status using the simple method of installing an exercise identification object in the installation section of the identifier reader. Furthermore, the identifier reader sends information to the management server indicating that the exercise identification object has been removed from the installation section, allowing the inspector to confirm that the user has finished exercising. For example, if the user removes an exercise identification object from the identifier reader, indicating that the user is out, the inspector can confirm that the user has returned home.

The identifier reader according to aspect 3 of the present invention may be the same as in aspect 2 above, but may also include a notification unit that issues a notification urging the user to remove the motion identification object from the installation unit at a predetermined timing after the reading unit reads the motion identifier, if the motion identification object is installed in the installation unit.

With this configuration, the identifier reader can prompt the user to report on their exercise status (for example, to report that they have returned home).

The identifier reader according to aspect 4 of the present invention may be configured in accordance with aspect 3 above, further comprising an operation unit that accepts user operations, and when the operation unit is operated, the notification unit stops the notification.

From a crime prevention perspective, it is undesirable for the notification unit to continue sending notifications while the user is out. With the above configuration, the user can stop such notifications from the notification unit by operating the operation unit while out.

The identifier reader according to aspect 5 of the present invention may be any of aspects 1 to 4 above, and may further include an audio output unit that outputs a predetermined sound corresponding to the exercise identifier when the reading unit reads the exercise identifier.

A service provision system according to aspect 6 of the present invention includes an identifier reader according to any one of aspects 1 to 5 above, and a management server. The management server may include a receiving unit that receives from the identifier reader the exercise identifier, the user identifier, and information indicating that the exercise identifier has been read by the reading unit; a memory unit that stores the exercise identifier and the details of the exercise in association with each other; and a transmitting unit that transmits to a verifying terminal the user's exercise status and a reading time indicating the time when the exercise identifier was read by the reading unit.

A service provision system according to Aspect 7 of the present invention may be configured in accordance with Aspect 6 above, such that the storage unit stores contact information for multiple users and user identifiers for multiple users in association with each other, and the transmission unit transmits the contact information for the users to the verifying terminal.

In the service provision system according to Aspect 8 of the present invention, in Aspect 7 above, the management server may further include a history registration unit that stores an exercise history, which is a history of the user's transmission of the exercise identifier, in the storage unit in association with the user identifier of the user, and a determination unit that determines whether or not the user's health condition needs to be checked based on the exercise history.

The present invention is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention.

1c Service provision system 100 Service card (motion identification object)
110 Card ID (exercise identifier)
200c Card reader (identifier reader)
210 Operation button (operation unit)
220, 310c Storage unit 221 Device ID (user identifier, reader identifier)
230c, 320c Control unit 231 Card reading unit (reading unit)
232 Reader transmission unit 235 Output control unit 240 Speaker (notification unit, audio output unit)
280 Display section (notification section)
290 Installation unit 300c Management server 311 User information 312 Exercise history information 319 Exercise information 322 Analysis unit (receiving unit)
325 History registration unit 326 Information providing unit (transmission unit)
328 Determination unit 500 Checker terminal

Claims (7)

a reading unit that reads an exercise identifier corresponding to the exercise of the user from an exercise identification object held by the user;
an identifier reader including a reader transmitter that transmits to a management server the exercise identifier read by the reader, a user identifier of the user, and information indicating that the exercise identifier has been read by the reader,
The identifier reader has a mounting portion for mounting the motion identification object,
the reading unit reads the motion identifier from the motion identification object installed in the installation unit;
The reader transmitting unit transmits information indicating that the motion identification object has been removed from the installation unit to a management server . The identifier reader of claim 1, further comprising a notification unit that issues a notification prompting the user to remove the motion identification object from the installation unit if the motion identification object is installed in the installation unit at a predetermined timing after the reading unit reads the motion identifier. An operation unit that accepts operations by a user is provided,
The identifier reader according to claim 2 , wherein the notification unit stops the notification when the operation unit is operated. The identifier reader according to claim 1 , further comprising: a sound output unit that outputs a predetermined sound corresponding to the exercise identifier when the reading unit reads the exercise identifier. An identifier reader according to any one of claims 1 to 4 ;
a management server;
The management server
a receiving unit that receives, from the identifier reader, the exercise identifier, the user identifier, and information indicating that the exercise identifier has been read by the reading unit;
a storage unit that stores the exercise identifier and the exercise content in association with each other;
A service providing system comprising: a transmitting unit that transmits to a verifying terminal the exercise status of the user and a reading time indicating the time when the exercise identifier was read by the reading unit. an identifier reader; and a management server;
The identifier reader
a reading unit that reads an exercise identifier corresponding to the exercise of the user from an exercise identification object held by the user;
a reader-transmitter that transmits to a management server the exercise identifier read by the reader, a user identifier of the user, and information indicating that the exercise identifier has been read by the reader;
The management server
a receiving unit that receives, from the identifier reader, the exercise identifier, the user identifier, and information indicating that the exercise identifier has been read by the reading unit;
a storage unit that stores the exercise identifier and the exercise content in association with each other;
a transmitting unit that transmits to a verifying terminal the exercise status of the user and a read time indicating the time when the exercise identifier was read by the reading unit;
the storage unit stores contact information of the plurality of users and user identifiers of the plurality of users in association with each other;
The transmission unit transmits the user's contact information to the verifying terminal. The management server
a history registration unit that stores an exercise history, which is a history of transmission of the exercise identifier by the user, in the storage unit in association with the user identifier of the user;
The service providing system according to claim 6 , further comprising a determining unit that determines whether or not the user's health condition needs to be checked based on the exercise history.