WO2022208806A1 - チェックインシステム、チェックイン方法、及びプログラム - Google Patents

チェックインシステム、チェックイン方法、及びプログラム Download PDF

Info

Publication number
WO2022208806A1
WO2022208806A1 PCT/JP2021/014022 JP2021014022W WO2022208806A1 WO 2022208806 A1 WO2022208806 A1 WO 2022208806A1 JP 2021014022 W JP2021014022 W JP 2021014022W WO 2022208806 A1 WO2022208806 A1 WO 2022208806A1
Authority
WO
WIPO (PCT)
Prior art keywords
check
user
information
service
code
Prior art date
Application number
PCT/JP2021/014022
Other languages
English (en)
French (fr)
Inventor
祥子 福島
Original Assignee
楽天グループ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天グループ株式会社 filed Critical 楽天グループ株式会社
Priority to JP2022509071A priority Critical patent/JP7142185B1/ja
Priority to PCT/JP2021/014022 priority patent/WO2022208806A1/ja
Publication of WO2022208806A1 publication Critical patent/WO2022208806A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services

Definitions

  • This disclosure relates to a check-in system, a check-in method, and a program.
  • Patent Document 1 a restaurant application installed on a user terminal displays a two-dimensional code, and a terminal installed in the restaurant reads the two-dimensional code, thereby allowing the user to check in to the restaurant. In-service is stated.
  • Patent Document 1 the user only checks in to a restaurant that is a member of the check-in service available from the restaurant app, and cannot check in to the restaurant from other services.
  • the user needs to manage information for each service, so managing the information required for check-in is complicated.
  • One of the purposes of this disclosure is to simplify the management of information necessary for check-in at places visited by users.
  • a check-in system when a user of a first service visits a location related to a second service, uses at least one of the user terminal of the user and the check-in terminal of the location. obtaining means for obtaining first information that can identify the user with the first service; and check-in to the location based on the first information or second information associated with the first information. and a check-in execution means to execute.
  • FIG. 4 is a diagram showing an example of how a user visits a hotel and checks in in the first embodiment
  • 2 is a functional block diagram showing an example of functions realized by the check-in system of the first embodiment
  • FIG. It is a figure which shows the data storage example of a 1st database. It is a figure which shows the data storage example of a 2nd database.
  • FIG. 2 is a flow diagram showing an example of processing executed by the check-in system of the first embodiment
  • FIG. FIG. 2 is a flow diagram showing an example of processing executed by the check-in system of the first embodiment
  • FIG. It is a figure showing an example of the whole check-in system composition of a 2nd embodiment. It is a figure which shows an example of the procedure which purchases a ticket from a 2nd service in 2nd Embodiment. It is a figure which shows an example of the screen displayed from a 1st application in 2nd Embodiment. It is a figure which shows an example of a mode that a user visits a stadium and checks in in 2nd Embodiment. It is an example of the functional block diagram in a modification.
  • FIG. 10 is a diagram showing an example of a home screen of the first application in modification 1;
  • FIG. 11 is a diagram showing an example of a check-in system of modification 2;
  • FIG. 11 is a diagram showing an example of a check-in system of modification 3;
  • FIG. 13 is a diagram showing an example of a check-in system of modification 4;
  • FIG. 13 is a diagram showing an example of a check-in system of modification 5;
  • FIG. 21 is a diagram showing an example of a check-in system of modification 6;
  • FIG. 22 is a diagram showing an example of a screen displayed on the user terminal of modification 8;
  • FIG. 1 is a diagram showing an example of the overall configuration of a check-in system according to the first embodiment.
  • the check-in system S includes a first server 10, a second server 20, a user terminal 30, and a check-in terminal 40.
  • Each of the first server 10, the second server 20, the user terminal 30, and the check-in terminal 40 can be connected to a network N such as the Internet.
  • the check-in system S may include at least one computer, and is not limited to the example of FIG.
  • the first server 10 is a server computer for the first service.
  • SNS Social Networking Service
  • the first service is not limited to the example of the first embodiment, and may be any service. Application examples of other services will be described later in a second embodiment and modifications.
  • the first server 10 includes a control unit 11, a storage unit 12, and a communication unit 13.
  • Control unit 11 includes at least one processor.
  • the storage unit 12 includes a volatile memory such as RAM and a nonvolatile memory such as a hard disk.
  • the communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.
  • the second server 20 is a server computer for the second service.
  • a travel reservation service will be described as an example of the second service.
  • the second service is a service that can cooperate with the first service.
  • the second service is a service different from the first service.
  • the second service is not limited to the example of the first embodiment. Application examples of other services will be described later in a second embodiment and modifications.
  • the second server 20 includes a control section 21 , a storage section 22 and a communication section 23 . Physical configurations of the control unit 21, the storage unit 22, and the communication unit 23 are the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.
  • the user terminal 30 is a computer operated by a user.
  • the user terminal 30 is a smartphone, tablet terminal, wearable terminal, or personal computer.
  • the user terminal 30 includes a control section 31 , a storage section 32 , a communication section 33 , an operation section 34 , a display section 35 , an imaging section 36 , an IC chip 37 and a GPS reception section 38 .
  • Physical configurations of the control unit 31, the storage unit 32, and the communication unit 33 are the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.
  • the operation unit 34 is an input device such as a touch panel.
  • the display unit 35 is a liquid crystal display or an organic EL display.
  • the imaging unit 36 includes at least one camera.
  • the IC chip 37 may be any standard chip, for example, a FeliCa (registered trademark) chip or a so-called Type A or Type B chip in the contactless standard.
  • GPS receiver 38 includes a receiver that receives signals from satellites. The GPS receiver 38 is used to acquire the current position or current date and time.
  • the check-in terminal 40 is a computer located at a facility that can be reserved from the second service.
  • the check-in terminal 40 is a personal computer, tablet terminal, or smart phone.
  • the check-in terminal 40 includes a control section 41 , a storage section 42 , a communication section 43 , an operation section 44 , a display section 45 and a reading section 46 .
  • the physical configurations of the control unit 41, the storage unit 42, the communication unit 43, the operation unit 44, and the display unit 45 are the same as those of the control unit 11, the storage unit 12, the communication unit 13, the operation unit 34, and the display unit 35, respectively.
  • the reading unit 46 includes a code reader or camera. The reading unit 46 may be connected to the outside of the check-in terminal 40 .
  • At least one of the programs and data stored in each of the first server 10, the second server 20, the user terminal 30, and the check-in terminal 40 may be supplied via the network N. Further, each of the first server 10, the second server 20, the user terminal 30, and the check-in terminal 40 has a reading unit (for example, an optical disk drive or a memory card slot) that reads a computer-readable information storage medium, and an external device. and an input/output unit (for example, a USB port) for inputting/outputting data. For example, at least one of the program and data stored in the information storage medium may be supplied via at least one of the reading section and the input/output section.
  • a reading unit for example, an optical disk drive or a memory card slot
  • an input/output unit for example, a USB port
  • a case where the user checks in to a hotel reserved from the second service is taken as an example.
  • a common user ID and password are used for the first service and the second service.
  • a user can log into both the first service and the second service with one set of user ID and password.
  • the user logs into the second service and makes a hotel reservation.
  • FIG. 2 is a diagram showing an example of a procedure for making a hotel reservation from the second service in the first embodiment.
  • the top page P1 of the second service is displayed.
  • the user may use the second service from a second application, which is an application of the second service.
  • the second application can be installed on the user terminal 30 .
  • the user enters any search criteria from the top page P1 and searches for the desired hotel.
  • the login page P2 for the second service is displayed.
  • the user enters the user ID and password in the input forms F20 and F21 and selects the button B22, the user logs in to the second service and completes the hotel reservation.
  • the user terminal 30 displays a reservation completion page P3 indicating that the hotel reservation has been completed.
  • the details of the user's reservation and the check-in method for the day are displayed.
  • the user uses the first application, which is the application of the first service, to check into the hotel.
  • a first application is installed in the user terminal 30 .
  • the user may use the first service from a browser. In this case, check-in may be performed using the browser screen.
  • FIG. 3 is a diagram showing an example of a screen displayed from the first application in the first embodiment.
  • a process for logging into the first service is executed between the first server 10 and the user terminal 30 .
  • Input of the user ID and password may be requested at the timing when the first application is activated.
  • the first embodiment a case will be described in which the user has logged in to the first service in the past and the input of the user ID and password is omitted.
  • the home screen G4 of the first application is displayed.
  • the user can use the first service by selecting another user from the home screen G4 and sending a message, or by adding another user as a friend from the home screen G4.
  • the home screen G4 includes a button B40 for displaying the code for the first service and a button B41 for displaying the code for the second service.
  • display screen G5 including code C50 for the first service is displayed.
  • code C50 is used for adding friends in the first service.
  • the code C50 displayed by a certain user A is read by the user terminal 30 of another user B, the other user B can add user A as a friend.
  • Code C50 may be used for other purposes in the first service.
  • Code C50 includes an ID that can identify the user in the first service. This ID may be the user ID described above, but in the first embodiment, the case of information different from the user ID will be described. Hereinafter, this ID will be referred to as code ID.
  • An expiration date is set for the code ID.
  • the first server 10 issues a new code ID and updates the code ID and the expiration date when the expiration date of a certain code ID has passed.
  • the code ID and expiration date are held in the first server 10 in association with the user ID.
  • the code ID does not have to have an expiration date.
  • Code C50 may include information other than the code ID.
  • Code C60 includes a code ID.
  • Code C60 may include information other than the code ID. Also, the code ID included in code C50 and the code ID included in code C60 may be different. That is, multiple code IDs may be issued. As shown in display screen G6, code C60 can be used for check-in at hotels nationwide. Code C60 can also be used for check-ins at other establishments other than hotels. When the user visits the hotel on the day of the stay, the user activates the first application and causes the display screen G to display the code C60.
  • FIG. 4 is a diagram showing an example of how a user visits a hotel and checks in in the first embodiment.
  • a guide screen G7 is displayed to guide the user to hold the check-in code of the first application over the reading unit 46.
  • FIG. The user holds the code C60 over the reading unit 46 of the check-in terminal 40 .
  • the check-in terminal 40 transmits the code ID included in the code C60 to the first server 10 .
  • the first server 10 identifies the user ID associated with the code ID and transmits this user ID to the second server 20.
  • the second server 20 acquires the reservation details associated with this user ID, and executes check-in based on this reservation details.
  • the check-in terminal 40 displays a completion screen G8 including information such as the name and address that the user entered at the time of reservation.
  • the check-in terminal 40 ejects the room key of the room reserved by the user. The user receives the room key and moves to this room.
  • the check-in system S of the first embodiment uses the check-in code C60 displayed by the first application to check in to the hotel reserved by the second service. Since the information necessary for check-in is centrally managed by the first application, the management of the information necessary for check-in can be simplified. The details of this technique are described below.
  • FIG. 5 is a functional block diagram showing an example of functions realized by the check-in system S of the first embodiment.
  • the first server 10 implements a data storage unit 100, a receiving unit 101, an issuing unit 102, and a first service providing unit 103.
  • FIG. The data storage unit 100 is realized mainly by the storage unit 12 .
  • Each of the receiving unit 101 , the issuing unit 102 , and the first service providing unit 103 is realized mainly by the control unit 11 .
  • the data storage unit 100 stores data necessary for providing the first service to the user and data necessary for user check-in.
  • the data storage unit 100 stores a first database DB1.
  • FIG. 6 is a diagram showing an example of data storage in the first database DB1.
  • the first database DB1 is a database that stores information about users who have made use settings for the first service.
  • the first database DB1 stores a user ID, password, code ID, expiration date, name, and usage status of the first service.
  • the user ID is an example of the second information. Therefore, the user ID can be read as the second information.
  • the second information is not limited to the user ID, and may be any information that can identify the user in at least the second service.
  • the second information may be information called by another name such as a user account instead of information called an ID, or an e-mail address may be used as the second information.
  • the second information may be a user ID uniquely issued for the second service instead of a user ID shared with the first service.
  • the code ID is an example of the first information. Therefore, the code ID can be read as the first information.
  • the first information is not limited to the code ID, and may be any information that can identify the user in at least the first service.
  • the first information may be information called by another name such as a user account instead of information called an ID, or an e-mail address may be used as the first information.
  • the user ID may correspond to the first information.
  • the second information which will be described later, does not exist, and the second information may not be used for check-in.
  • the first information may be a user ID uniquely issued for the first service instead of a user ID shared with the second service.
  • the second information since it is necessary to specify the user on the side of the second service, the second information may exist and be used for check-in.
  • the association between the first information and the second information may be managed by the second database DB2 instead of the first database DB1.
  • the user's membership registration procedure is common to the first service and the second service.
  • a user ID that is information that can identify the user is issued for both the first service and the second service.
  • user registration information associated with a user ID is stored in a management database different from the first database DB1 and the second database DB2.
  • the registration information includes a password, name, address, telephone number, and the like. Registration information may include other personal information.
  • the user After the user has completed the membership registration procedure, the user will carry out the procedure for setting up the use of the first service.
  • this usage setting procedure When this usage setting procedure is completed, a record corresponding to the user is created in the first database DB1. This record stores the user ID, password, and name stored in the management database.
  • the first server 10 manages code IDs and user IDs in association with each other using the first database DB1.
  • Code IDs and user IDs may be stored in an external database. That is, the first server 10 may use an external database to manage the association between code IDs and user IDs.
  • the first server 10 transmits to the second server 20 the user ID associated with the code ID acquired by the code ID acquisition unit 401 described later.
  • the usage status of the first service should store the content corresponding to the first service.
  • the SNS service corresponds to the first service, so the usage status of the first service includes the group to which the user belongs, the user's friends, and the user's talk content.
  • the first service information is updated when the user uses the first service.
  • the information stored in the first database DB1 is not limited to the example shown in FIG. 6, and arbitrary information may be stored. For example, information for logging in to the first service without entering a user ID and password may be stored.
  • the accepting unit 101 accepts a code ID issue request from the user terminal 30 .
  • the issuance request is made by transmitting data in a predetermined format.
  • the issuance request can be sent at any timing, for example, the timing when the first application is activated, the timing when the user logs in to the first service, the timing when the expiration date of the code ID has passed, or when the code ID is issued by the user. is sent at the specified timing.
  • the issuing unit 102 issues a code ID and transmits it to the user terminal 30 when the issuing request is accepted.
  • the issuing unit 102 issues a code ID based on a predetermined ID issuing rule so as not to overlap with other code IDs.
  • the issuing unit 102 may randomly issue a code ID based on random numbers.
  • the issuing unit 102 determines a time after the current date and time by a predetermined time as the expiration date of the code ID.
  • the issuing unit 102 stores the code ID and the expiration date in the first database DB1 in association with the user ID of the user who made the issue request. In the first embodiment, a case where the issuing unit 102 also transmits the expiration date to the user terminal 30 will be described, but the expiration date does not have to be sent to the user terminal 30 .
  • the first service providing unit 103 provides the first service to the user.
  • the first service providing unit 103 may execute processing according to the content of the first service.
  • the SNS service corresponds to the first service. Therefore, for example, the first service providing unit 103 sets the first service in the first database DB1 so that the message input by the user is transmitted to other users. Update service information. Also, for example, when a user adds a friend using code C50, the first service providing unit 103 updates the first service information in the first database DB1 so that the user's friend is added. .
  • the data storage unit 200 is implemented mainly by the storage unit 22 .
  • Each of the second service providing unit 201 and the check-in executing unit 202 is realized mainly by the control unit 21 .
  • the data storage unit 200 stores data necessary for providing the second service to the user and data necessary for user check-in.
  • the data storage unit 200 stores the second database DB2.
  • FIG. 7 is a diagram showing a data storage example of the second database DB2.
  • the second database DB2 is a database that stores information about users who have made use settings for the second service.
  • the second database DB2 stores user IDs, passwords, names, application information, and check-in information.
  • the user After the user has completed the membership registration procedure, the user will carry out the procedure for setting up the use of the second service.
  • this usage setting procedure When this usage setting procedure is completed, a record corresponding to the user is created in the second database DB2. This record stores the user ID, password, and name stored in the management database.
  • the application information is information on the content of the application for the second service.
  • a hotel reservation corresponds to an application for the second service. Therefore, the description of the hotel reservation can be read as the application for the second service.
  • An application for the second service is an application made from the second service or an application for using the second service.
  • the hotel reservation is an application made from the second service.
  • the application for the second service is not limited to hotel reservations, and may be an application corresponding to the second service.
  • reservations for other facilities such as tourist facilities, public facilities, amusement facilities, restaurants, or beauty salons may correspond to applications.
  • a reservation for an airplane, a train, a rental car, or the like may correspond to an application.
  • purchase of a ticket in a second embodiment described later also corresponds to an application.
  • the application information should include the content corresponding to the second service.
  • a hotel reservation corresponds to an application, so the application information indicates the details of the hotel reservation.
  • the application information includes information that can identify the hotel (hotel name, hotel ID, etc.), check-in date, check-out date, guest's name, address, and telephone number.
  • the check-in information is information about check-in status.
  • the check-in information includes whether or not check-in was performed, and the date and time when check-in was performed.
  • the second database DB2 allows the second server 20 to associate and manage user IDs and application information.
  • the user ID and application information may be stored in an external database. That is, the second server 20 may use an external database to manage the association between the user ID and the application information.
  • the code ID may be shared by the second server 20 and the application information may be associated with the code ID. In this case, the application information can be retrieved from the code ID without going through the user ID.
  • the second server 29 associates and manages the user ID and the application information for each of the plurality of hotels. That is, application information is managed for each reservation.
  • Information stored in the second database DB2 is not limited to the example shown in FIG. 7, and arbitrary information may be stored. For example, a code ID may be stored.
  • the data storage unit 200 may also store data such as the top page P1, basic hotel information, and vacant room information.
  • a second service providing unit 201 provides a second service to the user.
  • the second service providing unit 201 may execute processing according to the content of the second service.
  • the travel reservation service corresponds to the second service, so for example, the second service providing unit 201 provides the user with a page (top page P1, etc.) for accepting hotel reservations.
  • the second service providing unit 201 searches for hotels based on search conditions input by the user. Further, for example, when a certain user makes a reservation for a hotel, the second service providing unit 201 generates application information and stores it in the second database DB2 in association with this user.
  • the check-in executing unit 202 executes check-in to the hotel based on the code ID or the user ID associated with the code ID.
  • the second server 20 does not manage the code ID by itself, so the check-in execution unit 202 executes check-in to the hotel based on the user ID associated with the code ID.
  • the check-in executing section 202 executes check-in to the hotel based on the code ID. In this case, the user ID is not used for check-in.
  • Performing check-in means detecting that the user has visited the hotel. Identifying the user who visited the hotel or identifying the hotel visited by the user corresponds to executing check-in. For example, updating the check-in information in the second database DB2 corresponds to executing check-in. Also, for example, sending all or part of the user's application information to the check-in terminal 40 of the hotel visited by the user or another terminal of this hotel corresponds to executing check-in.
  • the user uses the second service to make a hotel reservation before visiting the hotel. Perform check-in.
  • the user ID of the user to be checked in may be specified by the second server 20 itself. Perform check-in based on the application information provided.
  • the check-in execution unit 202 updates the check-in information associated with this user ID.
  • the check-in executing unit 202 updates this check-in information so that it indicates that the user has already checked in and includes the current date and time as the check-in date and time.
  • the check-in executing unit 202 transmits all or part of the application information associated with this user ID to the check-in terminal 40 of the hotel visited by the user or another terminal of this hotel.
  • the hotel visited by the user can be identified by the terminal ID of the check-in terminal 40 .
  • the first server 10 receives the terminal ID together with the code ID from the check-in terminal 40 .
  • the first server 10 transmits this terminal ID to the second server 20 together with the user ID associated with this code ID.
  • the second server 20 receives the terminal ID and user ID from the first server 10.
  • the check-in executing unit 202 identifies the hotel visited by the user based on the terminal ID.
  • the check-in executing unit 202 executes check-in to this hotel based on the specified hotel application information among the plurality of application information. It is assumed that the relationship between the terminal ID and the hotel is stored in the data storage unit 200 in advance. That is, which terminal ID the check-in terminal 40 is located in which hotel is stored in advance in the data storage unit 200 . Instead of storing these relationships in the data storage unit 200, the check-in terminal 40 may transmit information that enables identification of the hotel in which it is located.
  • the user terminal 30 implements a data storage unit 300 and a display control unit 301 .
  • Data storage unit 300 is realized mainly by storage unit 32 .
  • the display control unit 301 is realized mainly by the control unit 31 .
  • the data storage unit 300 stores data necessary for the user to use each of the first service and the second service, and data necessary for check-in.
  • the data storage unit 300 stores the first application and code ID.
  • the user terminal 30 receives the code ID issued by the issuing unit 102 and records it in its own data storage unit 300 .
  • the user terminal 30 also receives the expiration date of the code ID, the user terminal 30 also records the expiration date in its own data storage unit 300 .
  • the display control unit 301 causes the display unit 35 to display the screens shown in FIGS. 2 and 3 .
  • the display control unit 301 can display the code including the code ID based on the first application for using the first service.
  • the display control unit 301 can display each of the code C50 for the first service and the code C60 for the second service.
  • the code C50 also includes the code ID, but the code C50 may include other information that can identify the user without including the code ID.
  • Code C50 is an example of the first code
  • code C60 is an example of the second code. Therefore, the portion described as code C50 can be read as the first code, and the portion described as code C60 can be read as the second code.
  • Each of the first code and the second code may be any code, and is not limited to the example of the first embodiment.
  • Each of the first code and the second code may be a bar code instead of a two-dimensional code, or a code whose appearance changes with the passage of time.
  • the display control unit 301 encodes the code ID stored in the data storage unit 300 and displays each of the codes C50 and C60.
  • the check-in terminal 40 implements a data storage unit 400 and a code ID acquisition unit 401 .
  • Data storage unit 400 is realized mainly by storage unit 42 .
  • Code ID acquisition section 401 is implemented mainly by control section 41 .
  • the data storage unit 400 stores data necessary for check-in.
  • the data storage unit 400 stores a terminal ID with which the check-in terminal 40 can be identified and information with which the first server 10 can be identified.
  • the data storage unit 400 may store information that can identify the hotel where the check-in terminal 40 is arranged.
  • the code ID acquisition unit 401 uses at least one of the user terminal 30 of the user and the check-in terminal 40 of the hotel to identify the user with the first service. Get the code ID of the possible user.
  • the case where both the user terminal 30 and the check-in terminal 40 are used will be described. may
  • the code ID is recorded in the data storage unit 300 of the user terminal 30, so the code ID acquisition unit 401 acquires the code ID recorded in the user terminal 30.
  • the code ID acquisition unit 401 acquires the code ID when the code C60 is read by the check-in terminal 40 .
  • the check-in terminal 40 may be a terminal for acquiring the code ID, and may be any terminal that corresponds to the method of acquiring the code ID.
  • the code ID does not have to be acquired optically, and may be acquired through communication.
  • a communication device capable of communicating with the user terminal 30 may correspond to the check-in terminal.
  • the communication itself can use any protocol, for example, Wi-Fi (registered trademark), Bluetooth (registered trademark), or infrared communication. It may be wireless communication.
  • a hotel is an example of a place related to the second service. Therefore, the place described as a hotel can be read as a place related to the second service.
  • the place related to the second service is the place where the application is made using the second service or the place where the second service is provided.
  • the place related to the second service may be other facilities such as tourist facilities, public facilities, airports, stations, stores, restaurants, or beauty salons, or may be special facilities such as outdoor spaces and bus stops.
  • the non-existent location may be the location for the second service.
  • FIGS. 8 and 9 are flow diagrams showing an example of processing executed by the check-in system S of the first embodiment.
  • the processes shown in FIGS. 8 and 9 are executed by each of the control units 11, 21, 31, 41 operating according to the programs stored in the storage units 12, 22, 32, 42, respectively.
  • the processing in FIGS. 8 and 9 is an example of processing executed by the functional blocks in FIG.
  • hotel reservation processing is executed between the second server 20 and the user terminal 30 (S1).
  • S1 a hotel is reserved according to the flow described with reference to FIG.
  • the second server 20 generates application information based on the information received from the user terminal 30, and stores it in the second database DB2 in association with the user ID of the user who reserved the hotel.
  • the user terminal 30 When the user selects the first application from the operation unit 34, the user terminal 30 activates the first application stored in the storage unit 32 (S2), and executes login processing with the first server 10 ( S3).
  • the user terminal 30 transmits a login process execution request to the first server 10 .
  • This execution request includes information required for login, and corresponds to a code ID issuance request in the first embodiment.
  • the first server 10 executes login processing based on the information received from the user terminal 30 and the first database DB1.
  • the first server 10 When the login is successful, the first server 10 issues a code ID and transmits it to the user terminal 30 (S4). In S4, the first server 10 sets an expiration date to the issued code ID and stores it in the first database DB1 in association with the user ID for which the login was successful.
  • the user terminal 30 When receiving the code ID, the user terminal 30 records the code ID in the storage area of the first application in the storage unit 32 (S5). The expiration date of the code ID is also recorded in this storage area.
  • the user terminal 30 causes the display unit 35 to display the home screen G4 of the first application (S6). Thereafter, processing is executed according to the user's operation.
  • processing is executed according to the user's operation.
  • an operation to select the button B41 is performed will be described.
  • the code C50 is not displayed, and a new code ID is issued in the same manner as in S4 and S5.
  • the user terminal 30 displays the check-in code C60 on the display screen G6 based on the code ID recorded in the storage area of the first application (S7).
  • the user holds the code C60 displayed in S7 over the check-in terminal 40 when visiting the reserved hotel.
  • the check-in terminal 40 acquires the code ID included in the code C60 based on the reading result of the code C60 by the reading unit 46 (S8).
  • the check-in terminal 40 transmits the terminal ID and code ID to the first server 10 (S9).
  • the first server 10 acquires the user ID associated with the code ID based on the first database DB1 (S10).
  • the first server 10 transmits the terminal ID received from the check-in terminal 40 and the user ID obtained in S10 to the second server 20 (S11).
  • the second server 20 Upon receiving the terminal ID and user ID, the second server 20 acquires hotel application information associated with this user ID and corresponding to this terminal ID based on the second database DB2 (S12). If the application information associated with this user ID does not exist in the second database DB2, this process ends and check-in is not executed. Even if there is application information, if the hotel does not correspond to this terminal ID, this process ends and check-in is not executed.
  • the second server 20 executes check-in to the hotel based on the application information acquired in S12 (S13). In S ⁇ b>13 , the second server 20 updates check-in information associated with the user ID received from the first server 10 . The second server 20 also transmits all or part of the application information acquired in S12 to the check-in terminal 40 indicated by the terminal ID received from the first server 10 . Upon receiving all or part of the application information, the check-in terminal 40 causes the display unit 46 to display the completion screen G8 based on the application information (S14), and the process ends.
  • the code ID of the first service is used to check the hotel.
  • the check-in there is no need to manage information necessary for check-in separately from the first application, so management of information necessary for check-in can be simplified.
  • a check-in code for a hotel reserved by the user is sent by e-mail, and the user checks in by displaying this code on the user terminal 30 on the day of the stay. It is necessary to search for the code from the mail, and information management becomes complicated. In this regard, the number of pieces of information to be managed can be reduced by allowing the user to check in from the first application that he/she normally uses.
  • the check-in system S obtains the code ID and executes check-in with a simple operation such as reading the code C60. can.
  • the code C60 can be displayed from the first application and there is no need to manage the code for checking in at the hotel separately from the first application, the management of information required for check-in can be simplified.
  • the check-in system S acquires the code ID to obtain the first service code C50 and the check-in code C60. , can be used properly.
  • the user can use the first service and check-in to the hotel simply by operating the first application, which simplifies the management of user information.
  • the check-in system S when the check-in system S receives an issue request from the user terminal 30, the check-in system S issues a code ID, transmits it to the user terminal 30, and acquires the code ID recorded in the user terminal 30. It is possible to prevent the same code ID from being reused for a long period of time. This prevents spoofing by malicious third parties and increases security at check-in. For example, even if a malicious third party obtains a screenshot of code C60 in some way, if the code ID is changed, it will not be possible to check in with that screenshot, thus increasing security. Also, for example, by randomly generating the code ID, it becomes impossible for a third party to predict the code ID, which further enhances security. Also, for example, by shortening the interval for updating the code ID, the security is further enhanced.
  • the check-in system S can save the user time and effort during check-in by executing check-in based on the application information of the hotel reserved by the user. For example, the user does not need to register at the front desk of the hotel on the day of stay.
  • the check-in system S reduces the risk of leakage of the user ID and increases security by including the code ID instead of the user ID in the codes C50 and C60.
  • the user ID can be included in the codes C50 and C60, but there is a possibility that the user ID will be leaked to a malicious third party and unauthorized login will be performed.
  • the codes C50 and C60 do not include the user ID, it is possible to prevent leakage of the user ID to a third party and unauthorized login. Even if the code ID is leaked, it is only necessary to update to another code ID, and even if some information is leaked to a third party, there is no need to change the user ID.
  • the check-in system S allows the user to check-in to an appropriate hotel by executing check-in based on the application information of the hotel visited by the user. can be executed. Further, by standardizing the code C60 used for check-in at a plurality of hotels, it becomes unnecessary to manage the information necessary for check-in for each hotel, and information management can be simplified.
  • the first service and the second service may be any combination of services, and are not limited to the example of the first embodiment.
  • the first service is an electronic payment service and the second service is a ticket sales service.
  • the description of the same contents as in the first embodiment is omitted.
  • the first service of the second embodiment is a service that provides electronic payment.
  • the first service is a service that provides electronic payment using the user terminal 30 .
  • the payment means available from the first application may be of any type, such as credit cards, debit cards, electronic money, electronic cash, points, bank accounts, wallets, virtual currencies, or combinations thereof. good too.
  • the first service may provide electronic payment using the IC chip 37 of the user terminal 30.
  • the first service may provide electronic payment using a physical card such as an IC card or magnetic card without using the user terminal 30 .
  • the first service may provide electronic payment using the user himself (ie using biometrics) rather than the user's property. Any payment method can be used for these electronic payments as well.
  • the second service of the second embodiment is a service that accepts purchase applications for tickets related to places visited by users. This location is the location for the second service.
  • the ticket itself sold by the second service may be a ticket handled by a known play guide.
  • the case where the user purchases tickets for a baseball game using the second service will be taken as an example.
  • a stadium where a match is held is thus an example of a location for the second service. Where the stadium is explained, it can be read as the location for the second service.
  • This location may be any location that is listed on the ticket, such as a concert venue, theater, other event venue, movie theater, or museum location.
  • FIG. 10 is a diagram showing an example of the overall configuration of the check-in system S of the second embodiment.
  • the check-in system S includes a payment terminal 50 in addition to the configuration described in the first embodiment.
  • the check-in terminal 40 and payment terminal 50 are placed in the stadium.
  • the payment terminal 50 is a store computer in the stadium.
  • the store is located inside the stadium, but the store may be located outside the stadium as long as it is near the stadium.
  • the payment terminal 50 is a POS terminal, personal computer, tablet terminal, or smart phone.
  • the settlement terminal 50 includes a control section 51 , a storage section 52 , a communication section 53 , an operation section 54 , a display section 55 and a reading section 56 .
  • the physical configurations of the control unit 51, the storage unit 52, the communication unit 53, the operation unit 54, the display unit 55, and the reading unit 56 are the control unit 11, the storage unit 12, the communication unit 13, the operation unit 34, the display unit 35, respectively. , and the reading unit 46 .
  • the user logs into the second service and purchases a match ticket.
  • FIG. 11 is a diagram showing an example of the procedure for purchasing a ticket from the second service in the second embodiment.
  • the top page P9 of the second service is displayed.
  • the user inputs arbitrary search conditions from the top page P9 to search for a desired ticket.
  • the login page P10 for the second service is displayed.
  • the user When the user enters the user ID and password in the input forms F100 and F101 and selects the button B102, the user logs in to the second service and purchase of the ticket is completed.
  • the user may use the first service to pay for the ticket, or may use another payment means registered with the second service.
  • the user terminal 30 displays a purchase completion page P11 indicating that the purchase of the ticket has been completed. As shown in the purchase completion page P11, the check-in method itself to the stadium is the same as in the first embodiment. A user checks in to a stadium using the first application.
  • FIG. 12 is a diagram showing an example of a screen displayed from the first application in the second embodiment.
  • a code ID is issued in the same manner as in the first embodiment, and the home screen G12 of the first application is displayed.
  • a code C120 for electronic payment is displayed on the home screen G12.
  • Code C120 includes a code ID.
  • Code C120 corresponds to code C50 in the first embodiment.
  • the method of displaying code C120 is the same as the method of displaying code C50.
  • the user can use the code C120 to execute electronic payment. For example, after checking in at the stadium, the user can make the payment terminal 50 read the code C120, and can execute electronic payment based on the preset payment means (credit card in FIG. 12).
  • Code C120 is available at any store except stadiums. That is, code C120 can be used in locations other than those relating to the second service.
  • Various methods can be used for the execution method of electronic payment itself. For example, a method of reading a code displayed on the payment terminal 50 with the user terminal 30 , a method of reading a code printed on paper or the like and posted at a store with the user terminal 30 , a method of reading the IC chip 37 of the user terminal 30 to the payment terminal 50 A method of holding it over a reader/writer or a method of completing only an operation on the user terminal 30 may be used.
  • Code C130 includes a code ID.
  • Code C130 corresponds to code C60 of the second embodiment.
  • the method of displaying code C130 is the same as the method of displaying code C60 described in the first embodiment.
  • FIG. 13 is a diagram showing an example of how a user visits a stadium and checks in in the second embodiment.
  • the first server 10 and the second server 20 check-in is executed by the control of each of
  • the check-in terminal 40 displays the details of the ticket purchased by the user, and the user is permitted to enter.
  • the check-in terminal 40 may issue the ticket purchased by the user from a printer connected to itself.
  • Settlement terminals 50 are arranged at each of a plurality of positions in the stadium, and users can purchase products or use services at any store.
  • the salesperson may carry a portable payment terminal 50 with them.
  • the user purchases a drink at a seat, purchases goods at a shop, and pays for a meal at a restaurant by electronic payment using the first application.
  • the second server 20 identifies the user who has checked out via the first server 10
  • the second server 20 executes checkout processing.
  • the check-in terminal 40 displays a screen indicating that the check-out is completed. Once checkout is complete, the user exits the stadium entrance. Note that checkout may be omitted.
  • the application information stored in the second database DB2 is information on tickets purchased by users.
  • the application information includes the date and time, start time, seats, and price of the game for which the user purchased the ticket.
  • the information included in the application information is displayed on the check-in terminal 40 .
  • information required for electronic payment is stored in the first database DB1.
  • information related to payment means such as credit card information, electronic money information, electronic cash information, or bank account information is stored in the first database DB1 in association with the user ID.
  • information for identifying the payment method selected by the user among the plurality of payment methods is stored in the first database DB1 in association with the user ID.
  • the payment terminal 50 When the user causes the user terminal 30 to display the code C120 and holds it over the payment terminal 50, the payment terminal 50 reads the code C120, acquires the code ID, and obtains information necessary for electronic payment (payment amount, etc.) and the first Send to server 10 .
  • the first server 10 receives the code ID from the payment terminal 50 .
  • the first service providing unit 103 refers to the first database DB1 and identifies the payment method selected by the user based on the information associated with this code ID.
  • the first service providing unit 103 executes electronic payment based on the information (credit card information, etc.) regarding the specified payment means.
  • Various well-known methods can be used for the electronic payment execution method itself.
  • the first service providing unit 103 may execute electronic payment for ticket purchase. That is, the first service providing unit 103 may allow the user to pay for the ticket purchased using the second service by electronic settlement of the first service. Further, when the user can use predetermined services (in the example of FIG. 13, each service of drink purchase, goods purchase, and meal use) at the stadium, the first service providing unit 103 executes check-in. electronic payment for use at the stadium may be performed.
  • predetermined services in the example of FIG. 13, each service of drink purchase, goods purchase, and meal use
  • the check-in terminal 40 may have an electronic payment function.
  • code C120 includes information that can identify the use of the first service to perform electronic payment.
  • the check-in terminal 40 reads the code C120, it transmits this information to the first server 10 together with the code ID.
  • the first server 10 determines to let the first service providing unit 103 process based on this information.
  • the first service providing unit 103 may execute electronic payment according to the same flow as described above.
  • code C130 may include information that can be identified to perform check-in.
  • the check-in terminal 40 reads the code C130, it transmits this information to the first server 10 together with the code ID.
  • the first server 10 may determine to execute check-in processing based on this information.
  • the first server 10 may perform check-in processing according to the same flow as described above.
  • the payment terminal 50 may have a check-in function.
  • the first server 10 determines whether to cause the first service providing unit 103 to perform processing or to execute check-in processing based on the information contained in the codes C120 and C130. Judge. Alternatively, instead of including this information in the codes C120 and C130, the user may be allowed to select whether to use the first service or check-in to the stadium, as in Modification 1 described later. .
  • the first application of the first service which is an electronic payment service relatively frequently used by users, can also manage the check-in code C130 to the stadium. Management of information required for In addition, the user's convenience is enhanced by performing the electronic payment of the first service for the ticket reserved by the user.
  • check-in system S simplifies payment within the stadium and enhances convenience for the user by executing electronic payment for use in the stadium when check-in is executed. It becomes easier for the user to manage the amount of payment used in the stadium.
  • FIG. 14 is an example of a functional block diagram in a modified example. In the modified example described below, each function shown in FIG. 14 is realized.
  • Each of the permission unit 104 , the usage amount acquisition unit 105 , the information provision unit 106 , and the determination unit 107 is realized mainly by the control unit 11 .
  • Distribution unit 203 is realized mainly by control unit 21 .
  • the combination of the first service and the second service described in the second embodiment is taken as an example, the combination described in the first embodiment may also be used.
  • FIG. 15 is a diagram showing an example of the home screen G14 of the first application in Modification 1.
  • the user terminal 30 may be able to display a common code C140 for the first service and the second service. That is, the code for the first service and the code for check-in may be the same.
  • This common code contains a code ID.
  • a code ID issuing method is the same as in the first and second embodiments.
  • the first service providing unit 103 of Modification 1 provides the first service based on the code ID when the common code C140 is read by the payment terminal 50 for the first service.
  • the payment terminal 50 is an example of a first service terminal. Therefore, the description of the settlement terminal 50 can be read as the first service terminal.
  • the first service terminal may be a computer for providing the first service, and is not limited to the settlement terminal 50 placed in the stadium.
  • a computer located in a place unrelated to the stadium may correspond to the first service terminal. For example, convenience stores, supermarkets, other shops, vending machines, etc. may correspond to the first service terminal.
  • the data storage unit 100 of the first server 10 stores a terminal ID that can identify the first service terminal.
  • the first service terminal reads the common code C140 and obtains the code ID, it transmits its own terminal ID and this code ID to the first server 10 .
  • the first service providing unit 103 determines whether or not the computer that transmitted the terminal ID and code ID is the first service terminal based on the terminal ID.
  • the first service providing unit 103 determines that the computer that has transmitted the terminal ID and the code ID is the first service terminal, based on the payment method specified by the user of the user ID associated with this code ID, perform electronic payments; As for the execution method of electronic payment itself, a known method can be used as described in the second embodiment.
  • the code C140 is read by the settlement terminal 50 in the stadium, the first service providing unit 103 executes electronic settlement based on the above flow.
  • the code ID acquisition unit 401 of Modification 1 acquires the code ID when the common code C140 is read by the check-in terminal 40 .
  • the check-in terminal 40 transmits its own terminal ID and this code ID to the first server 10 in the same manner as in the first and second embodiments. Based on this terminal ID, the first server 10 identifies that the computer that has sent the terminal ID and code ID is the check-in terminal 40 . Thereafter, check-in is executed in the same flow as in the first and second embodiments.
  • the check-in terminal 40 may select whether to use the first service or check-in to the stadium.
  • the check-in terminal 40 transmits its own terminal ID and code ID to the first server 10 along with information that can identify the user's selection result. Based on this information, the first server 10 may determine whether to allow the first service providing unit 103 to process or to execute check-in processing.
  • the first server 10 either causes the first service providing unit 103 to process the user's selection result based on information that can be used to identify the user's selection, or causes the first service providing unit 103 to perform check-in processing. It suffices to determine whether to execute the process.
  • the content of the purchased ticket may be displayed on the user terminal 30.
  • the user terminal 30 requests the content of the purchased ticket from the second server 20 via the first server 10 .
  • the second server 20 transmits all or part of the application information stored in the second database DB2 to the user terminal 30 via the first server 10 or directly.
  • the user can perform check-in by code C140 while confirming the application information.
  • the code C140 of the first service and the second service when the code C140 common to the first service and the second service is read by the check-in terminal 40, the code C140 of the first service and the second service can be read by acquiring the code ID. It can be shared and the management of information can be simplified.
  • FIG. 16 is a diagram showing an example of the check-in system S of Modification 2.
  • the user has purchased tickets for each of multiple stadiums A to C, and the user can visit each of multiple stadiums A to C. .
  • the second database DB2 of the second server 20 stores application information for each of the plurality of stadiums A to C.
  • stadium A has a check-in terminal 40A
  • stadium B has a check-in terminal 40B
  • stadium C has a check-in terminal 40C.
  • the user terminal 30 of Modification 2 can display the code C140 common to the plurality of stadiums A to C.
  • FIG. A user can check into each of stadiums AC using code C140.
  • This code C140 is common for the first service and for check-in as in Modification 1, but the codes C60 and C130 for check-in are used as in the first and second embodiments. may be
  • the second server 20 associates the terminal ID of each of the check-in terminals 40A to 40C with the stadium ID by which the stadium can be identified, and stores them in the data storage unit 200. Therefore, the second server 20 can identify which stadium the user is going to check-in by acquiring the terminal ID.
  • the application information of the second server 20 includes the stadium ID. By acquiring the stadium ID associated with the terminal ID, the second server 20 can identify which stadium the user is checking in to.
  • the stadium ID is stored in each of the check-in terminals 40A-40C, and may be transmitted to the first server 10 from each of the check-in terminals 40A-40C.
  • the code ID acquisition unit 401 of the check-in terminal 40A acquires the code ID when the common code C140 is read by the check-in terminal 40A.
  • the check-in terminal 40A transmits its own terminal ID and code ID to the first server 10 .
  • the first server 10 refers to the first database DB1 and acquires the user ID associated with the code ID.
  • the first server 10 transmits this terminal ID and this user ID to the second server 20 .
  • the second server 20 receives the terminal ID and code ID from the first server 10.
  • the check-in execution unit 202 acquires the stadium ID associated with this terminal ID, and acquires the user ID associated with this code ID.
  • the check-in execution unit 202 acquires application information including this stadium ID from the application information associated with this user ID.
  • the check-in execution unit 202 executes check-in to stadium A based on this application information.
  • Check-in itself is as described in the second embodiment.
  • a screen indicating that the check-in is completed is displayed on the check-in terminal 40A of the stadium A, and the user passes through the entrance of the stadium A.
  • the second server 20 may specify which stadium B or stadium C the user intends to check in to based on the terminal ID received from the check-in terminal 40B or the check-in terminal 40C. The same applies when the user has purchased tickets for two or more stadiums.
  • the stadium that the user is trying to check in may be specified by the first server 10 .
  • the first server 10 stores the association between the terminal ID and the stadium ID in the data storage unit 100 .
  • the first server 10 acquires the stadium ID associated with the terminal ID received from the check-in terminal 40 and transmits it to the second server 20 together with the user ID.
  • the second server 20 receives the stadium ID and the user ID from the first server 10, and the subsequent processing of the check-in execution unit 202 may be the same as described above.
  • the code C140 can be made common to the plurality of stadiums, making information management easier.
  • FIG. 17 is a diagram showing an example of the check-in system S of Modification 3.
  • the user can use a plurality of second services, and can visit locations related to each of the plurality of second services.
  • a ticket purchase service, a travel reservation service, and a restaurant reservation service are exemplified as a plurality of second services.
  • the check-in system S includes a second server 20D for ticket purchase service, a second server 20E for travel reservation service, and a second server 20F for restaurant reservation service.
  • the user has already purchased tickets for a match held at a stadium from a ticket purchase service.
  • the second server 20D stores this ticket application information.
  • a check-in terminal 40D is arranged in this stadium. Details of the ticket purchase service are as described in the second embodiment.
  • the user has booked a hotel through a travel reservation service.
  • the second server 20E stores the application information for this hotel.
  • a check-in terminal 40E is arranged in this hotel. Details of the travel reservation service are as described in the first embodiment.
  • the second server 20F stores application information for restaurants.
  • application information includes information that can identify the restaurant, the date and time of reservation, the name of the person making the reservation, and the number of people.
  • a check-in terminal 40F is arranged in this restaurant.
  • the user terminal 30 of Modification 3 can display the code C140 common to a plurality of second services. The user can use this code C140 to check into each of the stadium, hotel and restaurant.
  • This code C140 is common for the first service and for check-in as in Modification 1, but the codes C60 and C130 for check-in are used as in the first or second embodiment. may be
  • the first server 10 associates the terminal ID of each of the plurality of check-in terminals 40D to 40F with information for identifying each of the plurality of second servers 20D to 20E, and stores the information in the data storage unit 100. . Therefore, by obtaining the terminal ID, the first server 10 can specify which second service location the user is trying to check in to.
  • the code ID acquisition unit 401 of the check-in terminal 40D acquires the code ID when the common code C140 is read by the check-in terminal 40D.
  • the check-in terminal 40 ⁇ /b>D transmits its own terminal ID and code ID to the first server 10 .
  • the first server 10 identifies the second server 20D associated with this terminal ID.
  • the first server 10 refers to the first database DB1 and acquires the user ID associated with the code ID.
  • the first server 10 transmits this terminal ID and this user ID to the identified second server 20D.
  • the second server 20D receives the terminal ID and code ID from the first server 10, and the subsequent processing of the check-in execution unit 202 may be the same as in the second embodiment.
  • check-in at the hotel or restaurant is executed by the same processing as described above.
  • the first server 10 Based on the terminal ID received from the check-in terminal 40E or check-in terminal 40F, the first server 10 identifies the second server 20E or second server 20F associated with this terminal ID.
  • the first server 10 may transmit this terminal ID and the user ID associated with the code ID to the specified second server 20E or second server 20F. Subsequent processing by the check-in execution unit 202 may be the same as described above.
  • Modification 3 by acquiring the code ID when the code C140 common to a plurality of second services is read by the check-in terminal 40, the code C140 of a plurality of second services is made common, and information Management can be simplified.
  • FIG. 18 is a diagram showing an example of the check-in system S of Modification 4. As shown in FIG. As shown in FIG. 18, in Modified Example 4, the user purchases tickets for each of a plurality of dates and times, and has already purchased tickets for 3/26, 3/27, and 3/28. . The procedure for purchasing individual tickets is as described in the second embodiment. In FIG. 18, since it is not necessary to distinguish the check-in terminals 40, unlike FIGS. 16 and 17, alphabetic letters at the end are omitted.
  • the second server 20 associates and manages user IDs and application information for each of a plurality of dates and times. That is, the record of the user who purchased the ticket in the second database DB2 stores the ticket application information for March 26th, the ticket application information for March 27th, and the ticket application information for March 28th. there is
  • the case where the user checks in to the stadium on 3/26 is taken as an example.
  • the flow until the terminal ID and user ID are transmitted to the second server 20 is the same as in the second embodiment.
  • the second server 20 acquires the current date and time using a real-time clock or the like.
  • the check-in executing unit 202 executes check-in based on the date and time when the user visited the stadium (that is, the current date and time) among the application information for each of the plurality of dates and times.
  • the check-in execution unit 202 acquires the application information corresponding to the current date and time from among the multiple pieces of application information associated with the user ID received from the first server 10 .
  • Application information corresponding to the current date and time means application information that matches the current date and time of the application information, application information that matches the current date and the date of the application information, or the difference between the current date and time and the date and time of the application information is less than the threshold. This is the application information for
  • the check-in execution unit 202 executes check-in based on the acquired application information. In the example of FIG. 18, the check-in executing unit 202 executes check-in on 3/26 based on the application information on 3/26.
  • the check-in execution method itself is as described in the second embodiment.
  • the current date and time may be acquired by the first server 10 or the check-in terminal 40 and transmitted to the second server 20 .
  • check-in is performed based on the application information for the date and time when the user visited the stadium, out of the application information for each of the plurality of dates and times when the user purchased the ticket.
  • the user may apply for multiple tickets using the second service.
  • the user who applied for the ticket is described as the first user UA, and the users to whom the ticket is distributed are described as the second users UB and UC.
  • a first user UA applies for and purchases three tickets for a match to be watched together with second users UB and UC.
  • the first user UA distributes tickets to each of the second users UB, UC. It is assumed that each of the first user UA and the second users UB and UC has completed usage settings for both the first service and the second service.
  • FIG. 19 is a diagram showing an example of the check-in system S of modification 5.
  • the second server 20 associates and manages the user ID of the first user UA and the application information for each of the plurality of tickets.
  • FIG. 19 shows only the user ID and application information of the second database DB2. Also, the content of the application information is shown in a simplified form such as "Ticket 1". As shown in FIG. 19, when the user A purchases three tickets, the application information for each of the three tickets is associated with the user ID "Yamada.Taro" of the first user UA. This state is the state before ticket distribution.
  • the check-in system S of modification 5 includes a distribution unit 203.
  • the first user UA performs an operation from his own user terminal 20A to distribute two of the three tickets to each of the second users UB and UC.
  • This operation itself may be a method used in known play guides. For example, when the first user UA logs in to the second service, the three purchased tickets are displayed on the user terminal 20A.
  • the first user UA designates the user IDs of each of the second users UB and UC and the tickets to be distributed.
  • Each of the second users UB and UC may be identified by other information such as a mail address instead of a user ID.
  • the distribution unit 203 associates the ticket application information of the second users UB and UC among the plurality of tickets with the user IDs of the second users UB and UC. distributes the tickets to the second users UB and UC. As shown in FIG. 19, the distribution unit 203 distributes two of the three pieces of application information associated with the user ID "Yamada.Taro" of the first user UA to the user IDs "Yamada.Taro" of the second users UB and UC. "hanako999" and "yoshida111jiro". As a result, the second and third tickets are distributed to each of the second users UB and UC. A notification to the effect that the ticket distribution has been completed is sent to the user terminals 20B and 20C of the second users UB and UC, respectively, using e-mail or the like.
  • the code ID obtaining unit 401 obtains the code ID of the first user UA when the first user UA visits the stadium, and obtains the code ID of the second users UB and UC when the second users UB and UC visit the stadium. Get the code ID of The code ID acquisition method itself may be the same as in the first and second embodiments.
  • the first server 10 refers to the first database DB1, acquires the user ID associated with the code ID of the first user UA, and acquires the user IDs associated with the code IDs of the second users UB and UC. The first server 10 transmits these user IDs to the second server 20 .
  • the check-in execution unit 202 executes check-in for the first user UA based on the application information associated with the user ID of the first user UA.
  • the check-in executing unit 202 executes the check-in of the first user UA based on the application information for the first ticket associated with the user ID "Yamada.Taro".
  • the ticket application information of the second users UB and UC is not referred to in the check-in of the first user UA.
  • the check-in execution unit 202 executes check-in for the second users UB and UC based on the application information associated with the user IDs of the second users UB and UC.
  • the check-in execution unit 202 checks the second users UB and UC based on the application information for the second and third tickets associated with the user IDs "hanako999" and "yoshida111jiro". run in.
  • the ticket application information of the first user UA is not referred to in the check-ins of the second users UB and UC.
  • the check-in method itself is as described in the first and second embodiments.
  • Modified Example 5 even if the first user UA distributes the tickets to the second users UB and UC, the second users UB and UC cause their user terminals 30B and 30C to display the code C140 and enter the stadium by themselves. Since it is possible to check in to the user, it is possible to improve user convenience while simplifying the management of each user's information. For example, even if each of the first user UA and the second users UB and UC visits the stadium separately, each of them can check-in and enter using his or her own first application.
  • the first service is a service that provides electronic payment using the user terminal 30, the user needs to take out the user terminal 30 when trying to execute electronic payment.
  • the user in order to save the trouble of taking out the user terminal 30, it is being considered to execute electronic payment using biometric authentication.
  • the user does not have to take out the user terminal 30 if authentication at the time of electronic payment is completed only by the face authentication of the user.
  • the users of the first service there may be other users whose face resembles that of a certain user.
  • the user may be mistakenly authenticated by another user with a similar face, making it impossible to make an appropriate electronic payment.
  • a malicious third party who does not use the first service may impersonate a similar-looking user and make an electronic payment using the user's credit card or the like.
  • FIG. 20 is a diagram showing an example of the check-in system S of modification 6.
  • FIG. 20 similarly to the second embodiment, when the user checks in to the stadium, electronic payment using biometric authentication becomes possible with the payment terminal 50 placed in the stadium. Therefore, the user does not need to display code C130.
  • the payment terminal 50 is an example of an authentication device. Therefore, the part described as the payment terminal 50 can be read as the authentication device.
  • the authentication device may be any device capable of biometric authentication. In Modified Example 6, a case where face authentication corresponds to biometric authentication will be described, but any biometric authentication can be used for biometric authentication itself. For example, other biometric authentication such as fingerprint authentication, vein authentication, or voiceprint authentication may be used.
  • authentication information used for biometric authentication is stored in association with user IDs.
  • This authentication information is correct information in biometric authentication, and may be, for example, a facial feature amount, facial photograph, fingerprint pattern, vein pattern, or voiceprint pattern.
  • the user uploads to the first server 10 the information (facial photo, etc.) necessary for registering the authentication information when setting up the use of the first service.
  • the first server 10 stores the authentication information in association with the user ID of this user based on the uploaded information.
  • the check-in system S of Modification 6 includes a permitting unit 104 .
  • the permission unit 104 permits electronic payment to be performed by biometric authentication without using the user terminal 30 in the stadium when check-in is performed.
  • the first server 10 acquires the user ID of the user who has checked in from the second server 20 .
  • the first server 10 may store the user ID transmitted to the second server 20 at the time of check-in in the data storage unit 100 instead of acquiring this user ID from the second server 20 .
  • the permitting unit 104 associates the user ID of the user who has checked into the stadium with information indicating that electronic payment by biometric authentication has been permitted. These associations may be held in the first database DB1 or may be held in another database.
  • the first service providing unit 103 executes electronic payment for a user who is permitted to make an electronic payment by biometric authentication, if the user's biometric authentication is successful.
  • the first service providing unit 103 does not execute electronic payment by biometric authentication for users for whom electronic payment by biometric authentication is not permitted. Even if the first service providing unit 103 is a user for whom electronic payment by biometric authentication is not permitted, and even if a request for electronic payment by biometric authentication is received from a computer other than the stadium, the electronic payment by biometric authentication is accepted. do not run Even if another user whose face resembles that of the user who has checked in to the stadium is registered in the first database DB1, the other user has not checked in, so the information of the other user cannot be obtained at the time of biometric authentication determination. is not determined. Therefore, payment information such as credit card information of the other user is not used.
  • the user when the user purchases a drink from a seat in the stadium, the user has the camera of the payment terminal 50 carried by the seller photograph his/her face.
  • the payment terminal 50 transmits the captured image to the first server 10 together with its own terminal ID.
  • the first service providing unit 103 calculates facial feature amounts from the captured image.
  • the first service providing unit 103 acquires the authentication information of the user who is checking in to the stadium from among the authentication information stored in the first database DB1.
  • the first service providing unit 103 executes biometric authentication based on the calculated facial feature amount and the acquired authentication information.
  • a known method can be used for the biometric authentication itself, and success or failure may be determined based on the degree of similarity of facial features.
  • a known method can be used for biometric authentication itself.
  • the authentication information to be judged at the time of authentication should be limited to that of the user who is checking in.
  • the first service providing unit 103 executes electronic payment when biometric authentication is successful.
  • the first service providing unit 103 refers to the first database DB1 and acquires payment information such as credit card information associated with authentication information similar to the calculated facial feature amount.
  • the first service providing unit 103 executes electronic payment based on this payment information. As shown in FIG. 20, when the user purchases goods at a shop in the stadium, and when the user eats at a restaurant in the stadium, electronic payment is permitted only by facial recognition.
  • the permitting unit 104 prohibits electronic payment by biometric authentication when the user has checked out, when a predetermined time has passed since check-in, or when a predetermined time has passed after check-in.
  • the permission unit 104 changes the first database DB1 so that biometric authentication is not permitted. Update.
  • Modified Example 6 when check-in is executed, electronic payment is permitted to be executed by biometric authentication in the stadium without using the user terminal 30, so user convenience is improved. can be enhanced. In addition, by limiting the range in which electronic payment by biometric authentication is permitted within the stadium, false authentication and impersonation can be prevented, and security can be enhanced.
  • Modified Example 7 describes a case where the first service is an electronic payment service and the second service is a service provided by a karaoke operator.
  • the karaoke box can be used at a membership price.
  • the user uses the user terminal 30 to carry out procedures for membership registration of the karaoke company.
  • the membership registration procedure may be performed from a computer other than the user terminal 30 .
  • the second server 20 associates and manages the user ID and the user's membership information in the second service.
  • the second database DB2 stores information indicating whether or not the user is a member.
  • the check-in terminal 40 is located inside the karaoke box store.
  • a user can check in to a karaoke box as a guest user without becoming a member.
  • the user can use the karaoke box at the membership price.
  • the check-in executing unit 202 executes check-in based on the member information associated with the user ID. For example, if there is member information associated with the user ID in the second database DB2, the check-in execution unit 202 checks in the user so that the user can use the karaoke box at the member price. For example, the process of notifying the store terminal or user terminal 30 that the user is a member corresponds to check-in. Also, for example, setting a member price as a reference for the usage amount of the user corresponds to check-in.
  • user convenience can be enhanced by executing check-in based on the user's member information. For example, even if the user does not carry many membership cards or install many applications in the user terminal 30, the user's membership can be centrally managed by the first application.
  • Modification 8 For example, if the user can use a predetermined service at each of a plurality of positions in the stadium as in the second embodiment, the usage amount used by the user at the stadium may be displayed. Modification 8 describes the case where this service is the first service, but this service may be the second service or any third service different from these.
  • the check-in system S of Modification 8 includes a usage amount acquisition unit 105 and an information provision unit 106 .
  • the usage amount acquisition unit 105 acquires a series of usage amounts in the stadium when check-in is performed.
  • the usage amount acquisition unit 105 acquires each usage amount for which the user has made electronic payment from the first service after check-in is performed.
  • the usage amount acquisition unit 105 acquires usage amounts for purchase of drinks at the seat, purchase of goods at the shop, and payment for meals at the restaurant.
  • Each usage amount is transmitted from the payment terminal 50 to the first server 10 .
  • the first service providing unit 103 stores a history of execution results in the first database DB1 every time electronic payment is executed.
  • the usage amount acquisition unit 105 acquires the usage amount for each electronic payment after check-in by referring to this history.
  • FIG. 21 is a diagram showing an example of a screen displayed on the user terminal 30 of Modification 8.
  • the information providing unit 106 provides the user with information about the stadium based on the usage amount acquired by the usage amount acquiring unit 105 .
  • the information about the stadium may be information according to the usage amount, for example, the individual usage amount itself, the total usage amount, the shortfall until reaching the predetermined amount, recommended information according to the usage amount, or usage This is coupon information according to the amount. It is assumed that the data necessary for presenting this information is stored in the first server 10 or another computer. In the example of FIG.
  • the information providing unit 106 provides, as information about the stadium, history information I150 of individual usage amounts in the stadium, information I151 of the total amount, information I152 of the insufficient amount until the parking lot becomes free, and A provision screen G15 including recommended information I153 is displayed.
  • the recommended information I153 may display products that meet the shortfall until the parking lot becomes free.
  • Modification 8 when check-in is executed, by providing the user with information about the stadium based on a series of usage amounts at the stadium, useful information corresponding to the usage amount of a series of services can provide
  • the check-in system S determines whether to execute electronic settlement for a series of uses in the stadium each time or all at once, depending on the user.
  • a determining unit 107 for determining may be included.
  • Execution of electronic payment each time is as described in the second embodiment.
  • the collective electronic payment may be executed at any timing, for example, when the user checks out, when a predetermined time has passed after check-in, or when a predetermined date and time has arrived.
  • Batch execution means electronic settlement of the total amount of multiple usage amounts generated by multiple usages.
  • the first service providing unit 103 executes electronic payment based on the payment method determined by the determining unit 107. For example, if the determining unit 107 determines to execute each time, the first service providing unit 103 executes electronic payment each time an electronic payment is requested in the same manner as in the second embodiment. Further, for example, when the decision unit 107 collectively decides to execute the first service providing unit 103, the first service providing unit 103 accumulates a plurality of uses in the first database DB1, and when a predetermined timing comes, the total Perform electronic payments in batches.
  • the user may check in to the hotel from the first application for using electronic payment.
  • payment for meals and the like used at the hotel from the time the user checks in to the time he/she checks out may be executed from the electronic payment of the first application.
  • electronic payment may be performed collectively at the time of checkout, or electronic payment may be performed each time the product is used.
  • the check-in terminal 40 may directly transmit information such as the code ID to the second server 20 instead of transmitting information to the second server 20 via the first server 10 .
  • check-in terminal 40 may be read to perform check-in.
  • check-in may be performed by either the user terminal 30 or the check-in terminal 40 alone.
  • the user terminal 30 sends the first server 10 information that can identify this place. and the code ID stored in the user terminal 30 may be transmitted. In this case, the check-in terminal 40 becomes unnecessary.
  • check-in may be executed when the current position detected by the GPS receiver 38 of the user terminal 30 is near a hotel or stadium. In this case, the check-in terminal 40 becomes unnecessary.
  • check-in may be performed by the user reading a physical card or magnetic card with the check-in terminal 40 . In this case, the user terminal 30 becomes unnecessary.
  • the user may check-in by biometric authentication from the check-in terminal 40 . In this case also, the user terminal 30 becomes unnecessary.
  • the location related to the second service may be a location where no application such as reservation occurs.
  • the location may be a facility such as a shopping mall, supermarket, convenience store, day spa facility, game arcade, or department store. Users visit these facilities without making reservations. The user may perform check-in from the check-in terminal 40 arranged at these facilities according to the same procedure as in the first embodiment, the second embodiment, and the modified example.
  • first server 10 and the second server 20 may not be separated, and each function may be realized by one computer.
  • the functions described as being realized by the first server 10 may be shared by a plurality of computers.
  • the functions described as being realized by the second server 20 may be shared by a plurality of computers.
  • Each function may be realized by at least one computer.

Abstract

チェックインシステム(S)の取得手段(201)は、第1サービスのユーザが第2サービスに関する場所を訪れた場合に、ユーザのユーザ端末(30)と、場所のチェックイン端末(40)と、の少なくとも一方を利用して、第1サービスでユーザを識別可能な第1情報を取得する。チェックイン実行手段(202)は、第1情報又は第1情報に関連付けられた第2情報に基づいて、場所へのチェックインを実行する。

Description

チェックインシステム、チェックイン方法、及びプログラム
 本開示は、チェックインシステム、チェックイン方法、及びプログラムに関する。
 従来、ユーザが訪れた場所にユーザをチェックインさせる技術が知られている。例えば、特許文献1には、ユーザ端末にインストールされた飲食店アプリで二次元コードを表示させ、飲食店に配置された端末で二次元コードを読み取ることによって、ユーザを飲食店にチェックインさせるチェックインサービスが記載されている。
特開2020-160689号公報
 しかしながら、特許文献1の技術では、ユーザは、飲食店アプリから利用可能なチェックインサービスに加盟する飲食店にチェックインするだけであり、他のサービスから飲食店にチェックインすることはできない。従来の技術では、ユーザは、サービスごとに情報を管理する必要があるので、チェックインに必要な情報の管理が煩雑であった。
 本開示の目的の1つは、ユーザが訪れた場所へのチェックインに必要な情報の管理を簡易化することである。
 本開示の一態様に係るチェックインシステムは、第1サービスのユーザが第2サービスに関する場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記第1サービスで前記ユーザを識別可能な第1情報を取得する取得手段と、前記第1情報又は前記第1情報に関連付けられた第2情報に基づいて、前記場所へのチェックインを実行するチェックイン実行手段と、を含む。
 本開示によれば、ユーザが訪れた場所へのチェックインに必要な情報の管理を簡易化できる。
第1実施形態のチェックインシステムの全体構成の一例を示す図である。 第1実施形態で第2サービスからホテルを予約する手順の一例を示す図である。 第1実施形態で第1アプリから表示される画面の一例を示す図である。 第1実施形態でユーザがホテルを訪れてチェックインする様子の一例を示す図である。 第1実施形態のチェックインシステムで実現される機能の一例を示す機能ブロック図である。 第1データベースのデータ格納例を示す図である。 第2データベースのデータ格納例を示す図である。 第1実施形態のチェックインシステムで実行される処理の一例を示すフロー図である。 第1実施形態のチェックインシステムで実行される処理の一例を示すフロー図である。 第2実施形態のチェックインシステムの全体構成の一例を示す図である。 第2実施形態で第2サービスからチケットを購入する手順の一例を示す図である。 第2実施形態で第1アプリから表示される画面の一例を示す図である。 第2実施形態でユーザがスタジアムを訪れてチェックインする様子の一例を示す図である。 変形例における機能ブロック図の一例である。 変形例1における第1アプリのホーム画面の一例を示す図である。 変形例2のチェックインシステムの一例を示す図である。 変形例3のチェックインシステムの一例を示す図である。 変形例4のチェックインシステムの一例を示す図である。 変形例5のチェックインシステムの一例を示す図である。 変形例6のチェックインシステムの一例を示す図である。 変形例8のユーザ端末に表示される画面の一例を示す図である。
[1.第1実施形態]
 本開示に係るチェックインシステムの実施形態の一例である第1実施形態を説明する。
[1-1.チェックインシステムの全体構成]
 図1は、第1実施形態のチェックインシステムの全体構成の一例を示す図である。図1に示すように、チェックインシステムSは、第1サーバ10、第2サーバ20、ユーザ端末30、及びチェックイン端末40を含む。第1サーバ10、第2サーバ20、ユーザ端末30、及びチェックイン端末40の各々は、インターネット等のネットワークNに接続可能である。チェックインシステムSは、少なくとも1つのコンピュータを含めばよく、図1の例に限られない。
 第1サーバ10は、第1サービスのサーバコンピュータである。第1実施形態では、第1サービスの一例として、SNS(Social Networking Service)を説明する。第1サービスは、第1実施形態の例に限られず、任意のサービスであってよい。他のサービスの適用例は、後述の第2実施形態及び変形例で説明する。
 第1サーバ10は、制御部11、記憶部12、及び通信部13を含む。制御部11は、少なくとも1つのプロセッサを含む。記憶部12は、RAM等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部13は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
 第2サーバ20は、第2サービスのサーバコンピュータである。第1実施形態では、第2サービスの一例として、旅行予約サービスを説明する。第2サービスは、第1サービスと連携可能なサービスである。第2サービスは、第1サービスとは異なるサービスである。第2サービスは、第1実施形態の例に限られない。他のサービスの適用例は、後述の第2実施形態及び変形例で説明する。第2サーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様である。
 ユーザ端末30は、ユーザが操作するコンピュータである。例えば、ユーザ端末30は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。ユーザ端末30は、制御部31、記憶部32、通信部33、操作部34、表示部35、撮影部36、ICチップ37、及びGPS受信部38を含む。制御部31、記憶部32、及び通信部33の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様である。
 操作部34は、タッチパネル等の入力デバイスである。表示部35は、液晶ディスプレイ又は有機ELディスプレイである。撮影部36は、少なくとも1つのカメラを含む。ICチップ37は、任意の規格のチップであってよく、例えば、FeliCa(登録商標)のチップ、又は、非接触型規格におけるいわゆるTypeA若しくはTypeBのチップである。GPS受信部38は、衛星からの信号を受信する受信機を含む。GPS受信部38は、現在位置又は現在日時の取得に利用される。
 チェックイン端末40は、第2サービスから予約可能な施設に配置されたコンピュータである。例えば、チェックイン端末40は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。チェックイン端末40は、制御部41、記憶部42、通信部43、操作部44、表示部45、及び読取部46を含む。制御部41、記憶部42、通信部43、操作部44、及び表示部45の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部34、及び表示部35と同様である。読取部46は、コードリーダ又はカメラを含む。読取部46は、チェックイン端末40の外部に接続されていてもよい。
 なお、第1サーバ10、第2サーバ20、ユーザ端末30、及びチェックイン端末40の各々に記憶されるプログラム及びデータの少なくとも一方は、ネットワークNを介して供給されてもよい。また、第1サーバ10、第2サーバ20、ユーザ端末30、及びチェックイン端末40の各々に、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)と、外部機器とデータの入出力をするための入出力部(例えば、USBポート)と、の少なくとも一方が含まれてもよい。例えば、情報記憶媒体に記憶されたプログラム及びデータの少なくとも一方が、読取部及び入出力部の少なくとも一方を介して供給されてもよい。
[1-2.第1実施形態のチェックインシステムの概要]
 第1実施形態では、ユーザが、第2サービスから予約したホテルにチェックインする場合を例に挙げる。例えば、第1サービス及び第2サービスで共通のユーザID及びパスワードが利用される。ユーザは、1組のユーザID及びパスワードで、第1サービス及び第2サービスの両方にログインできる。まず、ユーザは、第2サービスにログインしてホテルを予約する。
 図2は、第1実施形態で第2サービスからホテルを予約する手順の一例を示す図である。図2に示すように、ユーザがユーザ端末30から第2サーバ20にアクセスすると、第2サービスのトップページP1が表示される。第1実施形態では、ユーザがブラウザから第2サービスを利用する場合を説明するが、ユーザは、第2サービスのアプリケーションである第2アプリから第2サービスを利用してもよい。第2アプリは、ユーザ端末30にインストール可能である。
 ユーザは、トップページP1から任意の検索条件を入力し、所望のホテルを検索する。ユーザが、所望のホテルを検索して予約に必要な情報を入力すると、第2サービスのログインページP2が表示される。ユーザが、入力フォームF20,F21にユーザID及びパスワードを入力してボタンB22を選択すると、第2サービスにログインしてホテルの予約が完了する。ユーザ端末30には、ホテルの予約が完了したことを示す予約完了ページP3が表示される。
 予約完了ページP3には、ユーザの予約内容と、当日のチェックイン方法と、が案内される。予約完了ページP3に示すように、ユーザは、第1サービスのアプリケーションである第1アプリを利用して、ホテルにチェックインする。第1アプリは、ユーザ端末30にインストールされている。なお、ユーザは、ブラウザから第1サービスを利用してもよい。この場合、ブラウザの画面を利用してチェックインが実行されてもよい。
 図3は、第1実施形態で第1アプリから表示される画面の一例を示す図である。ユーザがユーザ端末30を操作して第1アプリを起動させると、第1サーバ10及びユーザ端末30の間で、第1サービスにログインするための処理が実行される。第1アプリが起動したタイミングで、ユーザID及びパスワードの入力が要求されてもよい。第1実施形態では、過去に第1サービスにログイン済みであり、ユーザID及びパスワードの入力が省略される場合を説明する。
 図3に示すように、ユーザが第1サービスにログインすると、第1アプリのホーム画面G4が表示される。例えば、ユーザは、ホーム画面G4から他のユーザを選択してメッセージを送信したり、ホーム画面G4から他のユーザを友達追加したりすることによって、第1サービスを利用できる。ホーム画面G4は、第1サービス用のコードを表示させるためのボタンB40と、第2サービス用のコードを表示させるためのボタンB41と、を含む。
 ユーザがボタンB40を選択すると、第1サービス用のコードC50を含む表示画面G5が表示される。例えば、コードC50は、第1サービスにおける友達追加で利用される。あるユーザAが表示させたコードC50が、他のユーザBのユーザ端末30で読み取られると、他のユーザBは、ユーザAを友達追加できる。コードC50は、第1サービスにおける他の目的で利用されてもよい。
 コードC50は、第1サービスでユーザを識別可能なIDを含む。このIDは、先述したユーザIDであってもよいが、第1実施形態では、ユーザIDとは異なる情報の場合を説明する。以降、このIDを、コードIDと記載する。コードIDには、有効期限が設定される。第1サーバ10は、あるコードIDの有効期限が経過すると、新たなコードIDを発行し、コードID及び有効期限を更新する。コードID及び有効期限は、ユーザIDと関連付けられて第1サーバ10に保持される。コードIDには、有効期限が設定されなくてもよい。コードC50は、コードID以外の他の情報を含んでもよい。
 ユーザがボタンB41を選択すると、チェックイン用のコードC60を含む表示画面G6が表示部35に表示される。コードC60は、コードIDを含む。コードC60は、コードID以外の他の情報を含んでもよい。また、コードC50が含むコードIDと、コードC60が含むコードIDと、が異なってもよい。即ち、複数のコードIDが発行されてもよい。表示画面G6に示すように、コードC60は、全国のホテルのチェックインで利用できる。コードC60は、ホテル以外の他の施設へのチェックインでも利用できる。ユーザは、宿泊当日にホテルを訪れると、第1アプリを起動させて、表示画面GにコードC60を表示させる。
 図4は、第1実施形態でユーザがホテルを訪れてチェックインする様子の一例を示す図である。図4に示すように、ホテルに配置されたチェックイン端末40には、第1アプリのチェックイン用のコードを読取部46にかざすことを案内する案内画面G7が表示される。ユーザは、チェックイン端末40の読取部46にコードC60をかざす。チェックイン端末40は、読取部46でコードC60を読み取ると、コードC60に含まれるコードIDを、第1サーバ10に送信する。
 第1サーバ10は、コードIDに関連付けられたユーザIDを特定し、このユーザIDを第2サーバ20に送信する。第2サーバ20は、このユーザIDに関連付けられた予約内容を取得し、この予約内容に基づいて、チェックインを実行する。図4に示すように、チェックイン端末40には、ユーザが予約時に入力した氏名や住所等の情報を含む完了画面G8が表示される。チェックイン端末40は、ユーザが予約した部屋のルームキーを排出する。ユーザは、ルームキーを受け取り、この部屋に移動する。
 以上のように、第1実施形態のチェックインシステムSは、第1アプリから表示させたチェックイン用のコードC60を利用して、第2サービスから予約されたホテルへのチェックインを実行する。チェックインに必要な情報が第1アプリで一元管理されるので、チェックインに必要な情報の管理を簡易化できる。以降、この技術の詳細を説明する。
[1-3.第1実施形態のチェックインシステムで実現される機能]
 図5は、第1実施形態のチェックインシステムSで実現される機能の一例を示す機能ブロック図である。
[1-3-1.第1サーバで実現される機能]
 図5に示すように、第1サーバ10では、データ記憶部100、受付部101、発行部102、及び第1サービス提供部103が実現される。データ記憶部100は、記憶部12を主として実現される。受付部101、発行部102、及び第1サービス提供部103の各々は、制御部11を主として実現される。
[データ記憶部]
 データ記憶部100は、ユーザに第1サービスを提供するために必要なデータと、ユーザのチェックインに必要なデータと、を記憶する。例えば、データ記憶部100は、第1データベースDB1を記憶する。
 図6は、第1データベースDB1のデータ格納例を示す図である。図6に示すように、第1データベースDB1は、第1サービスの利用設定をしたユーザに関する情報が格納されたデータベースである。例えば、第1データベースDB1には、ユーザID、パスワード、コードID、有効期限、氏名、及び第1サービスの利用状況が格納される。
 ユーザIDは、第2情報の一例である。このため、ユーザIDと記載した箇所は、第2情報と読み替えることができる。第2情報は、ユーザIDに限られず、少なくとも第2サービスでユーザを識別可能な情報であればよい。例えば、第2情報は、IDと呼ばれる情報ではなく、ユーザアカウント等の他の名前で呼ばれる情報であってもよいし、メールアドレスが第2情報をとして利用されてもよい。他にも例えば、第2情報は、第1サービスと共通のユーザIDではなく、第2サービスで独自に発行されたユーザIDであってもよい。
 コードIDは、第1情報の一例である。このため、コードIDと記載した箇所は、第1情報と読み替えることができる。第1情報は、コードIDに限られず、少なくとも第1サービスでユーザを識別可能な情報であればよい。例えば、第1情報は、IDと呼ばれる情報ではなく、ユーザアカウント等の他の名前で呼ばれる情報であってもよいし、メールアドレスが第1情報をとして利用されてもよい。
 例えば、ユーザIDが第1情報に相当してもよい。ユーザIDが第1情報に相当する場合には、後述の第2情報が存在せず、第2情報がチェックインで利用されなくてもよい。他にも例えば、第1情報は、第2サービスと共通のユーザIDではなく、第1サービスで独自に発行されたユーザIDであってもよい。この場合には、第2サービス側でユーザを特定する必要があるので、第2情報が存在し、第2情報がチェックインで利用されてもよい。第1情報と第2情報の関連付けは、第1データベースDB1ではなく、第2データベースDB2で管理されてもよい。
 第1実施形態では、ユーザの会員登録の手続きは、第1サービス及び第2サービスで共通している。ユーザが会員登録をすると、第1サービス及び第2サービスの両方でユーザを識別可能な情報であるユーザIDが発行される。例えば、ユーザIDに関連付けられるユーザの登録情報は、第1データベースDB1及び第2データベースDB2とは異なる管理用のデータベースに格納される。登録情報は、パスワード、氏名、住所、及び電話番号等である。登録情報には、その他の個人情報が含まれてもよい。
 ユーザは、会員登録の手続きを完了した後に、第1サービスの利用設定の手続きをする。この利用設定の手続きが完了すると、ユーザに対応するレコードが第1データベースDB1に作成される。このレコードには、管理用のデータベースに格納されたユーザID、パスワード、及び氏名が格納される。
 第1実施形態では、第1データベースDB1によって、第1サーバ10は、コードIDと、ユーザIDと、を関連付けて管理する。コードID及びユーザIDは、外部のデータベースに格納されてもよい。即ち、第1サーバ10は、外部のデータベースを利用して、コードID及びユーザIDの関連付けを管理してもよい。第1サーバ10は、後述のコードID取得部401により取得されたコードIDに関連付けられたユーザIDを、第2サーバ20に送信する。
 第1サービスの利用状況には、第1サービスに応じた内容が格納されるようにすればよい。第1実施形態では、SNSサービスが第1サービスに相当するので、第1サービスの利用状況には、ユーザが属するグループ、ユーザの友達、及びユーザのトーク内容が含まれる。第1サービス情報は、ユーザが第1サービスを利用すると更新される。なお、第1データベースDB1に格納される情報は、図6の例に限られず、任意の情報が格納されてよい。例えば、ユーザID及びパスワードの入力を省略して第1サービスにログインするための情報が格納されてもよい。
[受付部]
 受付部101は、ユーザ端末30からコードIDの発行要求を受け付ける。発行要求は、所定形式のデータが送信されることによって行われる。発行要求は、任意のタイミングで送信可能であり、例えば、第1アプリが起動したタイミング、ユーザが第1サービスにログインするタイミング、コードIDの有効期限が経過したタイミング、又はユーザによりコードIDの発行が指示されたタイミングに送信される。
[発行部]
 発行部102は、発行要求が受け付けられた場合に、コードIDを発行してユーザ端末30に送信する。発行部102は、所定のID発行ルールに基づいて、他のコードIDと重複しないように、コードIDを発行する。発行部102は、乱数に基づいて、コードIDをランダムに発行してもよい。発行部102は、現在日時の所定時間だけ後の時間を、コードIDの有効期限として決定する。発行部102は、コードID及び有効期限を、発行要求をしたユーザのユーザIDに関連付けて第1データベースDB1に格納する。第1実施形態では、発行部102がユーザ端末30に有効期限も送信する場合を説明するが、有効期限は、ユーザ端末30に送信されなくてもよい。
[第1サービス提供部]
 第1サービス提供部103は、ユーザに第1サービスを提供する。第1サービス提供部103は、第1サービスの内容に応じた処理を実行すればよい。第1実施形態では、SNSサービスが第1サービスに相当するので、例えば、第1サービス提供部103は、ユーザが入力したメッセージが他のユーザに送信されるように、第1データベースDB1の第1サービス情報を更新する。また例えば、第1サービス提供部103は、あるユーザがコードC50を利用して友達追加をした場合に、このユーザの友達が追加されるように、第1データベースDB1の第1サービス情報を更新する。
[3-2.第2サーバで実現される機能]
 図5に示すように、第2サーバ20では、データ記憶部200、第2サービス提供部201、及びチェックイン実行部202が実現される。データ記憶部200は、記憶部22を主として実現される。第2サービス提供部201及びチェックイン実行部202の各々は、制御部21を主として実現される。
[データ記憶部]
 データ記憶部200は、ユーザに第2サービスを提供するために必要なデータと、ユーザのチェックインに必要なデータと、を記憶する。例えば、データ記憶部200は、第2データベースDB2を記憶する。
 図7は、第2データベースDB2のデータ格納例を示す図である。図7に示すように、第2データベースDB2は、第2サービスの利用設定をしたユーザに関する情報が格納されたデータベースである。例えば、第2データベースDB2には、ユーザID、パスワード、氏名、申込情報、及びチェックイン情報が格納される。
 ユーザは、会員登録の手続きを完了した後に、第2サービスの利用設定の手続きをする。この利用設定の手続きが完了すると、ユーザに対応するレコードが第2データベースDB2に作成される。このレコードには、管理用のデータベースに格納されたユーザID、パスワード、及び氏名が格納される。
 申込情報は、第2サービスに関する申し込みの内容に関する情報である。第1実施形態では、ホテルの予約が第2サービスに関する申し込みに相当する。このため、ホテルの予約について説明している箇所は、第2サービスに関する申し込みと読み替えることができる。第2サービスに関する申し込みは、第2サービスから行われる申し込み、又は、第2サービスを利用するための申し込みである。
 第1実施形態のように、旅行予約サービスが第2サービスに相当する場合には、ホテルの予約は、第2サービスから行われる申し込みである。第2サービスに関する申し込みは、ホテルの予約に限られず、第2サービスに応じた申し込みであればよい。例えば、観光施設、公共施設、遊戯施設、レストラン、又は美容院といった他の施設の予約が申し込みに相当してもよい。また例えば、飛行機、列車、又はレンタカー等の予約が申し込みに相当してもよい。他にも例えば、後述の第2実施形態におけるチケットの購入も申し込みに相当する。
 申込情報は、第2サービスに応じた内容を含めばよい。第1実施形態では、ホテルの予約が申し込みに相当するので、申込情報は、ホテルの予約内容を示す。例えば、申込情報は、ホテルを識別可能な情報(ホテル名・ホテルID等)、チェックイン日、チェックアウト日、宿泊者の氏名、住所、及び電話番号を含む。チェックイン情報は、チェックインの状況に関する情報である。例えば、チェックイン情報は、チェックインの有無と、チェックインが実行された日時と、を含む。
 第1実施形態では、第2データベースDB2によって、第2サーバ20は、ユーザIDと、申込情報と、を関連付けて管理する。ユーザID及び申込情報は、外部のデータベースに格納されてもよい。即ち、第2サーバ20は、外部のデータベースを利用して、ユーザID及び申込情報の関連付けを管理してもよい。なお、コードIDが第2サーバ20に共有されて、申込情報がコードIDと関連付けられてもよい。この場合、ユーザIDを介することなく、コードIDから申込情報が検索可能になる。
 例えば、ユーザが、複数のホテルの各々の予約を行った場合、第2サーバ29は、ユーザIDと、複数のホテルの各々の申込情報と、を関連付けて管理する。即ち、予約ごとに、申込情報が管理される。なお、第2データベースDB2に格納される情報は、図7の例に限られず、任意の情報が格納されてよい。例えば、コードIDが格納されてもよい。また、データ記憶部200は、トップページP1等のデータやホテルの基本情報及び空室情報を記憶してもよい。
[第2サービス提供部]
 第2サービス提供部201は、ユーザに第2サービスを提供する。第2サービス提供部201は、第2サービスの内容に応じた処理を実行すればよい。第1実施形態では、旅行予約サービスが第2サービスに相当するので、例えば、第2サービス提供部201は、ホテルの予約を受け付けるためのページ(トップページP1等)を、ユーザに提供する。また例えば、第2サービス提供部201は、ユーザが入力した検索条件に基づいて、ホテルを検索する。また例えば、第2サービス提供部201は、あるユーザがホテルを予約した場合に、申込情報を生成し、このユーザに関連付けて第2データベースDB2に格納する。
[チェックイン実行部]
 チェックイン実行部202は、コードID又はコードIDに関連付けられたユーザIDに基づいて、ホテルへのチェックインを実行する。第1実施形態では、第2サーバ20は、自身でコードIDを管理しないので、チェックイン実行部202は、コードIDに関連付けられたユーザIDに基づいて、ホテルへのチェックインを実行する。第2サーバ20が自身でコードIDを管理する場合には、チェックイン実行部202は、コードIDに基づいて、ホテルへのチェックインを実行する。この場合、ユーザIDはチェックインで利用されない。
 チェックインを実行するとは、ユーザがホテルを訪れたことを検知することである。ホテルを訪れたユーザを特定すること、又は、ユーザが訪れたホテルを特定することは、チェックインを実行することに相当する。例えば、第2データベースDB2のチェックイン情報を更新することは、チェックインを実行することに相当する。また例えば、ユーザが訪れたホテルのチェックイン端末40又はこのホテルの他の端末に、ユーザの申込情報の全部又は一部を送信することは、チェックインを実行することに相当する。
 第1実施形態では、ユーザは、ホテルを訪れる前に、第2サービスを利用してホテルの予約を行っているので、チェックイン実行部202は、ユーザIDに関連付けられた申込情報に基づいて、チェックインを実行する。チェックインの対象となるユーザのユーザIDは、第2サーバ20自身で特定してもよいが、第1実施形態では、チェックイン実行部202は、第1サーバ10から受信したユーザIDに関連付けられた申込情報に基づいて、チェックインを実行する。
 例えば、チェックイン実行部202は、第1サーバ10から受信したユーザIDに関連付けられた申込情報が第2データベースDB2に存在する場合には、このユーザIDに関連付けられたチェックイン情報を更新する。チェックイン実行部202は、ユーザがチェックイン済みであることを示し、かつ、チェックイン日時として現在日時を含むように、このチェックイン情報を更新する。また例えば、チェックイン実行部202は、このユーザIDに関連付けられた申込情報の全部又は一部を、ユーザが訪れたホテルのチェックイン端末40又はこのホテルの他の端末に送信する。
 ユーザが複数のホテルを予約した場合には、複数の申込情報が存在するので、チェックイン実行部202は、複数のホテルの各々の申込情報のうち、ユーザが訪れたホテルの申込情報に基づいて、チェックインを実行する。ユーザが訪れたホテルは、チェックイン端末40の端末IDによって識別可能である。第1サーバ10は、チェックイン端末40からコードIDとともに端末IDを受信する。第1サーバ10は、このコードIDに関連付けられたユーザIDとともに、この端末IDを第2サーバ20に送信する。
 第2サーバ20は、第1サーバ10から端末ID及びユーザIDを受信する。チェックイン実行部202は、端末IDに基づいて、ユーザが訪れたホテルを特定する。チェックイン実行部202は、複数の申込情報のうち、当該特定されたホテルの申込情報に基づいて、このホテルへのチェックインを実行する。なお、端末IDとホテルの関係は、データ記憶部200に予め記憶されているものとする。即ち、どの端末IDのチェックイン端末40がどのホテルに配置されているかは、データ記憶部200に予め記憶されている。これらの関係をデータ記憶部200に記憶せずに、チェックイン端末40に、自身が配置されたホテルを識別可能な情報を送信させてもよい。
[1-3-3.ユーザ端末で実現される機能]
 図5に示すように、ユーザ端末30では、データ記憶部300と、表示制御部301と、が実現される。データ記憶部300は、記憶部32を主として実現される。表示制御部301は、制御部31を主として実現される。
[データ記憶部]
 データ記憶部300は、ユーザが第1サービス及び第2サービスの各々を利用するために必要なデータと、チェックインに必要なデータと、を記憶する。例えば、データ記憶部300は、第1アプリ及びコードIDを記憶する。ユーザ端末30は、発行部102により発行されたコードIDを受信して自身のデータ記憶部300に記録する。ユーザ端末30は、コードIDの有効期限も受信した場合には、有効期限も自身のデータ記憶部300に記録する。
[表示制御部]
 表示制御部301は、図2及び図3の各画面を表示部35に表示させる。例えば、表示制御部301は、第1サービスを利用するための第1アプリに基づいて、コードIDを含むコードを表示可能である。第1実施形態では、表示制御部301は、第1サービス用のコードC50と、第2サービス用のコードC60と、の各々を表示可能である。第1実施形態では、コードC50もコードIDを含む場合を説明するが、コードC50は、コードIDを含まずに、ユーザを識別可能な他の情報を含んでもよい。
 コードC50は第1コードの一例であり、コードC60は第2コードの一例である。このため、コードC50と記載した箇所は、第1コードと読み替えることができ、コードC60と記載した箇所は、第2コードと読み替えることができる。第1コード及び第2コードの各々は、任意のコードであってよく、第1実施形態の例に限られない。第1コード及び第2コードの各々は、二次元コードではなく、バーコードであってもよいし、時間経過に応じて見た目が変わるコードであってもよい。表示制御部301は、データ記憶部300に記憶されたコードIDをコード化し、コードC50,C60の各々を表示させる。
[1-3-4.チェックイン端末で実現される機能]
 図5に示すように、チェックイン端末40では、データ記憶部400と、コードID取得部401と、が実現される。データ記憶部400は、記憶部42を主として実現される。コードID取得部401は、制御部41を主として実現される。
[データ記憶部]
 データ記憶部400は、チェックインに必要なデータを記憶する。例えば、データ記憶部400は、チェックイン端末40を識別可能な端末IDと、第1サーバ10を識別可能な情報と、を記憶する。他にも例えば、データ記憶部400は、チェックイン端末40が配置されたホテルを識別可能な情報を記憶してもよい。
[コードID取得部]
 コードID取得部401は、第1サービスのユーザがホテルを訪れた場合に、ユーザのユーザ端末30と、ホテルのチェックイン端末40と、の少なくとも一方を利用して、第1サービスでユーザを識別可能なユーザのコードIDを取得する。第1実施形態では、ユーザ端末30及びチェックイン端末40の両方が利用される場合を説明するが、後述の変形例のように、ユーザ端末30又はチェックイン端末40の何れか一方だけが利用されてもよい。
 第1実施形態では、ユーザ端末30のデータ記憶部300にコードIDが記録されているので、コードID取得部401は、ユーザ端末30に記録されたコードIDを取得する。例えば、第1実施形態では、コードID取得部401は、コードC60がチェックイン端末40で読み取られた場合に、コードIDを取得する。チェックイン端末40は、コードIDを取得するための端末であればよく、コードIDの取得方法に応じた端末であればよい。
 コードIDは、光学的に取得されなくてもよく、通信によって取得されてもよい。この場合、ユーザ端末30と通信可能な通信機器がチェックイン端末に相当してもよい。通信自体は、任意のプロトコルを利用可能であり、例えば、Wi-Fi(登録商標)、Bluetooth(登録商標)、又は赤外線通信であってもよいし、公知のICカードで採用されている近距離無線通信であってもよい。
 ホテルは、第2サービスに関する場所の一例である。このため、ホテルと記載した箇所は、第2サービスに関する場所と読み替えることができる。第2サービスに関する場所は、第2サービスを利用して申し込まれる場所、又は、第2サービスが提供される場所である。例えば、第2サービスに関する場所は、観光施設、公共施設、空港、駅、店舗、レストラン、又は美容院といった他の施設であってもよいし、屋外のスペースやバス停のように、特段の施設が存在しない場所が、第2サービスに関する場所であってもよい。
[1-4.第1実施形態のチェックインシステムで実行される処理]
 図8及び図9は、第1実施形態のチェックインシステムSで実行される処理の一例を示すフロー図である。図8及び図9に示す処理は、制御部11,21,31,41の各々が記憶部12,22,32,42の各々に記憶されたプログラムに従って動作することによって実行される。図8及び図9の処理は、図5の機能ブロックにより実行される処理の一例である。
 図8に示すように、第2サーバ20及びユーザ端末30の間で、ホテルの予約処理が実行される(S1)。S1では、図2を参照して説明した流れによって、ホテルが予約される。第2サーバ20は、ユーザ端末30から受信した情報に基づいて申込情報を生成し、ホテルを予約したユーザのユーザIDに関連付けて第2データベースDB2に格納する。
 ユーザ端末30は、ユーザが操作部34から第1アプリを選択すると、記憶部32に記憶された第1アプリを起動させ(S2)、第1サーバ10との間で、ログイン処理を実行する(S3)。S3では、ユーザ端末30は、第1サーバ10に、ログイン処理の実行要求を送信する。この実行要求は、ログインに必要な情報を含み、第1実施形態ではコードIDの発行要求に相当する。第1サーバ10は、ユーザ端末30から受信した情報と、第1データベースDB1と、に基づいて、ログイン処理を実行する。
 第1サーバ10は、ログインが成功した場合、コードIDを発行してユーザ端末30に送信する(S4)。S4では、第1サーバ10は、発行したコードIDに有効期限を設定し、ログインが成功したユーザIDに関連付けて第1データベースDB1に格納する。ユーザ端末30は、コードIDを受信すると、記憶部32のうちの第1アプリの記憶領域にコードIDを記録する(S5)。この記憶領域には、コードIDの有効期限も記録される。
 ユーザ端末30は、第1アプリのホーム画面G4を表示部35に表示させる(S6)。以降、ユーザの操作に応じた処理が実行される。ここでは、ボタンB41を選択する操作が行われた場合を説明する。なお、コードIDの有効期限が経過した場合には、コードC50が表示されずに、S4及びS5の処理と同様にして、新たなコードIDが発行される。
 ユーザ端末30は、ユーザがボタンB41を選択すると、第1アプリの記憶領域に記録されたコードIDに基づいて、チェックイン用のコードC60を表示画面G6に表示させる(S7)。ユーザは、予約したホテルを訪れた場合に、S7で表示させたコードC60をチェックイン端末40にかざす。チェックイン端末40は、読取部46によるコードC60の読取結果に基づいて、コードC60に含まれるコードIDを取得する(S8)。
 図9に移り、チェックイン端末40は、第1サーバ10に端末ID及びコードIDを送信する(S9)。第1サーバ10は、端末ID及びコードIDを受信すると、第1データベースDB1に基づいて、当該コードIDに関連付けられたユーザIDを取得する(S10)。第1サーバ10は、第2サーバ20に、チェックイン端末40から受信した端末IDと、S10で取得したユーザIDと、を送信する(S11)。
 第2サーバ20は、端末ID及びユーザIDを受信すると、第2データベースDB2に基づいて、このユーザIDに関連付けられた、この端末IDに対応するホテルの申込情報を取得する(S12)。このユーザIDに関連付けられた申込情報が第2データベースDB2に存在しない場合には、本処理は終了し、チェックインは実行されない。申込情報が存在したとしても、この端末IDに対応するホテルではない場合には、本処理は終了し、チェックインは実行されない。
 第2サーバ20は、S12で取得した申込情報に基づいて、ホテルへのチェックインを実行する(S13)。S13では、第2サーバ20は、第1サーバ10から受信したユーザIDに関連付けられたチェックイン情報を更新する。また、第2サーバ20は、第1サーバ10から受信した端末IDが示すチェックイン端末40に、S12で取得した申込情報の全部又は一部を送信する。チェックイン端末40は、申込情報の全部又は一部を受信すると、申込情報に基づいて、完了画面G8を表示部46に表示させ(S14)、本処理は終了する。
 第1実施形態のチェックインシステムSによれば、第1サービスのユーザが第2サービスを利用して予約したホテルを訪れた場合に、第1サービスのコードIDを利用して、ホテルへのチェックイン実行することによって、チェックインに必要な情報を第1アプリとは別に管理する必要がなくなるので、チェックインに必要な情報の管理を簡易化できる。例えば、ユーザが予約したホテルのチェックイン用のコードを電子メールで送信し、ユーザが宿泊当日にこのコードをユーザ端末30に表示させてチェックインすることも考えられるが、ユーザは、多数の電子メールからコードを探し出す必要があり、情報の管理が煩雑になる。この点、ユーザが普段使用する第1アプリからチェックインできるようにすることで、管理すべき情報の数を減らせる。
 また、チェックインシステムSは、第1アプリから表示されたコードC60がチェックイン端末40で読み取られた場合に、コードIDを取得することによって、コードC60の読み取りといった簡易な操作でチェックインを実行できる。また、コードC60は第1アプリから表示でき、ホテルにチェックインするためのコードを第1アプリとは別に管理する必要がなくなるので、チェックインに必要な情報の管理を簡易化できる。
 また、チェックインシステムSは、チェックイン用のコードC60がチェックイン端末40で読み取られた場合に、コードIDを取得することによって、第1サービス用のコードC50と、チェックイン用のコードC60と、を使い分けることができる。ユーザは第1アプリさえ操作すれば、第1サービスの利用と、ホテルへのチェックインの実行と、の両方を行うことができるので、ユーザの情報の管理を簡易化できる。
 また、チェックインシステムSは、ユーザ端末30からの発行要求が受け付けられた場合に、コードIDを発行してユーザ端末30に送信し、ユーザ端末30に記録されたコードIDを取得することによって、同じコードIDが長期間使いまわされることを防止できる。このため、悪意のある第三者によるなりすましを防止し、チェックイン時のセキュリティが高まる。例えば、悪意のある第三者がコードC60のスクリーンショットを何らかの形で入手したとしても、コードIDが変更されればそのスクリーンショットではチェックインできなくなるので、セキュリティが高まる。また例えば、コードIDをランダムに生成することによって、第三者がコードIDの予測をできなくなり、よりセキュリティが高まる。また例えば、コードIDを更新する間隔を短くすることで、よりセキュリティが高まる。
 また、チェックインシステムSは、ユーザが予約したホテルの申込情報に基づいてチェックインを実行することによって、チェックイン時のユーザの手間を省くことができる。例えば、ユーザが宿泊当日にホテルのフロントで記帳する必要がなくなる。
 また、チェックインシステムSは、ユーザIDではなくコードIDをコードC50,C60に含めることによって、ユーザIDが漏洩するリスクを低減し、セキュリティが高まる。例えば、コードC50,C60にユーザIDを含めることもできるが、悪意のある第三者にユーザIDが漏洩し、不正ログインが行われる可能性がある。この点、コードC50,C60にはユーザIDが含まれていないので、第三者へのユーザIDの漏洩及び不正ログインを防止できる。仮にコードIDが漏洩したとしても、他のコードIDに更新すれば済むだけであり、何らかの情報が第三者に漏洩したとしても、ユーザIDを変更する必要がなくなる。
 また、チェックインシステムSは、ユーザが複数のホテルの各々の予約を行ったとしても、ユーザが訪れたホテルの申込情報に基づいて、チェックインを実行することによって、適切なホテルへのチェックインを実行できる。また、複数のホテルのチェックインで利用するコードC60を共通化することによって、チェックインに必要な情報をホテルごとに管理する必要がなくなり、情報の管理をより簡易化できる。
[2.第2実施形態]
 第1サービス及び第2サービスは、任意のサービスの組み合わせであってよく、第1実施形態の例に限られない。第2実施形態では、第1サービスが電子決済サービスであり、第2サービスがチケット販売サービスである場合を説明する。なお、第2実施形態では、第1実施形態と同様の内容は、説明を省略する。
 第2実施形態の第1サービスは、電子決済を提供するサービスである。例えば、第1サービスは、ユーザ端末30を利用した電子決済を提供するサービスである。第2実施形態では、第1アプリを利用して電子決済が実行される場合を説明する。第1アプリから利用可能な決済手段は、任意の種類であってよく、例えば、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、銀行口座、ウォレット、仮想通貨、又はこれらの組み合わせであってもよい。
 なお、第1サービスは、ユーザ端末30のICチップ37を利用した電子決済を提供してもよい。第1サービスは、ユーザ端末30を利用せずに、ICカード又は磁気カード等の物理的なカードを利用した電子決済を提供してもよい。第1サービスは、ユーザの所有物ではなく、ユーザ自身を利用して(即ち、生体認証を利用して)電子決済を提供してもよい。これらの電子決済でも、任意の決済手段を利用可能である。
 第2実施形態の第2サービスは、ユーザが訪れる場所に関するチケットの購入申し込みを受け付けるサービスである。この場所は、第2サービスに関する場所である。スポーツの試合、コンサート、演劇、その他のイベント、映画館、又は美術館等のチケットを販売するサービスである。第2サービスで販売されるチケット自体は、公知のプレイガイドで取り扱われているチケットであればよい。
 第2実施形態では、ユーザが第2サービスを利用して野球の試合のチケットを購入する場合を例に挙げる。このため、試合が開催されるスタジアムは、第2サービスに関する場所の一例である。スタジアムについて説明している箇所は、第2サービスに関する場所と読み替えることができる。この場所は、チケットに記載される場所であればよく、コンサート会場、劇場、その他のイベント会場、映画館、又は美術館等の場所であってよい。
 図10は、第2実施形態のチェックインシステムSの全体構成の一例を示す図である。図10に示すように、チェックインシステムSは、第1実施形態で説明した構成に加えて、決済端末50を含む。第2実施形態では、チェックイン端末40及び決済端末50は、スタジアムに配置される。決済端末50は、スタジアムにおける店舗のコンピュータである。第2実施形態では、この店舗がスタジアムの中に存在する場合を説明するが、店舗は、スタジアム付近であれば、スタジアムの外に存在してもよい。
 例えば、決済端末50は、POS端末、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。決済端末50は、制御部51、記憶部52、通信部53、操作部54、表示部55、及び読取部56を含む。制御部51、記憶部52、通信部53、操作部54、表示部55、及び読取部56の物理的構成は、それぞれ制御部11、記憶部12、通信部13、操作部34、表示部35、及び読取部46と同様である。第2実施形態では、まず、ユーザは、第2サービスにログインして試合のチケットを購入する。
 図11は、第2実施形態で第2サービスからチケットを購入する手順の一例を示す図である。図11に示すように、ユーザがユーザ端末30から第2サーバ20にアクセスすると、第2サービスのトップページP9が表示される。ユーザは、トップページP9から任意の検索条件を入力し、所望のチケットを検索する。ユーザが、所望のチケットの購入申し込みをすると、第2サービスのログインページP10が表示される。
 ユーザが、入力フォームF100,F101にユーザID及びパスワードを入力してボタンB102を選択すると、第2サービスにログインしてチケットの購入が完了する。ユーザは、第1サービスを利用してチケットの代金を支払ってもよいし、第2サービスに登録した他の決済手段を利用してもよい。ユーザ端末30には、チケットの購入が完了したことを示す購入完了ページP11が表示される。購入完了ページP11に示すように、スタジアムへのチェックイン方法自体は、第1実施形態と同様である。ユーザは、第1アプリを利用してスタジアムにチェックインする。
 図12は、第2実施形態で第1アプリから表示される画面の一例を示す図である。ユーザがユーザ端末30を操作して第1アプリを起動させると、第1実施形態と同様にしてコードIDが発行され、第1アプリのホーム画面G12が表示される。ホーム画面G12には、電子決済用のコードC120が表される。コードC120は、コードIDを含む。コードC120は、第1実施形態のコードC50に対応する。コードC120を表示させる方法は、コードC50を表示させる方法と同様である。
 ユーザは、コードC120を利用して電子決済を実行できる。例えば、ユーザは、スタジアムにチェックインした後に、決済端末50にコードC120を読み取らせると、予め設定された決済手段(図12ではクレジットカード)に基づいて、電子決済を実行できる。コードC120は、スタジアム以外の任意の店舗で利用可能である。即ち、コードC120は、第2サービスに関する場所以外の場所でも利用可能である。
 なお、電子決済の実行方法自体は、種々の手法を利用可能である。例えば、決済端末50に表示されたコードをユーザ端末30で読み取る方法、紙等に印刷されて店舗に掲示されたコードをユーザ端末30で読み取る方法、ユーザ端末30のICチップ37を決済端末50のリーダライタにかざす方法、又はユーザ端末30に対する操作だけで完結する方法であってもよい。
 ユーザがホーム画面G12のボタンB121を選択すると、チェックイン用のコードC130を含む表示画面G13が表示部35に表示される。コードC130は、コードIDを含む。コードC130は、第2実施形態のコードC60に対応する。コードC130を表示させる方法は、第1実施形態で説明したコードC60を表示させる方法と同様である。
 図13は、第2実施形態でユーザがスタジアムを訪れてチェックインする様子の一例を示す図である。図13に示すように、ユーザは、スタジアムのエントランスに配置されたチェックイン端末40の読取部46にコードC130をかざすと、第1実施形態と同様にして、第1サーバ10及び第2サーバ20の各々の制御によってチェックインが実行される。チェックインが完了すると、チェックイン端末40には、ユーザが購入したチケットの詳細が表示され、ユーザの入場が許可される。チェックイン端末40は、自身に接続されたプリンタから、ユーザが購入したチケットを発券してもよい。
 チェックインが完了すると、ユーザは、スタジアムのエントランスから入場する。スタジアム内の複数の位置の各々に決済端末50が配置されており、ユーザは、任意の店舗で商品を購入したり、サービスを利用したりすることができる。スタジアム内を移動する売り子が電子決済に対応する場合には、売り子は、可搬型の決済端末50を持ち歩いてもよい。図13の例では、ユーザは、第1アプリを利用した電子決済により、座席でドリンクを購入し、売店でグッズを購入し、レストランで食事の支払いをする。
 試合が終了すると、ユーザは、チェックイン端末40の読取部46にコードC130をかざし、スタジアムからチェックアウトする。チェックアウト時の流れは、チェックイン時の流れと同様である。第2サーバ20は、第1サーバ10を介してチェックアウトしたユーザを特定すると、チェックアウトの処理を実行する。チェックイン端末40には、チェックアウトが完了したことを示す画面が表示される。チェックアウトが完了すると、ユーザは、スタジアムのエントランスから退場する。なお、チェックアウトは省略してもよい。
 第2実施形態のチェックインシステムSの機能ブロック及び処理の流れは、第1実施形態と同様である。第2実施形態では、第2データベースDB2に格納される申込情報は、ユーザにより購入されたチケットに関する情報である。例えば、申込情報は、ユーザがチケットを購入した試合の日時、開始時間、座席、及び価格を含む。チェックインが実行されると、チェックイン端末40には、申込情報に含まれるこれらの情報が表示される。
 なお、第2実施形態では、第1データベースDB1に、電子決済に必要な情報が格納されているものとする。例えば、ユーザIDに関連付けて、クレジットカード情報、電子マネー情報、電子キャッシュ情報、又は銀行口座情報といった決済手段に関する情報が第1データベースDB1に格納されている。また例えば、ユーザIDに関連付けて、複数の決済手段の中でユーザが選択した決済手段を識別する情報が第1データベースDB1に格納されている。
 ユーザがユーザ端末30にコードC120を表示させて決済端末50にかざすと、決済端末50は、コードC120を読み取ってコードIDを取得して、電子決済に必要な情報(決済金額等)とともに第1サーバ10に送信する。第1サーバ10は、決済端末50からコードIDを受信する。第1サービス提供部103は、第1データベースDB1を参照し、このコードIDに関連付けられた情報に基づいて、ユーザが選択した決済手段を特定する。第1サービス提供部103は、当該特定された決済手段に関する情報(クレジットカード情報等)に基づいて、電子決済を実行する。電子決済の実行方法自体は、公知の種々の方法を利用可能である。
 第1サービス提供部103は、チケットの購入に関する電子決済を実行してもよい。即ち、第1サービス提供部103は、ユーザが第2サービスを利用して購入するチケットの代金が第1サービスの電子決済で支払われるようにしてもよい。また、ユーザが、スタジアムで所定のサービス(図13の例では、ドリンク購入、グッズ購入、食事利用の各サービス)を利用可能な場合には、第1サービス提供部103は、チェックインが実行された場合に、スタジアムにおける利用に関する電子決済を実行してもよい。
 なお、チェックイン端末40が電子決済機能を有してもよい。この場合、コードC120は、電子決済を実行するために第1サービスを利用することを識別可能な情報を含む。チェックイン端末40は、コードC120を読み取った場合に、コードIDとともに、この情報を第1サーバ10に送信する。第1サーバ10は、この情報に基づいて、第1サービス提供部103に処理させると決定する。第1サービス提供部103は、上記と同様の流れにより、電子決済を実行すればよい。
 同様に、コードC130は、チェックインを実行することを識別可能な情報を含んでもよい。チェックイン端末40は、コードC130を読み取った場合に、コードIDとともに、この情報を第1サーバ10に送信する。第1サーバ10は、この情報に基づいて、チェックインのための処理を実行すると判定すればよい。第1サーバ10は、上記と同様の流れにより、チェックインのための処理を実行すればよい。
 また、決済端末50がチェックイン機能を有してもよい。この場合も上記と同様にして、第1サーバ10は、コードC120,C130に含まれる情報に基づいて、第1サービス提供部103に処理させるか、チェックインのための処理を実行するか、を判定すればよい。また、コードC120,C130にこの情報を含めるのではなく、後述する変形例1のように、第1サービスを利用するか、スタジアムへのチェックインを実行するか、をユーザに選択させてもよい。
 第2実施形態のチェックインシステムSによれば、ユーザが比較的頻繁に利用する電子決済サービスである第1サービスの第1アプリで、スタジアムへのチェックインのコードC130も管理できるので、チェックインに必要な情報の管理がより簡易化する。また、ユーザが予約したチケットの代金も第1サービスの電子決済で実行することによって、ユーザの利便性も高まる。
 また、チェックインシステムSは、チェックインが実行された場合に、スタジアムにおける利用に関する電子決済を実行することによって、スタジアム内での支払いが簡易化し、ユーザの利便性が高まる。ユーザは、スタジアム内で利用した支払額を管理しやすくなる。
[3.変形例]
 なお、本開示は、以上に説明した実施の形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
 図14は、変形例における機能ブロック図の一例である。以降説明する変形例では、図14に示す各機能が実現される。許可部104、利用額取得部105、情報提供部106、及び決定部107の各々は、制御部11を主として実現される。分配部203は、制御部21を主として実現される。なお、第2実施形態で説明した第1サービス及び第2サービスの組み合わせを例に挙げるが、第1実施形態で説明した組み合わせであってもよい。
[3-1.変形例1]
 図15は、変形例1における第1アプリのホーム画面G14の一例を示す図である。図15に示すように、ユーザ端末30は、第1サービス及び第2サービスで共通のコードC140を表示可能であってもよい。即ち、第1サービス用のコードと、チェックイン用のコードと、は同じであってもよい。この共通のコードは、コードIDを含む。コードIDの発行方法は、第1実施形態及び第2実施形態と同様である。
 例えば、コードC140が第1サービスを利用可能な場所(例えば、スタジアム内の店舗又は売り子)で読み取られると、ユーザは第1サービスを利用できる。変形例1の第1サービス提供部103は、第1サービスの決済端末50で、共通のコードC140が読み取られた場合に、コードIDに基づいて、第1サービスを提供する。
 決済端末50は、第1サービス端末の一例である。このため、決済端末50と記載した箇所は、第1サービス端末と読み替えることができる。第1サービス端末は、第1サービスを提供するためのコンピュータであればよく、スタジアムに配置された決済端末50に限られない。スタジアムとは関係のない場所に配置されたコンピュータが第1サービス端末に相当してもよい。例えば、コンビニエンスストア、スーパーマーケット、その他の店舗、又は自動販売機等が第1サービス端末に相当してもよい。
 変形例1では、第1サーバ10のデータ記憶部100は、第1サービス端末を識別可能な端末IDを記憶する。第1サービス端末は、共通のコードC140を読み取ってコードIDを取得すると、第1サーバ10に、自身の端末ID及びこのコードIDを送信する。第1サービス提供部103は、端末ID及びコードIDを受信すると、この端末IDに基づいて、端末ID及びコードIDを送信したコンピュータが第1サービス端末であるか否かを判定する。
 第1サービス提供部103は、端末ID及びコードIDを送信したコンピュータが第1サービス端末であると判定した場合に、このコードIDに関連付けられたユーザIDのユーザが指定した決済手段に基づいて、電子決済を実行する。電子決済の実行方法自体は、第2実施形態で説明した通り、公知の方法を利用可能である。コードC140がスタジアムの決済端末50で読み取られると、第1サービス提供部103は、上記の流れに基づいて、電子決済を実行する。
 一方、コードC140がスタジアムのチェックイン端末40で読み取られると、電子決済は実行されず、ユーザは第2サービスで予約したチケットでスタジアムに入場できる。変形例1のコードID取得部401は、共通のコードC140がチェックイン端末40で読み取られた場合に、コードIDを取得する。チェックイン端末40は、第1実施形態及び第2実施形態と同様にして、自身の端末ID及びこのコードIDを第1サーバ10に送信する。第1サーバ10は、この端末IDに基づいて、端末ID及びコードIDを送信したコンピュータがチェックイン端末40であることを特定する。以降、第1実施形態及び第2実施形態と同様の流れでチェックインが実行される。
 なお、チェックイン端末40が電子決済機能を有する場合には、ユーザにより、第1サービスを利用するか、スタジアムへのチェックインを実行するか、を選択させてもよい。チェックイン端末40は、ユーザの選択結果を識別可能な情報とともに、自身の端末ID及びコードIDを第1サーバ10に送信する。第1サーバ10は、この情報に基づいて、第1サービス提供部103に処理させるか、チェックインのための処理を実行するか、を判定すればよい。決済端末50がチェックイン機能を有する場合も同様にして、第1サーバ10は、ユーザの選択結果を識別可能な情報に基づいて、第1サービス提供部103に処理させるか、チェックインのための処理を実行するか、を判定すればよい。
 また、図15に示すように、ユーザがボタンB141を選択すると、購入済みのチケットの内容がユーザ端末30に表示されてもよい。この場合、ユーザ端末30は、第1サーバ10を介して第2サーバ20に購入済みのチケットの内容を要求する。第2サーバ20は、第2データベースDB2に格納された申込情報の全部又は一部を、第1サーバ10を介して又は直接的にユーザ端末30に送信する。ユーザは、申込情報を確認しながらコードC140によってチェックインを実行できる。
 変形例1によれば、第1サービス及び第2サービスで共通のコードC140がチェックイン端末40で読み取られた場合に、コードIDを取得することによって、第1サービス及び第2サービスのコードC140を共通化し、情報の管理をより簡易化できる。
[3-2.変形例2]
 図16は、変形例2のチェックインシステムSの一例を示す図である。図16に示すように、変形例2では、ユーザは、複数のスタジアムA~Cの各々のチケットを購入しており、ユーザが複数のスタジアムA~Cの各々を訪問可能である場合を説明する。第2サーバ20の第2データベースDB2には、複数のスタジアムA~Cの各々の申込情報が格納されている。図16では、スタジアムAにはチェックイン端末40Aが配置されており、スタジアムBにはチェックイン端末40Bが配置されており、スタジアムCにはチェックイン端末40Cが配置されている。
 従来の技術では、複数のスタジアムA~Cの各々にチェックインするために、別々のコードが必要なので、コードの管理が煩雑である。そこで、変形例2のユーザ端末30は、複数のスタジアムA~Cで共通のコードC140を表示可能である。ユーザは、コードC140を利用して、スタジアムA~Cの各々にチェックインできる。このコードC140は、変形例1と同様に第1サービス用及びチェックイン用で共通のものとするが、第1実施形態又は第2実施形態のように、チェックイン用のコードC60,C130が利用されてもよい。
 第2サーバ20は、複数のチェックイン端末40A~40Cの各々の端末IDと、スタジアムを識別可能なスタジアムIDと、を関連付けてデータ記憶部200に記憶している。このため、第2サーバ20は、端末IDを取得すれば、どのスタジアムにユーザがチェックインしようとしているかを特定できるようになっている。第2サーバ20の申込情報には、スタジアムIDが含まれている。第2サーバ20は、端末IDに関連付けられたスタジアムIDを取得すれば、どのスタジアムにユーザがチェックインしようとしているかを特定できる。なお、スタジアムIDは、チェックイン端末40A~40Cの各々に記憶されており、チェックイン端末40A~40Cの各々から第1サーバ10に送信されてもよい。
 変形例2では、ユーザがスタジアムAにチェックインする場合を例に挙げる。チェックイン端末40AのコードID取得部401は、共通のコードC140がチェックイン端末40Aで読み取られた場合に、コードIDを取得する。チェックイン端末40Aは、第1サーバ10に、自身の端末ID及びコードIDを送信する。第1サーバ10は、第1データベースDB1を参照し、コードIDに関連付けられたユーザIDを取得する。第1サーバ10は、この端末ID及びこのユーザIDを第2サーバ20に送信する。
 第2サーバ20は、第1サーバ10から端末ID及びコードIDを受信する。チェックイン実行部202は、この端末IDに関連付けられたスタジアムIDを取得し、このコードIDに関連付けられたユーザIDを取得する。チェックイン実行部202は、このユーザIDに関連付けられた申込情報のうち、このスタジアムIDを含む申込情報を取得する。
 ここでは、スタジアムAの申込情報が取得されるので、チェックイン実行部202は、この申込情報に基づいて、スタジアムAへのチェックインを実行する。チェックイン自体は、第2実施形態で説明した通りである。スタジアムAのチェックイン端末40Aには、チェックインが完了したことを示す画面が表示され、ユーザは、スタジアムAのエントランスを通過する。
 なお、ユーザがスタジアムB又はスタジアムCにチェックインする場合も、上記と同様の処理により、スタジアムB又はスタジアムCへのチェックインが実行される。第2サーバ20は、チェックイン端末40B又はチェックイン端末40Cから受信した端末IDに基づいて、ユーザがスタジアムB又はスタジアムCの何れにチェックインしようとしているかを特定すればよい。ユーザがチケットを購入したスタジアムが2つ又は4つ以上の場合も同様である。
 また、ユーザがチェックインしようとしているスタジアムは、第1サーバ10によって特定されてもよい。この場合、第1サーバ10は、端末IDと、スタジアムIDと、の関連付けをデータ記憶部100に記憶しているものとする。第1サーバ10は、チェックイン端末40から受信した端末IDに関連付けられたスタジアムIDを取得し、ユーザIDとともに、第2サーバ20に送信する。第2サーバ20は、第1サーバ10からスタジアムID及びユーザIDを受信し、その後のチェックイン実行部202の処理は、上記と同様にすればよい。
 変形例2によれば、複数のスタジアムで共通のコードC140がチェックイン端末40で読み取られた場合にコードIDを取得することによって、複数のスタジアムでコードC140を共通化し、情報の管理をより簡易化できる。
[3-3.変形例3]
 図17は、変形例3のチェックインシステムSの一例を示す図である。図17に示すように、変形例3では、ユーザは、複数の第2サービスを利用可能であり、複数の第2サービスの各々に関する場所を訪問可能である。変形例3では、複数の第2サービスとして、チケット購入サービス、旅行予約サービス、及びレストラン予約サービスを例に挙げる。チェックインシステムSは、チケット購入サービスの第2サーバ20D、旅行予約サービスの第2サーバ20E、及びレストラン予約サービスの第2サーバ20Fを含む。
 例えば、ユーザは、チケット購入サービスからスタジアムで開催される試合のチケットを購入済みである。第2サーバ20Dは、このチケットの申込情報を記憶する。このスタジアムには、チェックイン端末40Dが配置されている。チケット購入サービスの詳細は、第2実施形態で説明した通りである。
 また例えば、ユーザは、旅行予約サービスからホテルを予約済みである。第2サーバ20Eは、このホテルの申込情報を記憶する。このホテルには、チェックイン端末40Eが配置されている。旅行予約サービスの詳細は、第1実施形態で説明した通りである。
 また例えば、ユーザは、レストラン予約サービスからレストランを予約済みである。第2サーバ20Fは、レストランの申込情報を記憶する。レストランの予約自体は、公知の種々の方法を利用可能であり、この申込情報の形式は、第1実施形態及び第2実施形態と同様であってよい。この申込情報には、レストランを識別可能な情報、予約日時、予約者の氏名、及び人数といった内容が含まれる。このレストランには、チェックイン端末40Fが配置されている。
 従来の技術では、スタジアム、ホテル、及びレストランの各々にチェックインするために、別々のコードが必要なので、コードの管理が煩雑である。そこで、変形例3のユーザ端末30は、複数の第2サービスで共通のコードC140を表示可能である。ユーザは、このコードC140を利用して、スタジアム、ホテル、及びレストランの各々にチェックインできる。このコードC140は、変形例1と同様に第1サービス用及びチェックイン用で共通のものとするが、第1実施形態又は第2実施形態のように、チェックイン用のコードC60,C130が利用されてもよい。
 第1サーバ10は、複数のチェックイン端末40D~40Fの各々の端末IDと、複数の第2サーバ20D~20Eの各々を識別可能な情報と、を関連付けてデータ記憶部100に記憶している。このため、第1サーバ10は、端末IDを取得すれば、どの第2サービスに関する場所にユーザがチェックインしようとしているかを特定できるようになっている。
 変形例3では、ユーザがスタジアムにチェックインする場合を例に挙げる。チェックイン端末40DのコードID取得部401は、共通のコードC140がチェックイン端末40Dで読み取られた場合に、コードIDを取得する。チェックイン端末40Dは、第1サーバ10に、自身の端末ID及びコードIDを送信する。第1サーバ10は、この端末IDに関連付けられた第2サーバ20Dを特定する。第1サーバ10は、第1データベースDB1を参照し、コードIDに関連付けられたユーザIDを取得する。第1サーバ10は、この端末ID及びこのユーザIDを、特定した第2サーバ20Dに送信する。
 第2サーバ20Dは、第1サーバ10から端末ID及びコードIDを受信し、その後のチェックイン実行部202の処理は、第2実施形態と同様にすればよい。ユーザがホテル又はレストランにチェックインする場合も、上記と同様の処理により、ホテル又はレストランへのチェックインが実行される。第1サーバ10は、チェックイン端末40E又はチェックイン端末40Fから受信した端末IDに基づいて、この端末IDに関連付けられた第2サーバ20E又は第2サーバ20Fを特定する。第1サーバ10は、特定した第2サーバ20E又は第2サーバ20Fに、この端末IDと、コードIDに関連付けられたユーザIDと、を送信すればよい。その後のチェックイン実行部202の処理は、上記と同様にすればよい。
 変形例3によれば、複数の第2サービスで共通のコードC140がチェックイン端末40で読み取られた場合にコードIDを取得することによって、複数の第2サービスのコードC140を共通化し、情報の管理をより簡易化できる。
[3-4.変形例4]
 図18は、変形例4のチェックインシステムSの一例を示す図である。図18に示すように、変形例4では、ユーザは、複数の日時の各々でチケットの購入を行い、3/26のチケット、3/27のチケット、及び3/28のチケットを購入済みである。個々のチケットの購入手順は、第2実施形態で説明した通りである。なお、図18では、チェックイン端末40を区別する必要がないので、図16及び図17とは異なり、末尾のアルファベットを省略する。
 第2サーバ20は、ユーザIDと、複数の日時の各々の申込情報と、を関連付けて管理する。即ち、第2データベースDB2のうち、チケットを購入したユーザのレコードには、3/26のチケットの申込情報、3/27のチケットの申込情報、及び3/28のチケットの申込情報が格納されている。
 変形例4では、ユーザが3/26にスタジアムにチェックインする場合を例に挙げる。第2サーバ20に端末ID及びユーザIDが送信されるまでの流れは、第2実施形態と同様である。第2サーバ20は、第1サーバ10から端末ID及びユーザIDを受信すると、リアルタイムクロック等を利用して、現在日時を取得する。チェックイン実行部202は、複数の日時の各々の申込情報のうち、ユーザがスタジアムを訪れた日時(即ち、現在日時)に基づいて、チェックインを実行する。
 チェックイン実行部202は、第1サーバ10から受信したユーザIDに関連付けられた複数の申込情報のうち、現在日時に対応する申込情報を取得する。現在日時に対応する申込情報とは、現在日時及び申込情報の日時が一致する申込情報、現在の日付及び申込情報の日付が一致する申込情報、又は現在日時及び申込情報の日時のずれが閾値未満の申込情報である。チェックイン実行部202は、取得した申込情報に基づいて、チェックインを実行する。図18の例であれば、チェックイン実行部202は、3/26の申込情報に基づいて、3/26のチェックインを実行する。チェックインの実行方法自体は、第2実施形態で説明した通りである。
 なお、ユーザが3/27又は3/28にスタジアムにチェックインする場合も、上記と同様の処理により、3/27の申込情報又は3/28の申込情報に基づいて、3/27又は3/28のチェックインが実行される。また、現在日時は、第1サーバ10又はチェックイン端末40によって取得されて第2サーバ20に送信されてもよい。
 変形例4によれば、ユーザがチケットを購入した複数の日時の各々の申込情報のうち、ユーザがスタジアムを訪れた日時の申込情報に基づいて、チェックインを実行することによって、複数の日時のコードC140を共通化し、情報の管理をより簡易化できる。
[3-5.変形例5]
 例えば、第2実施形態において、ユーザは、第2サービスを利用して、複数のチケットを申し込んでもよい。変形例5では、チケットを申し込んだユーザを第1ユーザUAと記載し、チケットが分配されるユーザを第2ユーザUB,UCと記載する。第1ユーザUAは、第2ユーザUB,UCと一緒に観戦する試合のチケットを3枚分申し込んで購入する。第1ユーザUAは、第2ユーザUB,UCの各々にチケットを分配する。なお、第1ユーザUAと、第2ユーザUB,UCと、の各々は、第1サービス及び第2サービスの両方の利用設定を済ませているものとする。
 図19は、変形例5のチェックインシステムSの一例を示す図である。第2サーバ20は、第1ユーザUAのユーザIDと、複数のチケットの各々の申込情報と、を関連付けて管理する。図19では、第2データベースDB2のうち、ユーザIDと申込情報の部分のみ示す。また、申込情報の内容を「チケット1」のように簡略化して示す。図19に示すように、ユーザAが3枚のチケットを購入した時点では、第1ユーザUAのユーザID「Yamada.Taro」に、3枚のチケットの各々の申込情報が関連付けられている。この状態は、チケットの分配前の状態である。
 変形例5のチェックインシステムSは、分配部203を含む。第1ユーザUAは、自身のユーザ端末20Aから、3枚のチケットのうちの2枚を、第2ユーザUB,UCの各々に分配するための操作を行う。この操作自体は、公知のプレイガイドで利用されている方法であってよい。例えば、第1ユーザUAは、第2サービスにログインすると、購入した3枚のチケットをユーザ端末20Aに表示させる。第1ユーザUAは、第2ユーザUB,UCの各々のユーザIDと、分配するチケットと、を指定する。第2ユーザUB,UCの各々は、ユーザIDではなく、メールアドレス等の他の情報によって識別されてもよい。
 第1ユーザUAが分配のための操作を終えると、分配部203は、複数のチケットのうち、第2ユーザUB,UCのチケットの申込情報を、第2ユーザUB,UCのユーザIDに関連付けることによって、第2ユーザUB,UCにチケットを分配する。図19に示すように、分配部203は、第1ユーザUAのユーザID「Yamada.Taro」に関連付けられていた3つの申込情報のうちの2つを、第2ユーザUB,UCのユーザID「hanako999」及び「yoshida111jiro」に関連付ける。これにより、2枚目及び3枚目のチケットが第2ユーザUB,UCの各々に分配される。第2ユーザUB,UCの各々のユーザ端末20B,20Cには、チケットの分配が完了した旨の通知が電子メール等を利用して送信される。
 コードID取得部401は、第1ユーザUAがスタジアムを訪れた場合に、第1ユーザUAのコードIDを取得し、第2ユーザUB,UCがスタジアムを訪れた場合に、第2ユーザUB,UCのコードIDを取得する。コードIDの取得方法自体は、第1実施形態及び第2実施形態と同様であってよい。第1サーバ10は、第1データベースDB1を参照し、第1ユーザUAのコードIDに関連付けられたユーザIDを取得し、第2ユーザUB,UCのコードIDに関連付けられたユーザIDを取得する。第1サーバ10は、これらのユーザIDを、第2サーバ20に送信する。
 チェックイン実行部202は、第1ユーザUAのユーザIDに関連付けられた申込情報に基づいて、第1ユーザUAのチェックインを実行する。図19の例であれば、チェックイン実行部202は、ユーザID「Yamada.Taro」に関連付けられた1枚目のチケットの申込情報に基づいて、第1ユーザUAのチェックインを実行する。第2ユーザUB,UCのチケットの申込情報は、第1ユーザUAのチェックインでは参照されない。
 チェックイン実行部202は、第2ユーザUB,UCのユーザIDに関連付けられた申込情報に基づいて、第2ユーザUB,UCのチェックインを実行する。図19の例であれば、チェックイン実行部202は、ユーザID「hanako999」及び「yoshida111jiro」に関連付けられた2,3枚目のチケットの申込情報に基づいて、第2ユーザUB,UCのチェックインを実行する。第1ユーザUAのチケットの申込情報は、第2ユーザUB,UCのチェックインでは参照されない。チェックインの方法自体は、第1実施形態及び第2実施形態で説明した通りである。
 変形例5によれば、第1ユーザUAが第2ユーザUB,UCにチケットを分配したとしても、第2ユーザUB,UCは自身のユーザ端末30B,30CにコードC140を表示させて各自でスタジアムにチェックインできるので、各ユーザの情報の管理を簡易化しつつ、ユーザの利便性を高めることができる。例えば、第1ユーザUAと、第2ユーザUB,UCと、の各々が別々にスタジアムを訪れたとしても、各自が自分の第1アプリからチェックインをして入場できる。
[3-6.変形例6]
 例えば、第1サービスが、ユーザ端末30を利用した電子決済を提供するサービスである場合、ユーザは、電子決済を実行しようとすると、ユーザ端末30を取り出す必要がある。この点、ユーザ端末30を取り出す手間を省くために、生体認証を利用して電子決済を実行することが検討されている。例えば、ユーザの顔認証だけで電子決済時の認証が完了するのであれば、ユーザは、ユーザ端末30を取り出さなくて済む。
 しかしながら、第1サービスのユーザの中には、あるユーザと顔が似た他のユーザが存在することがある。この場合、あるユーザが顔認証で電子決済を実行しようとすると、顔が似た他のユーザに誤認証されてしまい、適切な電子決済が実行できないことがある。第1サービスを利用していない悪意のある第三者が、顔が似たユーザに成りすまして、このユーザのクレジットカード等を利用して電子決済する可能性もある。
 そこで、変形例6では、あるユーザがチェックインした場所の中であれば、このユーザについては、顔認証による電子決済が許可されるようになっている。この場所の中にいる人間の数は限られているので、顔認証が成功する程度に顔が似た者がいる可能性は非常に低い。チェックイン時には、ユーザ端末30を利用してセキュアな本人確認(いわゆる所持認証)が行われるため、顔認証による電子決済の範囲を、チェックインした場所に限定することによって、ユーザの利便性を高めつつ、セキュリティ性を担保できる。
 図20は、変形例6のチェックインシステムSの一例を示す図である。図20に示すように、第2実施形態と同様にして、ユーザがスタジアムにチェックインすると、スタジアム内に配置された決済端末50であれば、生体認証による電子決済が可能になる。このため、ユーザは、コードC130を表示させる必要はない。
 決済端末50は、認証装置の一例である。このため、決済端末50と記載した箇所は、認証装置と読み替えることができる。認証装置は、生体認証が可能な装置であればよい。変形例6では、顔認証が生体認証に相当する場合を説明するが、生体認証自体は、任意の生体認証を利用可能である。例えば、指紋認証、静脈認証、又は声紋認証といった他の生体認証が利用されてもよい。
 変形例6の第1データベースDB1には、ユーザIDに関連付けて、生体認証で利用される認証情報が格納されている。この認証情報は、生体認証における正解となる情報であり、例えば、顔の特徴量、顔写真、指紋パターン、静脈パターン、又は声紋パターンであってよい。ユーザは、第1サービスの利用設定時に、認証情報の登録に必要な情報(顔写真等)を第1サーバ10にアップロードする。第1サーバ10は、当該アップロードされた情報に基づいて、このユーザのユーザIDに関連付けて、認証情報を格納する。
 変形例6のチェックインシステムSは、許可部104を含む。許可部104は、チェックインが実行された場合には、スタジアムにおいて、ユーザ端末30を利用せずに、生体認証によって電子決済が実行されることを許可する。第1サーバ10は、第2サーバ20からチェックインが実行されたユーザのユーザIDを取得する。第1サーバ10は、第2サーバ20からこのユーザIDを取得するのではなく、チェックイン時に第2サーバ20に送信したユーザIDを、データ記憶部100に保持してもよい。
 例えば、許可部104は、スタジアムにチェックインしたユーザのユーザIDに、生体認証による電子決済が許可されたことを示す情報を関連付ける。これらの関連付けは、第1データベースDB1に保持されてもよいし、他のデータベースに保持されてもよい。第1サービス提供部103は、生体認証による電子決済が許可されたユーザについては、このユーザの生体認証が成功した場合に、電子決済を実行する。
 第1サービス提供部103は、生体認証による電子決済が許可されていないユーザについては、生体認証による電子決済を実行しない。第1サービス提供部103は、生体認証による電子決済が許可されていないユーザであったとしても、もし仮にスタジアム以外のコンピュータから生体認証による電子決済の要求を受け付けたとしても、生体認証による電子決済を実行しない。スタジアムにチェックインしたユーザと顔が似た他のユーザが第1データベースDB1に登録されていたとしても、当該他のユーザはチェックインしていないので、生体認証の判定時に当該他のユーザの情報は判定されない。このため、当該他のユーザのクレジットカード情報等の決済情報は利用されない。
 図20の例であれば、ユーザは、スタジアムの座席でドリンクを購入する場合に、売り子が所持する決済端末50のカメラで自分の顔を撮影させる。決済端末50は、自身の端末IDとともに、撮影画像を第1サーバ10に送信する。第1サーバ10が端末ID及び撮影画像を受信すると、第1サービス提供部103は、撮影画像から顔の特徴量を計算する。第1サービス提供部103は、第1データベースDB1に格納された認証情報のうち、スタジアムにチェックイン中のユーザの認証情報を取得する。
 第1サービス提供部103は、計算した顔の特徴量と、取得した認証情報と、に基づいて、生体認証を実行する。生体認証自体は、公知の方法を利用可能であり、顔の特徴量の類似度によって成否が判定されるようにすればよい。顔認証以外の生体認証が利用される場合も同様に、生体認証自体は、公知の方法を利用可能である。認証時の判定対象となる認証情報が、チェックイン中のユーザのものだけに限定されるようにすればよい。
 第1サービス提供部103は、生体認証が成功した場合に、電子決済を実行する。第1サービス提供部103は、第1データベースDB1を参照し、計算した顔の特徴量と類似する認証情報に関連付けられたクレジットカード情報等の決済情報を取得する。第1サービス提供部103は、この決済情報に基づいて、電子決済を実行する。図20に示すように、ユーザがスタジアム内の売店でグッズを購入する場合、及び、スタジアム内のレストランで食事した場合も同様に、顔認証だけで電子決済が許可される。
 許可部104は、ユーザがチェックアウトした場合、チェックインしてから所定の時間が経過した場合、又はチェックインした後の所定の時間が訪れた場合には、生体認証による電子決済を禁止する。図20の例であれば、ユーザがチェックイン端末40にユーザ端末30のコードC130等をかざしてチェックアウトした場合には、許可部104は、生体認証が許可されないように、第1データベースDB1を更新する。
 変形例6によれば、チェックインが実行された場合には、スタジアムにおいて、ユーザ端末30を利用せずに、生体認証によって電子決済が実行されることが許可されるので、ユーザの利便性を高めることができる。また、生体認証による電子決済が許可される範囲をスタジアム内に限定することで、誤認証や成りすましを防止し、セキュリティを高めることができる。
[3-7.変形例7]
 変形例7では、第1サービスが電子決済サービスであり、第2サービスがカラオケ事業者により提供されるサービスである場合を説明する。ユーザがラオケ事業者の会員になると、カラオケボックスを会員価格で利用できるものとする。ユーザは、ユーザ端末30を利用して、カラオケ事業者の会員登録の手続きを行う。会員登録の手続きは、ユーザ端末30以外のコンピュータから行われてもよい。ユーザが会員登録の手続きをすると、第2サーバ20は、ユーザIDと、第2サービスにおけるユーザの会員情報と、を関連付けて管理する。例えば、第2データベースDB2には、ユーザが会員であるか否かを示す情報が格納される。
 チェックイン端末40は、カラオケボックスの店舗内に配置される。ユーザは、会員にならなくても、カラオケボックスにゲストユーザとしてチェックインできる。ユーザは、会員になった後に、カラオケボックスにチェックインすると、会員価格でカラオケボックスを利用できるようになる。チェックイン実行部202は、ユーザIDに関連付けられた会員情報に基づいて、チェックインを実行する。例えば、チェックイン実行部202は、第2データベースDB2に、ユーザIDに関連付けられた会員情報が存在する場合、ユーザが会員価格でカラオケボックスを利用できるように、このユーザのチェックインを実行する。例えば、店舗の端末又はユーザ端末30に、ユーザが会員であることを通知する処理がチェックインに相当する。また例えば、ユーザの利用金額の基準となる料金を会員価格に設定することがチェックインに相当する。
 変形例7によれば、ユーザの会員情報に基づいてチェックインを実行することによって、ユーザの利便性を高めることができる。例えば、ユーザが多数の会員カードを持ち歩いたり、多数のアプリをユーザ端末30にインストールしたりしなくても、ユーザが会員であることを第1アプリで一元管理できる。
[3-8.変形例8]
 例えば、第2実施形態のように、ユーザが、スタジアムにおける複数の位置の各々で所定のサービスを利用可能である場合、ユーザがスタジアムで利用した利用額が表示されてもよい。変形例8では、このサービスが第1サービスである場合を説明するが、このサービスは、第2サービスであってもよいし、これらとは異なる任意の第3サービスであってもよい。変形例8のチェックインシステムSは、利用額取得部105及び情報提供部106を含む。
 利用額取得部105は、チェックインが実行された場合に、スタジアムにおける一連の利用額を取得する。利用額取得部105は、チェックインが実行された後に、ユーザが第1サービスから電子決済した個々の利用額を取得する。図13の例であれば、利用額取得部105は、座席におけるドリンクの購入、売店におけるグッズの購入、及びレストランにおける食事の支払いの各々の利用額を取得する。個々の利用額は、決済端末50から第1サーバ10に送信される。第1サービス提供部103は、電子決済を実行するたびに、その実行結果の履歴を第1データベースDB1に格納する。利用額取得部105は、この履歴を参照することによって、チェックイン後の個々の電子決済の利用額を取得する。
 図21は、変形例8のユーザ端末30に表示される画面の一例を示す図である。図21に示すように、情報提供部106は、利用額取得部105により取得された利用額に基づいて、スタジアムに関する情報を、ユーザに提供する。スタジアムに関する情報は、利用額に応じた情報であればよく、例えば、個々の利用額そのもの、利用額の合計額、所定の金額になるまでの不足額、利用額に応じたおすすめ情報、又は利用額に応じたクーポン情報である。これらの情報の提示に必要なデータは、第1サーバ10又は他のコンピュータに記憶されているものとする。図21の例では、情報提供部106は、スタジアムに関する情報として、スタジアム内における個々の利用額の履歴情報I150、合計額の情報I151、駐車場が無料になるまでの不足額の情報I152、及びおすすめ情報I153を含む提供画面G15を表示させる。おすすめ情報I153は、駐車場が無料になるまでの不足額を達成できる程度の商品が表示されてもよい。
 変形例8によれば、チェックインが実行された場合に、スタジアムにおける一連の利用額に基づいて、スタジアムに関する情報を、ユーザに提供することによって、一連のサービスの利用額に応じた有益な情報を提供できる。
[3-9.変形例9]
 例えば、第2実施形態において、チェックインシステムSは、チェックインが実行された場合に、スタジアムにおける一連の利用に関する電子決済を、都度実行するか、一括して実行するか、をユーザに応じて決定する決定部107を含んでもよい。電子決済を都度実行するのは、第2実施形態で説明した通りである。電子決済を一括して実行するのは、任意のタイミングであってよく、例えば、ユーザのチェックアウト時、チェックインしてから所定時間の経過時、所定の日時が訪れた時であってよい。一括して実行とは、複数回の利用で発生した複数の利用額の合計額を電子決済することである。
 第1サービス提供部103は、決定部107により決定された決済方法に基づいて、電子決済を実行する。例えば、第1サービス提供部103は、決定部107により都度実行が決定された場合には、第2実施形態と同様にして、電子決済が要求されるたびに、電子決済を実行する。また例えば、第1サービス提供部103は、決定部107により一括して実行が決定された場合には、複数回の利用を第1データベースDB1に蓄積し、所定のタイミングが訪れた場合に、合計額を一括した電子決済を実行する。
 変形例9によれば、チェックインが実行された場合に、スタジアムにおける一連の利用に関する電子決済を、都度実行するか、一括して実行するか、をユーザに応じて決定することによって、ユーザが訪れたスタジアムにおける電子決済の利便性を高めることができる。
[3-10.変形例10]
 例えば、上記説明した変形例を組み合わせてもよい。
 また例えば、第1実施形態及び第2実施形態を組み合わせて、ユーザが電子決済を利用するための第1アプリからホテルにチェックインしてもよい。この場合、ユーザがチェックインしてからチェックアウトするまでにホテルで利用した食事等の支払いが第1アプリの電子決済から実行されてもよい。この場合、チェックアウト時に一括して電子決済が実行されてもよいし、利用の都度、電子決済が実行されてもよい。また例えば、チェックイン端末40は、第1サーバ10介して第2サーバ20に情報を送信するのではなく、コードID等の情報を第2サーバ20に直接的に送信してもよい。
 また例えば、ユーザがユーザ端末30をチェックイン端末40にかざすことによってチェックインが実行される場合を説明したが、画像を利用するのではなく、ICチップ37に記録された何らかのIDをチェックイン端末40に読み取らせてチェックインが実行されてもよい。また例えば、ユーザ端末30又はチェックイン端末40の何れか一方のみによってチェックインが実行されてもよい。例えば、ホテル又はスタジアム等の場所に掲示又は何らかのコンピュータに表示されたコードがユーザ端末30の撮影部36で撮影された場合に、ユーザ端末30から第1サーバ10に、この場所を識別可能な情報と、ユーザ端末30に記憶されたコードIDと、が送信されてもよい。この場合、チェックイン端末40は不要になる。
 また例えば、ユーザ端末30のGPS受信部38によって検出された現在位置がホテルやスタジアムの付近になった場合に、チェックインが実行されてもよい。この場合、チェックイン端末40は不要になる。また例えば、ユーザが物理カード又は磁気カードをチェックイン端末40で読み取ることによってチェックインが実行されてもよい。この場合、ユーザ端末30は不要になる。他にも例えば、ユーザがチェックイン端末40からの生体認証でチェックインが実行されてもよい。この場合もユーザ端末30は不要になる。
 また例えば、第2サービスに関する場所は、予約等の申し込みが発生しない場所であってもよい。例えば、この場所は、ショッピングモール、スーパーマーケット、コンビニエンスストア、日帰りの温泉施設、ゲームセンター、又は百貨店等の施設であってもよい。ユーザは、特に予約をせずに、これらの施設を訪れる。ユーザは、第1実施形態、第2実施形態、及び変形例と同様の手順により、これらの施設に配置されたチェックイン端末40からチェックインを実行すればよい。
 また例えば、第1サーバ10と第2サーバ20が分けられておらず、1つのコンピュータで各機能が実現されてもよい。また例えば、第1サーバ10で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。また例えば、第2サーバ20で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも1つのコンピュータで実現されるようにすればよい。

Claims (20)

  1.  第1サービスのユーザが第2サービスに関する場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記第1サービスで前記ユーザを識別可能な第1情報を取得する取得手段と、
     前記第1情報又は前記第1情報に関連付けられた第2情報に基づいて、前記場所へのチェックインを実行するチェックイン実行手段と、
     を含むチェックインシステム。
  2.  前記ユーザ端末は、前記第1サービスを利用するための第1アプリに基づいて、前記第1情報を含むコードを表示可能であり、
     前記チェックイン端末は、前記コードを読み取り可能であり、
     前記取得手段は、前記コードが前記チェックイン端末で読み取られた場合に、前記第1情報を取得する、
     請求項1に記載のチェックインシステム。
  3.  前記ユーザ端末は、前記第1サービス用の第1コードと、前記第2サービス用の第2コードと、の各々を表示可能であり、
     前記第2コードは、前記第1情報を含み、
     前記取得手段は、前記第2コードが前記チェックイン端末で読み取られた場合に、前記第1情報を取得する、
     請求項2に記載のチェックインシステム。
  4.  前記コードは、前記第1サービス及び前記第2サービスで共通のコードであり、
     前記チェックインシステムは、前記第1サービスの第1サービス端末で前記共通のコードが読み取られた場合に、前記第1情報に基づいて、前記第1サービスを提供する第1サービス提供手段を更に含み、
     前記取得手段は、前記共通のコードが前記チェックイン端末で読み取られた場合に、前記第1情報を取得する、
     請求項2に記載のチェックインシステム。
  5.  前記ユーザは、複数の前記場所の各々を訪問可能であり、
     前記コードは、前記複数の場所で共通のコードであり、
     前記取得手段は、前記共通のコードが前記チェックイン端末で読み取られた場合に、前記第1情報を取得する、
     請求項2~4の何れかに記載のチェックインシステム。
  6.  前記ユーザは、複数の第2サービスの各々に関する前記場所を訪問可能であり、
     前記コードは、前記複数の第2サービスで共通のコードであり、
     前記取得手段は、前記共通のコードが前記チェックイン端末で読み取られた場合に、前記第1情報を取得する、
     請求項2~5の何れかに記載のチェックインシステム。
  7.  前記チェックインシステムは、
     前記ユーザ端末から前記第1情報の発行要求を受け付ける受付手段と、
     前記発行要求が受け付けられた場合に、前記第1情報を発行して前記ユーザ端末に送信する発行手段と、
     を更に含み、
     前記ユーザ端末は、前記第1情報を受信して自身の記憶手段に記録し、
     前記取得手段は、前記記憶手段に記録された前記第1情報を取得する、
     請求項1~6の何れかに記載のチェックインシステム。
  8.  前記ユーザは、前記場所を訪れる前に、前記第2サービスを利用して前記場所に関する申し込みを行い、
     前記第2サービスの第2サーバは、前記第1情報又は前記第2情報と、前記申し込みに関する申込情報と、を関連付けて管理し、
     前記チェックイン実行手段は、前記第1情報又は前記第2情報に関連付けられた前記申込情報に基づいて、前記チェックインを実行する、
     請求項1~7の何れかに記載のチェックインシステム。
  9.  前記第2情報は、前記第1サービス及び前記第2サービスの両方で前記ユーザを識別可能な情報であり、
     前記第2サーバは、前記第2情報と、前記申込情報と、を関連付けて管理し、
     前記第1サービスの第1サーバは、前記第1情報と、前記第2情報と、を関連付けて管理し、
     前記第1サーバは、前記取得手段により取得された前記第1情報に関連付けられた前記第2情報を、前記第2サーバに送信し、
     前記第2サーバは、前記チェックイン実行手段を含み、前記第1サーバから受信した前記第2情報に関連付けられた前記申込情報に基づいて、前記チェックインを実行する、
     請求項8に記載のチェックインシステム。
  10.  前記ユーザは、複数の前記場所の各々に関する前記申し込みを行い、
     前記第2サーバは、前記第1情報又は前記第2情報と、前記複数の場所の各々の前記申込情報と、を関連付けて管理し、
     前記チェックイン実行手段は、前記複数の場所の各々の前記申込情報のうち、前記ユーザが訪れた前記場所の前記申込情報に基づいて、前記チェックインを実行する、
     請求項8又は9に記載のチェックインシステム。
  11.  前記ユーザは、複数の日時の各々で前記場所に関する前記申し込みを行い、
     前記第2サーバは、前記第1情報又は前記第2情報と、前記複数の日時の各々の前記申込情報と、を関連付けて管理し、
     前記チェックイン実行手段は、前記複数の日時の各々の前記申込情報のうち、前記ユーザが前記場所を訪れた日時の前記申込情報に基づいて、前記チェックインを実行する、
     請求項8~10の何れかに記載のチェックインシステム。
  12.  前記第2サービスは、前記場所に関するチケットの購入申し込みを受け付けるサービスであり、
     第1ユーザは、前記第2サービスを利用して、複数の前記チケットを申し込み、
     前記第2サーバは、前記第1ユーザの前記第1情報又は前記第2情報と、前記複数のチケットの各々の前記申込情報と、を関連付けて管理し、
     前記チェックインシステムは、前記複数のチケットのうち、第2ユーザの前記チケットの前記申込情報を、前記第2ユーザの前記第1情報又は前記第2情報に関連付けることによって、前記第2ユーザに当該チケットを分配する分配手段を更に含み、
     前記取得手段は、前記第1ユーザが前記場所を訪れた場合に、前記第1ユーザの前記第1情報を取得し、前記第2ユーザが前記場所を訪れた場合に、前記第2ユーザの前記第1情報を取得し、
     前記チェックイン実行手段は、前記第1ユーザの前記第1情報又は前記第2情報に関連付けられた前記申込情報に基づいて、前記第1ユーザの前記チェックインを実行し、前記第2ユーザの前記第1情報又は前記第2情報に関連付けられた前記申込情報に基づいて、前記第2ユーザの前記チェックインを実行する、
     請求項8~11の何れかに記載のチェックインシステム。
  13.  前記第1サービスは、電子決済を提供するサービスであり、
     前記チェックインシステムは、前記申し込みに関する前記電子決済を実行する第1サービス提供手段を更に含む、
     請求項8~12の何れかに記載のチェックインシステム。
  14.  前記第1サービスは、電子決済を提供するサービスであり、
     前記ユーザは、前記場所で所定のサービスを利用可能であり、
     前記チェックインシステムは、前記チェックインが実行された場合に、前記場所における利用に関する前記電子決済を実行する第1サービス提供手段を更に含む、
     請求項1~13の何れかに記載のチェックインシステム。
  15.  前記第1サービスは、前記ユーザ端末を利用した前記電子決済を提供するサービスであり、
     前記場所には、前記ユーザの生体認証を実行するための認証装置が配置されており、
     前記チェックインシステムは、前記チェックインが実行された場合には、前記場所において、前記ユーザ端末を利用せずに、前記生体認証によって前記電子決済が実行されることを許可する許可手段、
     を更に含む請求項13又は14に記載のチェックインシステム。
  16.  前記第2サービスの第2サーバは、前記第1情報又は前記第2情報と、前記第2サービスにおける前記ユーザの会員情報と、を関連付けて管理し、
     前記チェックイン実行手段は、前記第1情報又は前記第2情報に関連付けられた前記会員情報に基づいて、前記チェックインを実行する、
     請求項1~15の何れかに記載のチェックインシステム。
  17.  前記第1サービスは、電子決済を提供するサービスであり、
     前記ユーザは、前記場所における複数の位置の各々で所定のサービスを利用可能であり、
     前記チェックインシステムは、
     前記チェックインが実行された場合に、前記場所における一連の利用額を取得する利用額取得手段と、
     前記利用額に基づいて、前記場所に関する情報を、前記ユーザに提供する提供手段と、
     を含む請求項1~16の何れかに記載のチェックインシステム。
  18.  前記第1サービスは、電子決済を提供するサービスであり、
     前記ユーザは、前記場所における複数の位置の各々で所定のサービスを利用可能であり、
     前記チェックインシステムは、
     前記チェックインが実行された場合に、前記場所における一連の利用に関する前記電子決済を、都度実行するか、一括して実行するか、を前記ユーザに応じて決定する決定手段と、
     前記決定手段により決定された決済方法に基づいて、前記電子決済を実行する第1サービス提供手段と、
     を含む請求項1~17の何れかに記載のチェックインシステム。
  19.  第1サービスのユーザが第2サービスに関する場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記第1サービスで前記ユーザを識別可能な第1情報を取得する取得ステップと、
     前記第1情報又は前記第1情報に関連付けられた第2情報に基づいて、前記場所へのチェックインを実行するチェックイン実行ステップと、
     を含むチェックイン方法。
  20.  第1サービスのユーザが第2サービスに関する場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記第1サービスで前記ユーザを識別可能な第1情報を取得する取得手段、
     前記第1情報又は前記第1情報に関連付けられた第2情報に基づいて、前記場所へのチェックインを実行するチェックイン実行手段、
     としてコンピュータを機能させるためのプログラム。
PCT/JP2021/014022 2021-03-31 2021-03-31 チェックインシステム、チェックイン方法、及びプログラム WO2022208806A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022509071A JP7142185B1 (ja) 2021-03-31 2021-03-31 チェックインシステム、チェックイン方法、及びプログラム
PCT/JP2021/014022 WO2022208806A1 (ja) 2021-03-31 2021-03-31 チェックインシステム、チェックイン方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/014022 WO2022208806A1 (ja) 2021-03-31 2021-03-31 チェックインシステム、チェックイン方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022208806A1 true WO2022208806A1 (ja) 2022-10-06

Family

ID=83400873

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/014022 WO2022208806A1 (ja) 2021-03-31 2021-03-31 チェックインシステム、チェックイン方法、及びプログラム

Country Status (2)

Country Link
JP (1) JP7142185B1 (ja)
WO (1) WO2022208806A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003187272A (ja) * 2001-12-20 2003-07-04 Mediaseek Inc 電子チケット、電子チケット販売システム及び電子チケット販売方法
JP2007249549A (ja) * 2006-03-15 2007-09-27 Toshiba Tec Corp 宿泊施設利用システム
JP2013522777A (ja) * 2010-03-23 2013-06-13 アマゾン テクノロジーズ インコーポレイテッド 効率的な取引のためのユーザプロファイルおよび地理的位置
CN108537689A (zh) * 2018-05-17 2018-09-14 东莞市鑫禧塑胶电子有限公司 一种酒店自助机操作系统及其操作方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003187272A (ja) * 2001-12-20 2003-07-04 Mediaseek Inc 電子チケット、電子チケット販売システム及び電子チケット販売方法
JP2007249549A (ja) * 2006-03-15 2007-09-27 Toshiba Tec Corp 宿泊施設利用システム
JP2013522777A (ja) * 2010-03-23 2013-06-13 アマゾン テクノロジーズ インコーポレイテッド 効率的な取引のためのユーザプロファイルおよび地理的位置
CN108537689A (zh) * 2018-05-17 2018-09-14 东莞市鑫禧塑胶电子有限公司 一种酒店自助机操作系统及其操作方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "PayPal aims to popularize digital wallets that integrate the real net", THE CONSUMER CREDIT MONTHLY, vol. 33, no. 5, 1 May 2015 (2015-05-01), JP, pages 14 - 19, XP009540473, ISSN: 0288-8122 *
FUJITA SATORU: "Touchless and comfortable experience for the future customer", NEC TECHNICAL JOURNAL, vol. 73, no. 1, 15 October 2020 (2020-10-15), JP , pages 97 - 100, XP009540254, ISSN: 0285-4139 *

Also Published As

Publication number Publication date
JP7142185B1 (ja) 2022-09-26
JPWO2022208806A1 (ja) 2022-10-06

Similar Documents

Publication Publication Date Title
US20230368183A1 (en) Consumer device based point-of-sale
RU2394275C2 (ru) Система и способ проведения транзакций
JP5872083B2 (ja) 効率的な取引のためのユーザプロファイルおよび地理的位置
US20150046202A1 (en) Universal Ticketing and Payment System
US20100082487A1 (en) Systems and methods for managing a virtual card based on geographical information
US20190295006A1 (en) Use of ticket for purchasing
US20240095607A1 (en) Ticket system, program, and method
US20140249904A1 (en) Systems and Methods for Managing a Virtual Card Based on Geographical and Balance Information
US20100250290A1 (en) System and method for token-based transactions
US20170200319A1 (en) Queue management system and method
US20130066660A1 (en) Event reservation system
US20130063246A1 (en) System and method for electronically providing an access authorization
JP2015075947A (ja) 情報処理システム、売買支援サーバ、販売者端末および購入者端末
US20130024216A1 (en) Apparatus and method for expedited event access
JP7142185B1 (ja) チェックインシステム、チェックイン方法、及びプログラム
US20130024218A1 (en) Apparatus and method for expedited event access
WO2021009969A1 (ja) 処理管理システム、処理管理装置、処理管理方法、及びコンピュータプログラム
CN114663255A (zh) 基于标签终端的酒店服务管理系统
JP7382363B2 (ja) 情報提供システム、情報提供方法、及びプログラム
JP7153756B1 (ja) 電子決済システム、電子決済方法、及びプログラム
JP6448758B1 (ja) 交通系カード入場管理システム
JP2021135768A (ja) チケット販売方法、チケット販売プログラム、並びに情報処理装置
JP2001209741A (ja) 移動体通信装置およびその使用方法
KR102300754B1 (ko) 오프라인 거래에 수반하는 생활 관련 정보의 관리방법, 오프라인 거래에 수반하는 생활 관련 정보의 관리를 위한 정보 전송 장치, 오프라인 거래의 정당성 인증 방법, 및 오프라인 거래의 정당성 인증을 수행하기 위한 정보 전송 장치
WO2024095377A1 (ja) サーバ装置、システム、サーバ装置の制御方法及び記憶媒体

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2022509071

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 17785340

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21934970

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21934970

Country of ref document: EP

Kind code of ref document: A1