Identifier reader and service provision system
The identifier reader system simplifies service access for elderly users by transmitting exercise data to a management server, addressing the challenge of using complex communication terminals and reducing stress in monitoring technologies.
Patent Information
- Application Number
- JP2021126842
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2021-08-02
- Publication Date
- 2025-10-29
- Estimated Expiration
- 2041-08-02
AI Technical Summary
Elderly individuals unfamiliar with general-purpose information and communication terminals struggle to utilize safety confirmation systems, and existing monitoring technologies like motion sensors and GPS devices are cumbersome and stressful.
An identifier reader that reads an exercise identifier from a user-held object and transmits data to a management server, allowing easy service provision through a card reader and management server system without requiring complex terminal operations.
Encourages elderly users to voluntarily contact others for safety confirmation, simplifying service access and reducing stress through intuitive operation.
Smart Images

Figure 0007762005000001 
Figure 0007762005000002 
Figure 0007762005000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to an identifier reader and a service providing system. [Background technology]
[0002] In recent years, technologies for checking the safety of elderly people using communication terminals such as personal computers and smartphones have become known. For example, Patent Document 1 discloses a safety confirmation system in which multiple users check each other's safety using their own user terminals. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2018-55159 Summary of the Invention [Problem to be solved by the invention]
[0004] However, because the above-mentioned conventional technologies use general-purpose information and communication terminals (such as personal computers or smartphones), there is a problem that elderly people who are unfamiliar with operating general-purpose information and communication terminals are unable to fully utilize the above-mentioned systems.
[0005] There are also known techniques for watching over elderly people by installing motion sensors in homes or by providing elderly people with GPS devices, etc. However, such conventional techniques have the problem that it is time-consuming to install motion sensors in homes and that being monitored can cause stress to elderly people.
[0006] One aspect of the present invention has been made 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 can encourage them to voluntarily contact someone to let them know they are safe. [Means for solving the problem]
[0007] In order to solve the above problem, an identifier reader according to one embodiment 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. [Effects of the Invention]
[0008] According to one aspect of the present invention, even elderly people who are unfamiliar with operating communication terminals can easily use them, and can be encouraged to spontaneously contact others to let them know they are safe. [Brief explanation of the drawings]
[0009] [Figure 1] 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. [Figure 2] 1 is a schematic diagram illustrating an overview of a service providing system according to a first embodiment of the present invention. [Figure 3] 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. [Figure 4] 2 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. [Figure 5] 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. [Figure 6] FIG. 10 is a block diagram showing an example of the configuration of a main part of a service providing system according to a second embodiment of the present invention. [Figure 7] FIG. 2 is a schematic diagram illustrating an example of the configuration of destination information. [Figure 8] FIG. 10 is a diagram illustrating an example of a part of a processing flow of a control unit of the management server. [Figure 9]FIG. 10 is a block diagram showing an example of the configuration of a main part of a service providing system according to a third embodiment of the present invention. [Figure 10] FIG. 2 is a perspective view showing an example of the configuration of a card reader. [Figure 11] 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. [Figure 12] 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. [Figure 13] FIG. 2 is a schematic diagram showing an example of the configuration of exercise information. [Figure 14] FIG. 2 is a schematic diagram showing an example of the configuration of exercise history information. [Figure 15] 10 is a flowchart showing the processing of a control unit of a card reader. [Figure 16] 10 is a flowchart showing a process of a control unit of a management server. [Figure 17] FIG. 10 is a diagram showing a specific example of a display screen displayed on the verifying terminal. DETAILED DESCRIPTION OF THE INVENTION
[0010] [Embodiment 1] Hereinafter, one embodiment of the present invention will be described in detail with reference to FIGS.
[0011] (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.
[0012] The service providing system 1 is a system in which users can use various services provided by multiple service providers using a card reader 200 and multiple service cards 100 that have been distributed to them in advance. Users can begin using the service providing system 1 by registering their personal information, etc. with the operating company (system operator) that operates the management server 300. Similarly, individual service providers can begin providing services using the service providing system 1 by registering information, such as contact information for their own provider server 400, with the management server 300. The operating company of the management server 300 distributes to users who wish to use the service providing system 1 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. 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 providing system 1 without having to configure a communication environment, etc. The card reader 200 is distributed in a state in which it can be used on the mobile phone communication network contracted by the system operator, and the user does not need to make a separate contract with a communication operator or internet service provider to use the service providing system 1.
[0013] A user can receive a service from a service provider that corresponds to the service the user desires to receive by using the service providing system 1. More specifically, the user can transmit a service 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 service from.
[0014] 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 based on the content of the provision request. The management server 300 then transfers the request content to the provider server 400 owned by the identified service provider. At this time, the management server 300 transmits personal information, including contact information of the requesting user, that has been registered with the management server 300 to the provider server 400 along with the request content.
[0015] Service providers are engaged in the business of providing various services. The services provided by the service providers may be of any type; for example, the service providers may provide services such as purchasing goods, making appointments for medical examinations, and 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. The means of contact is not particularly limited, but if the contact information is, for example, a telephone number, the service provider contacts the user by telephone. When the service provider contacts the user, the service provider may also explain the specific content and fees of the services to be provided.
[0016] When a service provider starts providing a service to a user using the service providing 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 to be registered in advance is the amount to be paid to the system provider when the service provider provides a service using the service providing system 1. The service provider may, for example, enter into a contract to pay the system provider an amount according to the number of times the service is provided to a user using the service providing 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.
[0017] 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, the service provider 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 history information regarding the provision of the service.
[0018] In this way, the service providing 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. Since the operation of the card reader 200 is intuitive and simple compared to the operation of general-purpose information communication terminals such as personal computers and smartphones, even elderly people who are unfamiliar with general-purpose information communication terminals can receive the same services as if they were using a general-purpose information communication terminal. Furthermore, since the management server 300 transmits the user's contact information to the provider server 400, unlike conventional technology, the user does not need to make individual contracts (including registering contact information) with each service provider in advance.
[0019] (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.
[0020] The service card 100 is a card issued by each service provider and stores content that can be read by the card reader 200. The service card 100 may be a card of any type as long as the content can be read by the card reader 200, and may be, for example, a contactless communication IC card compatible with the FeliCa (registered trademark) system.
[0021] 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 the user wishes 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 can read the contents of the service card 100 placed in the housing and transmit a service provision request to the service provider corresponding to the contents to the management server 300.
[0022] The card reader 200 may further include a display that provides text or video 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.
[0023] (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.
[0024] The service providing system 1 is a system in which a user can receive services from a service provider that provides various services and operates a provider server 400 by using a service card 100 and a card reader 200. The service providing system 1 includes the service card 100, the card reader 200, a management server 300, and a plurality of provider servers 400 corresponding to a plurality of service providers.
[0025] The service card 100 is a card associated with a service provider that provides services through the service providing system 1, and the internal information of the card can be read by the card reader 200. The service card 100 has a card ID 110, which is a service identifier for uniquely identifying the service provider associated with the service card 100. That is, in this embodiment, all of the multiple service cards 100 that can be used in the service providing system 1 are cards that have a card ID 110 and have a common format. The card ID 110 is different for each service provider.
[0026] 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 storage 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.
[0027] The operation button 210 is a button provided on the housing of the card reader 200. The operation button 210 may be of any configuration as long as it can be intentionally operated by a user. The operation button 210 may be, for example, a lever.
[0028] The memory unit 220 stores various types of information handled by the card reader 200. The memory unit 220 stores a device ID 221. The memory unit 220 may store, for example, information about the management server 300 to which it is connected. The device ID 221 is a reader identifier for uniquely identifying the card reader 200. The user who uses the card reader 200 can be identified by the device ID.
[0029] The control unit 230 controls all the units 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 has successfully read the card ID 110, the control unit 230 instructs the service request unit 233 to send a request for providing a service to the management server 300.
[0030] The card reading unit 231 acquires the card ID 110 from the service card 100 installed in the card reader 200 in accordance with an instruction from the control unit 230. The card reading unit 231 notifies the control unit 230 of the acquired result.
[0031] The service request unit 233 requests the provision of a service by transmitting 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 in accordance with an instruction from the control unit 230. The service request unit 233 may obtain the date and time of transmission using, for example, a timer (not shown), and transmit it together with the card ID 110 and the device ID 221.
[0032] The output control unit 235 controls the audio output from the speaker 240 .
[0033] Management server 300 is a server managed by the operating company that operates service providing system 1. Management server 300 includes a memory unit 310 and a control unit 320. Memory unit 310 stores user information 311, service provider information 313, and service history information 315. 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.
[0034] The storage unit 310 stores various types of information handled by the management server 300. The 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 the user applied to use the service provision system 1. The storage unit 310 stores, as the user information 311, contact information for multiple users and device IDs 221 of multiple card readers 200 distributed to the multiple users, in association with each other. The service provider information 313 is information about service providers that provide services through the service provision system 1. The storage unit 310 stores, as the service provider information 313, multiple card IDs 110 in association with multiple service providers. The 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 the card readers 200. Specific examples of the user information 311, the service provider information 313, and the service history information 315 will be described later with reference to FIG. 4.
[0035] The control unit 320 controls all the units of the management server 300. The control unit 320 instructs the history registration unit 325 to register the history of transmission and reception in the service history information 315 according to the content of data transmitted and received by the management server 300.
[0036] 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 the device ID 221 from the data received from the card reader 200. That is, the request content analysis unit 321 functions as a receiving unit that receives from the card reader 200 the card ID 110 and the device ID 221 that have been 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.
[0037] Based on the analysis result by the request content analysis unit 321, the request content transfer unit 323 transfers 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 transfer 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 transfer unit 323 further identifies the user to whom the card reader 200 corresponding to the device ID 221 is to be distributed from the user information 311. The request content transfer unit 323 then transmits information regarding the contact information of the identified user to the provider server 400 of the identified service provider. In other words, the request content transfer unit 323 functions as a transmission unit that transmits the contact information of the user 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 received together with the contact information. At this time, the request content transfer unit 323 may notify the provider server 400 to call the user's contact information. The request content transfer unit 323 may obtain the transmission date and time using a timer (not shown) and transmit it to the business entity server 400 together with the above-mentioned information.
[0038] The history registration unit 325 registers information such as the date and time when processing related to the provision of a service was executed and the execution result in the service history information 315 in accordance with instructions from the control unit 320 .
[0039] The provider server 400 is a server owned by a service provider that provides a service to a user in response to a request. The provider server 400 includes a control unit 410, which includes a request presentation unit 411 and a result notification unit 413. Although 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 be configured to provide services in a different form in addition to the configuration for providing services in the service providing system 1. For example, the provider server 400 may further include a configuration for operating as a web server that provides a screen for accepting web reservations via the internet to a general-purpose information communication terminal such as a personal computer or a smartphone.
[0040] The control unit 410 controls each unit of the provider server 400 in an integrated manner. 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 input of information from the service provider using an input unit (not shown) and output information using a display unit (not shown). For example, the control unit 410 may accept input of information 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 has been given, the date and time of the offer, etc.), and provide the information to the result notification unit 413.
[0041] The request presentation unit 411 presents the service request received from the management server 300 to the service provider in accordance with instructions from the control unit 410. More specifically, the request presentation unit 411 presents the fact that a new service request has been received and the information included in the request regarding the contact information 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 identify the existence of a user who desires service from the content presented by the request presentation unit 411 and 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 a date and time obtained using a timer (not shown).
[0042] The service provider offers to provide the service to the user based on the service request, and inputs the progress of the service provision to 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, together with the provision result.
[0043] (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.
[0044] In the illustrated example, the user information 311 has three items: "User ID," "Personal Information," and "Device ID." The "Personal Information" is further subdivided into six items: "Name," "Telephone Number," "Age," "Gender," "Address," and "Area." The "User ID" is an identifier (user identifier) used by the management company that operates the management server 300 to uniquely identify the person to whom the card reader 200 was distributed, i.e., the user of the service providing system 1. The "Personal Information" is set with the user's personal information, with the "Name" being the user's name, the "Telephone Number" being the user's telephone number, the "Age" being the user's current age, the "Gender" being the user's gender, and the "Address" being the user's current address. The "Area" is set with a regional identifier that can identify a region (e.g., Kanto, Kinki, etc.), prefecture, city, town, village, town name, and / or street name. The "Device ID" is an identifier used to uniquely identify the card reader 200 distributed to the user. That is, in the illustrated example, there is a one-to-one correspondence between the value of the "User ID" and the value of the "Device ID." That is, the device ID also functions as a user identifier.
[0045] 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 value of "Personal Information" in that record as information about the user to be sent to the provider server 400. When the provider server 400 receives the value of "Personal Information" 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 may be used as the user's contact information, or other information such as an address or email address may also be used.
[0046] The service provider information 313 includes five items: "Service Provider ID," "Service Provider Name," "Service Notification Destination," "Card ID," and "Billing Data." The "Service Provider ID" is an identifier for uniquely identifying a service provider in the service providing 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 a value identical to the card ID 110 of the service card 100 corresponding to the service provider specified by the "Service Provider ID." That is, in the illustrated example, the value of the "Service Provider ID" and the value of the "Card ID" correspond one-to-one. The "Billing Data" specifies a fee structure that the service provider specified by the "Service Provider ID" pays to the operating company of the management server 300 when providing a service using the service providing system 1. The fee structure may be a pay-per-use system based on the number of completed service provision transactions, or a flat-rate system or other system may be set. That is, the storage unit 310 stores, as service provider information 313, information relating to the amounts to be paid by a plurality of service providers when a service is provided using the service providing system 1, in association with each other. For example, the management server 300 displays the contents of the "billing data" and the service history information 315 on a display unit (not shown). The system provider can calculate the usage fee for the service providing system 1 for each service provider based on the displayed contents and bill each service provider.
[0047] 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 service provider server 400. More specifically, the request content forwarding unit 323 determines whether or not 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 the record as the contact information of the service provider from which the user who made the service request desires to provide the service. The request content forwarding unit 323 forwards the service request to the transfer destination set as the contact information of the service provider by email or other means, thereby allowing the service provider to offer the service to the user.
[0048] The service history information 315 includes a "service management number," a "service provider ID," a "user ID," a "card read time," a "service contact time," a "service acceptance time," a "service provision time," and a "service result." The "service management number" is an identifier that uniquely identifies the history of a service request received by the management server 300 from the card reader 200. The "service provider ID" is set to a value similar to that of the item with the same name in the service provider information 313. The "user ID" is set to a value similar to that of the item with the same name in the user information 311. The "card read time" is set to the date and time when the card reader 200 reads the card ID 110 of the service card 100. The "service contact time" is set to the date and time when the management server 300 receives a service provision request from the card reader 200. The "service acceptance time" is set to the date and time when the provider server 400 receives a service provision request from the management server 300. The "service provision time" is set to the date and time when the service provider contacts the user and offers to provide the service. That is, the service history information 315 stores information relating to the history of the time when some processing was performed in at least one of the card reader 200, the management server 300, and the business server 400 from the time when the card reader 200 read the card ID 110 until the service provider provided the service to the user. In the "service result," the service provision result indicating the progress of the provision of the service is set.
[0049] The service history information 315 includes a history of processes executed by the card reader 200, the management server 300, or the agent server 400 in the service providing system 1, which is collected and stored in the management server 300.
[0050] First, a service request is sent from the card reader 200 to the management server 300, along with the date and time when the card ID 110 of the service card 100 was read. When the 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 the card reader 200 that sent the request, which are identified from the received service request, and the service provider ID corresponding to the card ID 110, along with the date and time when the card ID 110 was read, to the service history information 315 as a new record. That is, at this point, values have been set for the "service management number," "service provider ID," "user ID," and "card reading time," but values have not been set for the "service contact time," "service acceptance time," "service provision time," and "service result."
[0051] Next, when the request content forwarding unit 323 forwards the service request to the business operator 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 business operator server 400 indicating that the service request has been accepted, the history registration unit 325 sets the date and time when the business operator 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.
[0052] 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 when the service was offered and the progress of the service provision based on whether the user finally agreed to the provision of the service, which are included in the notification, in the "service provision time" and "service result," respectively.
[0053] In this way, the history registration unit 325 can collect and store the history of processing in the service providing system 1 in the service history information 315.
[0054] (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.
[0055] First, the user places the service card 100 corresponding to the service provider from which the user desires 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 when the card ID was read to the management server 300 (S1: service request).
[0056] When the management server 300 receives a service request from the card reader 200, it sets a new service management number for the request and further analyzes the request using the request content analysis unit 321 (S2: Request content analysis). Thereafter, the management server 300 uses the request content transfer unit 323 to identify the user's personal information and the contact information of the service provider's operator server 400. Then, the management server 300 transmits the service management number set in S2, together with the identified user's personal information and the date and time of transfer of the service request, to the identified contact information of the service provider's operator server 400 (S3: Request content transfer). At this time, the management server 300 additionally registers a history of the transfer of the service request in the service history information 315 using the history registration unit 325. Furthermore, when the transfer of the service request is completed, the management server 300 notifies the card reader 200 that the transfer is complete (S4: Transfer notification). Based on the notification, the card reader 200 notifies the user by voice or the like that the service request has been transferred to the business server 400.
[0057] On the service provider side, when the provider server 400 receives the service provision request transferred from the management server 300, the provider server 400 notifies the service provider of the request contents (S5: request acceptance). After that, the provider server 400 notifies the management server 300 of the date and time when the service provision request was accepted, together with the service management number sent from the management server 300 in S3 (S6: acceptance notification).
[0058] When the management server 300 receives a notification from the business entity server 400 that the service request has been accepted, the management server 300 notifies the card reader 200 that the service request has been accepted by the business entity server 400, together with information on the date and time sent from the business entity server 400 in S6 (S7: Acceptance completion notification). Based on the notification, the card reader 200 notifies the user by voice or the like that the service request has been transferred to the business entity server 400.
[0059] After S6 and S7, the service provider contacts the user by telephone or other means using the user's personal information that the provider server 400 received from the management server 300 in S3, and offers to provide the service (S8: service provision). Note that since the service provider cannot detect that the processing of S7 has been completed, the processing of S8 may be performed before the processing of S7, but this does not pose a problem.
[0060] When the user receives an offer to provide a service from the service provider through the processing of S8, the user receives a detailed explanation of the service, and then notifies the service provider of his or her intention to actually use the service (S9: Notification of whether or not to use the service).
[0061] 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 transmits the service management number received from the management server 300 in S3 together with the user's personal information, along with the date and time when the service provision offer was made (service provision time) and the progress of the service provision (service result) to the management server 300 using the provider server 400 (S10: service provision result notification). Note that if the user notified the service provider in S9 that they will use 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 when the service is actually provided. Then, the management server 300 uses the history registration unit 325 to additionally register the information received from the provider server 400 in the service history information 315.
[0062] Through the above processing, 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 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 a service from the service provider. As a result, compared to the case where the user selects a desired service provider using a general-purpose information and communication terminal such as a personal computer or smartphone, the user can receive a service from the service provider simply by having the card reader 200 read the selected service card 100.
[0063] Furthermore, since the contact information of users and service providers is centrally managed by the management server 300, users do not need to sign individual contracts with each service provider. Therefore, users can receive new services from the corresponding service provider simply by reading the newly acquired service card 100 into the card reader 200.
[0064] To participate in the service provision system 1, a service provider must register contact information in 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 a person who is unfamiliar with operating an information communication terminal can receive the same services from the service provider as if they were using an information communication terminal, and a highly convenient service provision system can be realized.
[0065] [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.
[0066] Furthermore, the management server 300 may analyze the trends in services used by each user by analyzing the history information stored in the service history information 315. 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 according to the user's trends.
[0067] (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.
[0068] 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 refers to the user information 311 stored in the memory unit 310 and determines whether the personal information (address, age, gender, etc.) of each user satisfies the notification conditions. The information notification unit 327 transmits the business notification information to the card reader 200 of the user who satisfies the notification conditions.
[0069] 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 sound from the speaker 240. The business notification information may be sound data or text data. If the business notification information is text data, the output control unit 235 converts the text data into sound data and outputs it as sound from the speaker 240.
[0070] (Personal Notification Information) The card reader 200 may notify the user by voice of information unrelated to the business. 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 by voice of the personal notification information when the user holds the personal card over the card reader 200 and reads the user's user identifier from the personal card.
[0071] Specifically, the card reading unit 231 reads the user identifier of the user 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.
[0072] Upon receiving the user identifier, the information notification unit 327 of the management server 300 refers to 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 where the user lives or pre-registered information. The personal notification information may include, for example, the weather in the area where the user lives, news about the area, the time when the user should take their medicine, or the current time. The time when the user should take their medicine may be registered in advance as user information. The information notification unit 327 may obtain the local weather, news about the area, etc. 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.
[0073] 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 sound from the speaker 240. The personal notification information may be sound data or text data.
[0074] Alternatively, the card reader 200 may notify the user of the personal notification information by voice at a predetermined time.
[0075] 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. At the predetermined time, the information notification unit 327 transmits the personal notification information to the card reader 200. The output control unit 235 of the card reader 200 outputs the personal notification information as sound from the speaker 240.
[0076] The management server 300 may transmit personal notification information to any number of users. For example, to the card readers 200 of multiple users residing in a certain area, the management server 300 may transmit weather information for the area, news for the area, or evacuation information for the area. For example, to the card readers 200 of multiple users belonging to a certain organization, the management server 300 may transmit information about the organization. For example, common information may be transmitted to all users.
[0077] Alternatively, 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 the associated user identifier to the management server 300. The management server 300 refers to pre-stored user information 311 and checks 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.
[0078] [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.
[0079] FIG. 6 is a block diagram showing an example of the main configuration of the service providing system 1a. In the service providing system 1a, in addition to the service card for requesting the provision of the above-mentioned services, each user is given a service card for informing others of the user's own health condition. 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 a social welfare council employee), who is a person (verifier) responsible for watching over the user. The user can inform the verifying person that the user is healthy (in good health) by having the card reader 200 read the contents of the service card indicating that the user is healthy (in good health). Furthermore, the service providing system 1a can monitor users who are, for example, elderly people.
[0080] The service providing system 1a includes a card reader 200, a management server 300a, and business servers 400, 400a corresponding to a plurality of service businesses. The configurations of the card reader 200 and the business server 400 are the same as those in the first embodiment, and therefore detailed explanations will be omitted. The processing of the management server 300a and the business server 400 when a service card requesting provision of a service is read by the card reader 200 is the same as in the first embodiment. Note that the business server 400 is omitted in FIG. 6.
[0081] The card reader 200 acquires a card ID from a service card indicating the health condition, and transmits the card ID read from the service card together with the device ID to the management server 300a.
[0082] (Administration Server Configuration) Management server 300a includes a memory unit 310a and a control unit 320a. Memory unit 310a stores user information 311, service provider information 313, service history information 315, status history information 316, and destination information 317. 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. Determination unit 328 includes a learning unit 330.
[0083] FIG. 7 is a schematic diagram showing an example of the configuration of destination information 317. FIG. 7 is merely an example, and destination information 317 may have any configuration. Destination information 317 has the fields of "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, a messaging app account, or a phone number to which short mail notifications will be sent. The card ID of the service card indicating the health condition is stored in destination information 317.
[0084] The request content analysis unit 321 extracts the card ID and the device ID from the data received from the card reader 200. The request content analysis unit 321 outputs the card ID and the device ID to the request content transfer unit 323.
[0085] The request content forwarding unit 323 determines whether the received card ID indicates a request for a service provider to provide a service or a request for the checker to be notified 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 in the destination information 317. The request content forwarding unit 323 acquires a destination corresponding to the card ID from the destination information 317. The request content forwarding unit 323 notifies the checker of 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 information about the checker's destination, 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 mail, the provider server 400a is a server of a mobile communication provider that provides the short mail function. If the destination service type is e-mail, the carrier server 400a is the mail server of the telecommunications carrier corresponding to the checker's e-mail address.
[0086] The result acquisition unit 324 receives information indicating the user (e.g., user ID), the confirmation result of the user's health condition, and information indicating the date and time of the confirmation from the result notification unit 413 of the business entity server 400a. The result acquisition unit 324 outputs the received information indicating the user (e.g., user ID), the confirmation result of the user's health condition, and information indicating the date and time of the confirmation to the history registration unit 325.
[0087] The history registration unit 325 stores the service history of the user in the storage unit as service history information 315a in association with the user's user ID. 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.
[0088] The history registration unit 325 also registers the history of requests to notify the checker of the user's health condition in the status history information 316 in association with the user ID. The status history information 316 includes information regarding the request to notify 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 entity 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 status history information 316 in association with the user ID. The status history information 316 includes the history of requests to notify the checker of the user's health condition and the history of the check results of the user's health condition.
[0089] The determination unit 328 determines whether or not the user's health condition needs to be checked based on the service history, and outputs the determination result to the first promotion notification unit 329.
[0090] If it is determined that the health condition needs to be checked, the first prompt notification unit 329 notifies the checker to prompt them to check the user's health condition. Specifically, the first prompt notification unit 329 acquires a destination corresponding to the user ID from the destination information 317. If there are multiple destinations corresponding to the user ID, the first prompt notification unit 329 may acquire multiple destinations. The first prompt notification unit 329 transmits information about the checker's destination, the user information, and a message prompting the checker to check the user's health condition to the business operator server 400a corresponding to the destination. As a result, the first prompt notification unit 329 notifies the checker terminal 500 of the checker of the user information and the message prompting the checker to check the user's health condition via the business operator server 400a corresponding to the destination. The user information and the message are notified to the checker by, for example, email, a messaging app, or short mail.
[0091] (Operator server configuration) 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.
[0092] The request presentation unit 411 receives information about the checker'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 checker terminal 500 corresponding to the checker's address. The user information notified to the checker may include, in addition to "name," for example, "telephone number," "age," "gender," "address," and / or "area."
[0093] The result notification unit 413 receives input of the check result of the user's health condition and the date and time of the check from the checker's terminal 500. The result notification unit 413 transmits information indicating the user (e.g., user ID), the check result of the user's health condition, and information indicating the date and time of the check to the management server 300a.
[0094] The second prompt notification unit 415 receives information about the checker's address, user information, and a message urging 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 the message urging the user to check their health condition to the checker terminal 500 corresponding to the checker's address.
[0095] 8 is a diagram showing an example of a portion of the processing flow of the control unit 320a of the management server 300a. The history registration unit 325 stores the history of service requests by users or the history of service provision to users by service providers in association with the user ID of the users in the storage unit 310a (S21).
[0096] The result acquisition unit 324 acquires the check result of the user's health condition and information indicating the date and time of the check from the business entity server 400a. The history registration unit 325 stores the check result of the user's health condition and information indicating the date and time of the check in the storage unit 310a in association with the user's user ID (S22).
[0097] The learning unit 330 performs learning using the service history as input and the confirmation result of the user's health condition as output (S23). Note that the learning step S23 can be omitted as described later.
[0098] 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 the determination at a predetermined timing (for example, periodically).
[0099] If it is determined that the health condition needs to be checked (Yes in S24), the first prompt notifier 329 notifies the checker to prompt the checker to check the user's health condition (S25).
[0100] If it is determined that confirmation of the health condition is not necessary (No in S24), the first prompt notification unit 329 does not notify the checker to prompt the checker to check the user's health condition.
[0101] (Processing of the decision section) 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 determination 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 determination unit 328 does not need to include the learning unit 330.
[0102] For example, since no service history has been accumulated for a user who has just started using the service, the determination unit 328 may determine whether or not it is necessary to check the user's health condition based on the condition history information 316. For example, the determination unit 328 may determine that it is necessary to check the user's health condition when the user has not used a service card indicating their health condition for a predetermined period of time or longer.
[0103] The determination unit 328 may determine whether or not the user's health condition needs to be checked by, for example, comparing the frequency of service use by the user in a first period with the frequency of service use by the user in a second period that precedes the first period. For example, if the value obtained by subtracting the frequency of service use in the first period from the frequency of service use 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.
[0104] The determination unit 328 may determine whether or not the user's health condition needs to be checked by, for example, comparing the interval between service usages in a first period with the interval between service usages 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 usages 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 usages in the second period, the determination unit 328 may determine that the interval between usages has become longer and that the health condition needs to be checked. The representative value of the interval between service usages 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).
[0105] In this way, the determination 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. Any of the card reading time, service contact time, service reception time, and service provision time may be used as the service history.
[0106] (Processing of decision section 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 (to generate a learning model). Therefore, the learned 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 time of card reading, the time of service contact, the time of service reception, the time of service provision, 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.
[0107] The determination 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 determination unit 328 determines that the user's health condition needs to be checked, and if the estimated result indicates health, the determination 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 the estimated result indicating unhealthy health is equal to or greater than a predetermined value, the determination unit 328 may determine that the estimated result of the health condition is "requiring caution" (health condition check required).
[0108] 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. Also, a learning model trained using the service history and health status check results of one user may be modified (additionally trained) using the service history and health status check results of another user.
[0109] The first promotion notification unit 329 may acquire the estimated result of the user's health condition from the determination unit 328 and transmit it to the checker terminal 500 via the business entity server 400a. The first promotion notification unit 329 may change the message to be transmitted to the checker terminal 500 depending on the estimated result of the user's health condition (such as "Caution required" or "Urgent action required").
[0110] According to the service providing system 1a of this embodiment, it is possible to monitor users, such as elderly people, based on the service history. For example, a social welfare officer or a social welfare council employee who is the checker can efficiently visit the user at an appropriate time and check the user's health condition.
[0111] [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.
[0112] Fig. 9 is a block diagram showing an example of the configuration of the main parts of the service providing system 1b. Fig. 10 is a perspective view showing an example of the configuration of a card reader 200b. The service providing system 1b includes a card reader 200b instead of the card reader 200 of the service providing system 1. Furthermore, the service providing system 1b includes a management server 300b instead of the management server 300 of the service providing system 1.
[0113] The service providing system 1b is a system in which a user can send speech information to a verifying person using a card reader 200b and multiple service cards 100 that have been distributed in advance. A user can start using the service providing system 1 by registering the address of the verifying person in addition to his or her personal information with the operating company (system operator) that operates the management server 300. The verifying person (the recipient of the speech information) is, for example, a local welfare officer or social welfare council employee in the area where the user lives, or the user's family member.
[0114] 9 and 10, card reader 200b differs from card reader 200 in that it further includes a display unit 250 and a microphone 260. In addition, control unit 230b of card reader 200b includes output control unit 235, service request unit 233, card reading unit 231, speech acquisition unit 239, and operation input unit 237.
[0115] The output control unit 235 may display the acquired personal notification information as text data on the display unit 250.
[0116] 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 utterance acquisition unit 239 to acquire the user's utterance.
[0117] Here, the operation input unit 237 may instruct the utterance acquiring 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 acquiring 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 acquiring unit 239 to continue recording the user's utterance for a predetermined period after the operation button 210 is pressed.
[0118] 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 an instruction from the operation input unit 237. The card reading unit 231 outputs the read card ID 110 to the service request unit 233.
[0119] 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 as speech information indicating the user's speech to the service request unit 233. Note that the speech acquisition unit 239 may 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.
[0120] 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 utterance information associated with the card ID 110 from the utterance acquisition unit 239. The service request unit 233 transmits to the management server 300b an instruction to transmit the utterance information indicating the utterance of the user acquired by the utterance 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 utterance information and transmits an instruction to the management server 300b to transmit the utterance information.
[0121] As shown in FIG. 9, the management server 300b includes destination information 317 in a storage unit 310b.
[0122] The destination information 317 is information about multiple destinations that the user registered with the operating company of the service providing system 1b when applying to use the service providing system 1b. The destination here includes the service type that the verifyer uses to receive the user's utterance information and the verifyer's notification destination registered for that service type (see FIG. 7). The storage unit 310b stores multiple card IDs 110 and multiple destinations in association with each other as the destination information 317.
[0123] The request content analysis unit 321 analyzes and extracts the card ID 110, the device ID 221, and the speech information from the data received from the card reader 200b.
[0124] Based on the analysis result by the request content analysis unit 321, the request content transfer unit 323 transfers an instruction to transmit utterance information to the business operator server 400 corresponding to the service type used by the checker. More specifically, the request content transfer unit 323 identifies the address of the checker corresponding to the card ID 110 extracted by the request content analysis unit 321 (i.e., the service type used by the checker and the notification destination of the checker) from the address information 317. The request content transfer unit 323 further identifies the user to whom the card reader 200b corresponding to the device ID 221 is to be distributed from the user information 311. Then, the request content transfer unit 323 transmits the notification destination of the identified checker, information related to the contact information of the identified user, and the utterance information to the business operator server 400 corresponding to the identified service type.
[0125] The business operator server 400 is a server that transmits information about the user's contact points and utterance information to the recipient of the checker's notification. When the control unit 410 receives an instruction to transmit the utterance information from the management server 300, it transmits the information about the user's contact points and the utterance information to the recipient of the checker's notification. For example, if the business operator server 400 is a mail server of a telecommunications company, the control unit 410 transmits an email to the terminal owned by the checker, presenting the information about the user's contact points and the utterance information.
[0126] An example of the configuration of information managed by the management server 300b according to this embodiment will be described with reference to Fig. 7. Fig. 7 is a schematic diagram showing an example of the configuration of destination information 317 stored in the storage unit of the management server 300b.
[0127] The destination information 317 has three items: "user ID," "card ID," and "verifier's destination," and the "verifier's destination" is further subdivided into two items: "service type" and "notification destination." A "user ID" that uniquely identifies a user of the service providing system 1b is set with multiple "card IDs" corresponding to multiple service cards 100 distributed to the user. The "verifier's destination" is the destination to which the user's speech information is sent. The "service type" is the service type used by the verifyer to receive the user's speech information. The "notification destination" is the notification destination of the verifyer registered in the business server 400. The destination information 317 associates the "card ID" with the "verifier's destination," and the card ID 110 functions as a destination identifier.
[0128] 7, the service type is, for example, email, a message app, or a short mail. If the service type is email, an email address is stored in destination information 317 as the destination of the checker's notification. If the service type is a message app, an account is stored in destination information 317 as the destination of the checker's notification. If the service type is a short mail, a phone number is stored in destination information 317 as the destination of the checker's notification.
[0129] 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 transmit 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) corresponding 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.
[0130] [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.
[0131] (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.
[0132] In the service providing system 1c, in addition to a service card for requesting the provision of the above-mentioned service, a service card for informing the verifyer of the user's exercise status is distributed to the user. 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 doing exercise (exercising) such as radio calisthenics. For example, the user can notify the verifyer that the user is out by placing a service card indicating the out status in the card reader 200.
[0133] 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. Also, 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.
[0134] 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 transmitting unit 232 of the read card ID and the reading time.
[0135] 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 when the service card 100 was removed 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.
[0136] The reader transmitting unit 232 transmits the card ID 110 read by the card reading unit 231 from the service card 100, the device ID 221 (user identifier of the user), and the read time (information indicating that the card ID 110 has been read) when the card reading unit 231 read the card ID 110 to the management server 300c. The reader transmitting unit 232 also transmits the removal time (information indicating that the service card 100 has been removed) when the service card 100 was removed, together with the card ID 110 and the device ID 221, to the management server 300c.
[0137] 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." The display unit 280 may also issue a notice urging the user to remove the service card 100 from the installation unit 290 by blinking an LED (light emitting diode) that the display unit 280 has.
[0138] Here, when operation button 210 (operation unit) is pressed, output control unit 235 may stop control of speaker 240 and / or display unit 280. For example, from the viewpoint of crime prevention, it is not desirable for the notification unit to continue to notify while the user is out. Therefore, the user can stop such notifications by pressing operation button 210 when going out.
[0139] 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 the service card 100 for informing the user that he / she is out, the speaker 240 outputs the sound "Take care." Alternatively, when the card reading unit 231 reads the service card 100 for informing the user that he / she is doing radio calisthenics, the speaker 240 outputs the sound of radio calisthenics. The sound source output by the speaker 240 is stored in the storage unit 220 of the card reader 200c. The sound source output by the speaker 240 may be acquired from the management server 300c.
[0140] (Configuration of management server 300c) 11, management server 300c includes a storage unit 310c and a control unit 320c. Storage unit 310c stores user information 311, exercise information 319, and exercise history information 312. Control unit 320 includes an analysis unit 322, an information provision unit 326, a history registration unit 325, and a determination unit 328. Management server 300c according to this embodiment is, for example, a server managed by an operating company that operates service provision system 1. For example, management server 300c also functions as a web server.
[0141] FIG. 13 is a schematic diagram showing an example of the configuration of exercise information 319. FIG. 13 is merely an example, and exercise information 319 may have any configuration. Exercise information 319 has the following 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.
[0142] FIG. 14 is a schematic diagram showing an example of the configuration of exercise history information 312. FIG. 14 is merely an example, and exercise history information 312 may have any configuration. Exercise history information 312 has the following items: "Sent time," "Personal information," and "Exercise status." "Sent time" is the reading time or removal time sent from 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.
[0143] The analysis unit 322 (reception unit) analyzes and extracts the card ID 110, the device ID 221, and the read time or removal time from the data received from the card reader 200c.
[0144] 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 read time 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 FIG. 13). Furthermore, the information providing unit 326 identifies the exercise status of the exercise corresponding to the card ID 110 depending on whether the read time or the removal time has been acquired. For example, when the information providing unit 326 acquires the read time, it determines that the exercise corresponding to the card ID 110 has started. Furthermore, when the information providing unit 326 acquires the removal time, it determines that the exercise corresponding to the card ID 110 has ended (see FIG. 14). Furthermore, the information providing unit 326 identifies the personal information of the user, including the contact information of the user 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 by the above-described method, and the user's contact information in exercise history information 312 on the storage unit 310c via the history registration unit 325 (described later). 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.
[0145] The history registration unit 325 acquires 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. That is, the history registration unit 325 registers the exercise history, which is the history of the user's transmission of card ID 110, in association with the user's personal information including the user ID in the exercise history information 312.
[0146] 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 checks the user's health condition. Alternatively, the determination unit 328 may transmit the determination result to the checker terminal 500, and the checker may check the user's health condition.
[0147] (Example of card reader 200c operation) 15 is a flowchart showing the processing of the control unit 230c of the card reader 200c. The processing of the control unit 230c transmitting the user's exercise status to the management server 300c will be described below with reference to FIG.
[0148] 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 when the card ID 110 is read using a timer (not shown) (S42). The card reading unit 231 notifies the reader transmitting unit 232 of the read card ID 110 and the read time. The reader transmitting unit 232 transmits the card ID 110, the device ID 221, and the read time to the management server 300c (S43).
[0149] 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 acquires the removal time when the service card 100 was removed 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).
[0150] (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.
[0151] As shown in FIG. 16, first, the analysis unit 322 receives the card ID, the device ID, and the reading time or the removal time from the reader transmission unit 232 (S51). That is, the analysis unit 322 analyzes and extracts the card ID 110, the device ID 221, and the reading time or the 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 storage unit 310c (S52). Next, the information providing unit 326 transmits the exercise status, the user's contact information, and the reading time or the removal time to the verifying terminal 500 (S53). The information providing unit 326 may transmit 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 information such as the exercise status to the verifying terminal 500. The checker terminal 500 acquires information such as the status of exercise using a web application or web browser and displays the information. The checker can check the user's health condition by checking the type of exercise (going out, exercising, etc.), frequency, duration, etc. If necessary, the checker can also contact the user using the user's contact information.
[0152] As described above, the card reader 200c can transmit the user's exercise status to the inquirer terminal 500 via the management server 300c. That is, the user can notify the inquirer of the exercise status by a simple method such as installing the service card 100 in the installation unit 290 of the card reader 200c. In addition, since the exercise status is notified to the inquirer by the user's voluntary action of installing the service card 100 in the card reader 200c, the user does not feel stressed about being monitored. Furthermore, the card reader 200c can prompt the user to notify the inquirer of the exercise status by periodically (at a predetermined timing) notifying the notification unit.
[0153] In this embodiment, the case where the card reader 200c acquires the read time when the card ID 110 is read or the removal time when the service card 100 is removed has been described, but the present invention is not limited to this configuration. For example, the management server 300c may acquire the time when the card ID 110 and the device ID 221 are received from the card reader 200c as the read time indicating the time when the card ID 110 was read by the card reading unit 231 or the removal time indicating the time when the service card 100 was removed. In this case, the card reading unit 231 does not need to acquire the read time or the removal time. The reader transmitting unit 232 transmits the card ID 110, the device ID 221, and information indicating that the card ID 110 has been read or information indicating that the service card 100 has been removed to the management server 300c. The information providing unit 326 transmits the time at which it received the card ID 110, the device ID 221, and the information indicating that the card ID 110 has been read as a read time to the checker terminal 500. Similarly, the information providing unit 326 transmits the time at which it received the card ID 110, the device ID 221, and the information indicating that the service card 100 has been removed as a removal time to the checker terminal 500.
[0154] (Safety notification via operation button) In the service providing system 1c, a user may operate the operation button 210 every day during a first predetermined period to notify the checker of his / her 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 his / her safety. Alternatively, the user may install the service card 100 shown 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 his / her safety. Alternatively, the user may install the service card 100 shown in the fourth embodiment in the card reader 200 without pressing the operation button 210, and have the card reading unit 231 automatically read the card ID 110 to notify the checker of his / her safety.
[0155] Here, for a user who has not operated the operation button 210 during a first predetermined period, the card reader 200c notifies the user at a predetermined timing during a second predetermined period, urging the user to operate the operation button 210. 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 after 10:00 AM.
[0156] When the operation button 210 is pressed, the operation input unit 237 acquires the pressing time of the operation button 210 using a timer (not shown). The reader transmission unit 232 transmits the device ID 221 and the pressing time to the management server 300c.
[0157] Here, operation input unit 237 determines whether operation button 210 has been pressed within the first predetermined period. If operation button 210 has not been pressed within the first predetermined period, output control unit 235 controls speaker 240 and / or display unit 280 to notify the user to prompt them to operate operation button 210.
[0158] The analysis unit 322 analyzes and extracts the device ID 221 and the pressing time 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 pressing time in the operation history information 314.
[0159] The determination unit 328 determines, for each of a plurality of 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 for whom the 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 inquirer terminal 500. Based on the display screen, the inquirer checks the safety of users for whom the operation button 210 has not been operated (by calling, rushing to the location, etc.).
[0160] Fig. 17 is a diagram showing a specific example of a display screen displayed on the checker terminal 500. The display screen shown in Fig. 17 shows the name of the user and whether or not the user has operated the operation button 210 for each date. In the example shown in Fig. 17, if there is a user who has not operated (used) the operation button 210 for three days, the checker (business operator) is notified of the user's contact information. Note that the timing of notifying the checker is not limited to this, and if there is a user who has not operated the operation button 210 for one day, the checker may be notified of the user's contact information.
[0161] As described above, the card reader 200c can notify a user who has not operated the operation button 210 during the first predetermined period to prompt the user to operate the operation button 210 during the 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 either.
[0162] (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.
[0163] The service identification object may have a service identifier and a user ID. In this case, the service identification object is issued exclusively for the user. The card readers 200, 200b, and 200c may read the service identifier and the user ID from the service identification object and transmit them to the management servers 300, 300a, and 300c. The management servers 300, 300a, and 300c may use the received user ID instead of the device ID to perform the above-mentioned processing.
[0164] [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 on an integrated circuit (IC chip) or the like, or may be realized by software.
[0165] In the latter case, the card readers 200, 200b, and 200c, the management servers 300, 300a, 300b, and 300c, and the 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 storing 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 central processing unit (CPU). The recording medium may be a "non-transitory tangible medium," such as a read-only memory (ROM), tape, disk, card, semiconductor memory, or programmable logic circuit. The computer may also include a random access memory (RAM) for loading the program. The program may be supplied to the computer via any transmission medium capable of transmitting the program (such as a communication network or broadcast waves). Note that one aspect of the present invention may also be realized in the form of a data signal embedded in a carrier wave, in which the program is embodied by electronic transmission.
[0166] 〔summary〕 The identifier reader according to 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.
[0167] According to the above configuration, the identifier reader can transmit the user's exercise status to the management server. That is, the user can communicate the status of their exercise to a person (verifier) who is responsible for watching over the user via the management server. In addition, since the user's exercise status is communicated to theverifier through the user's voluntary action, such as having the identifier reader read the exercise identification object, the user does not feel stressed about being watched.
[0168] An identifier reader according to aspect 2 of the present invention may be such that, in aspect 1 above, the identifier reader is formed with an installation section for installing the motion identification object, the reading section reads the motion identifier from the motion identification object installed in the installation section, and the reader transmitting section transmits information to a management server indicating that the motion identification object has been removed from the installation section.
[0169] According to the above configuration, the user can notify the inspector of the status of their exercise by simply 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 exercise identification object indicating that the user is out is removed from the identifier reader, the inspector can confirm that the user has returned home.
[0170] The identifier reader of aspect 3 of the present invention may, in aspect 2 above, be provided with a notification unit that, at a predetermined timing after the reading unit reads the motion identifier, issues a notification urging the user to remove the motion identification object from the installation unit if the motion identification object is installed in the installation unit.
[0171] According to the above configuration, the identifier reader can prompt the user to report the status of their exercise (for example, to report that they have returned home).
[0172] An identifier reader according to a fourth aspect of the present invention may be configured in the third aspect above, further comprising an operation unit that accepts user operations, and when the operation unit is operated, the notification unit stops the notification.
[0173] From the viewpoint of crime prevention, it is undesirable for the notification unit to continue to send notifications while the user is out. With the above configuration, the user can stop such notifications by operating the operation unit when they are out.
[0174] The identifier reader according to aspect 5 of the present invention, in any one of aspects 1 to 4 above, may further include a sound output unit that outputs a predetermined sound corresponding to the exercise identifier when the reading unit reads the exercise identifier.
[0175] A service providing system according to a sixth aspect of the present invention includes an identifier reader according to any one of the first to fifth aspects above, and a management server, and 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 in association with the content of the exercise, 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.
[0176] A service provision system according to aspect 7 of the present invention may be configured such that, in aspect 6 above, the memory unit stores contact information of multiple users in association with user identifiers of multiple users, and the transmission unit transmits the contact information of the users to the verifying terminal.
[0177] In the service providing system of 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 memory unit in association with the user's user identifier, and a judgment unit that judges whether or not the user's health condition needs to be checked based on the exercise history.
[0178] 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. [Explanation of symbols]
[0179] 1c Service provision system 100 Service Card (Motion Identification Object) 110 Card ID (exercise identifier) 200c Card Reader (Identifier Reader) 210 Operation button (operation part) 220, 310c storage unit 221 Device ID (user identifier, reader identifier) 230c, 320c control unit 231 Card reader (reader) 232 Reader transmitter 235 Output control section 240 Speaker (notification unit, audio output unit) 280 Display section (notification section) 290 Installation section 300c Management Server 311 User information 312 Exercise history information 319 Exercise information 322 Analysis unit (receiving unit) 325 History Registration Department 326 Information Provision Department (Transmission Department) 328 Judgment Department 500 Confirmer terminal
Claims
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. A system including 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.
7. 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.
Citation Information
Patent Citations
Physical information management method, management device, physical information management system and recording medium
JP2002203051A
Time management system
JP2006127263A
Electronic apparatus
JP2010141501A
Semiconductor element, authentication device, and authentication system
JP2010286936A
Information processing device and program
JP2016067519A