JP7526321B2 - Information processing method, information processing system, information processing device, and program - Google Patents

Description

The present invention relates to an information processing method, an information processing system, an information processing device, and a program.

There is a technology that uses a visitor identification code to check in visitors when they arrive at a facility or event venue. For example, Patent Document 1 discloses a visitor management system that reads a visitor identification code printed on a letter brought by the visitor and registers the read visitor identification code in a visitor database.

JP 2006-99786 A

However, the invention in Patent Document 1 has the problem that visitor data cannot be checked at any time until the delivery date.

One aspect is to provide an information processing method that allows exhibitors to download visitor data in real time.

An information processing method according to one aspect includes transmitting an exhibitor code for identifying an exhibitor to be read by a mobile terminal lent to a plurality of exhibitors exhibiting at an event, accepting login to the mobile terminal using the exhibitor code, storing visitor data corresponding to the visitor code read by the mobile terminal after login in association with the exhibitor, notifying each exhibitor of exhibitor access information for downloading the visitor data before or during the exhibition, and outputting the visitor data in response to a download request for the visitor data based on the notified exhibitor access information.

One aspect is that exhibitors can download visitor data in real time.

FIG. 1 is an explanatory diagram showing an overview of a visitor management system for exhibitors. FIG. 2 is a block diagram showing an example of the configuration of a server. FIG. 2 is an explanatory diagram illustrating an example of a record layout of an event DB. FIG. 2 is an explanatory diagram illustrating an example of a record layout of a download data DB. FIG. 13 is an explanatory diagram showing an example of a record layout of a visitor DB. FIG. 2 is an explanatory diagram illustrating an example of a record layout of an exhibitor DB. FIG. 2 is an explanatory diagram illustrating an example of a record layout of a terminal monitoring DB. FIG. 2 is a block diagram showing a configuration example of a mobile terminal. FIG. 2 is a block diagram showing an example of the configuration of an exhibitor terminal. FIG. 2 is an explanatory diagram illustrating the operation of the visitor management system. 13 is a flowchart showing a processing procedure when performing login processing of a mobile terminal using an exhibitor code. 13 is a flowchart showing a processing procedure for outputting attendee data. 13 is a flowchart showing a processing procedure for outputting attendee data. FIG. 13 is an explanatory diagram showing an example of a screen displaying an exhibitor code on an exhibitor terminal. FIG. 13 is an explanatory diagram showing an example of a screen for reading an exhibitor code by a mobile terminal. FIG. 13 is an explanatory diagram showing an example of a visitor data download screen. FIG. 11 is a block diagram showing an example of the configuration of a server according to a second embodiment. FIG. 11 is an explanatory diagram illustrating an example of a record layout of a download setting DB. 10 is a flowchart showing a processing procedure for accepting a selection of an item to be downloaded. 13 is a flowchart showing a processing procedure for outputting attendee data based on items to be downloaded. FIG. 13 is an explanatory diagram showing an example of a screen that accepts the selection of an item to be downloaded; FIG. 13 is a block diagram showing an example of the configuration of a server according to a third embodiment. FIG. 13 is an explanatory diagram showing an example of a record layout of a visitor management DB. FIG. 11 is a block diagram showing an example of the configuration of a mobile terminal according to a third embodiment. FIG. 13 is an explanatory diagram illustrating an example of a record layout of a reading history DB. 11 is an explanatory diagram showing an example of a record layout of a DB for displaying visitor information; FIG. FIG. 13 is a functional block diagram showing the processing operation for performing synchronization processing based on a visitor ID. 13 is a flowchart showing a processing procedure for receiving visitors to an event. 13 is a flowchart showing a processing procedure for receiving visitors to an event. FIG. 13 is an explanatory diagram showing an example of a visitor reception screen. FIG. 13 is an explanatory diagram showing an example of a reading history screen.

The present invention will be described in detail below with reference to drawings showing an embodiment of the invention.

(Embodiment 1)
The first embodiment relates to a form in which visitor data is output in response to a download request from an exhibitor exhibiting at an event. Fig. 1 is an explanatory diagram showing an overview of a visitor management system for exhibitors. The system of this embodiment includes a management device 1, a mobile terminal 2, and an exhibitor terminal 3, and each device transmits and receives information via a network N such as the Internet.

The management device 1 is an information processing device that processes, stores, and transmits/receives various types of information. The management device 1 is, for example, a server device, a personal computer, etc. In this embodiment, the management device 1 is a server device, and for the sake of brevity, will be referred to as server 1 below.

The mobile terminal 2 is a terminal device that logs in to the mobile terminal using the exhibitor code, reads the visitor code, and transmits the visitor identification information read from the visitor code. The mobile terminal 2 is, for example, an information processing device such as a smartphone or tablet. Alternatively, the mobile terminal 2 may be a terminal device equipped with a dedicated reading module capable of reading codes.

For example, the mobile terminal 2 reads the code to check the attendance of visitors at an event where multiple sub-events (for example, exhibition booths or seminars within the event), such as an exhibition event where multiple exhibitors set up booths, are held. Note that the event is not limited to an exhibition event, and may be other events, such as a lecture or live music concert. The mobile terminal 2 is operated, for example, by the event organizer or an exhibitor exhibiting at an individual booth within the event venue, and reads the code at a specified reception desk set up at the event venue or at each booth. For example, the mobile terminal 2 is lent to a person in charge of the event organizer or to the organizers (exhibitors) of each sub-event during the event, and is returned after the event ends.

The exhibitor terminal 3 is a terminal device that downloads visitor data and displays visitor data. The exhibitor terminal 3 is, for example, an information processing device such as a smartphone, a mobile phone, a tablet, or a personal computer terminal.

In this embodiment, the server 1 issues exhibitor codes to the exhibitors to identify the exhibitors, which can be read by the mobile terminals 2 lent to the multiple exhibitors exhibiting at the event. The server 1 accepts logins from the mobile terminals 2 using the exhibitor codes issued to the exhibitors, and performs login processing. The server 1 registers in advance information about visitors (applicants) attending the event in association with visitor identification information, and issues visitor codes describing the visitor identification information to the visitors in advance.

After logging in to the mobile terminal 2, the mobile terminal 2 reads the visitor identification information from the visitor code issued to the visitor and transmits it to the server 1 via the network N. Based on the visitor identification information transmitted from the mobile terminal 2, the server 1 stores the visitor data in association with the exhibitor. Before or during the exhibition, the server 1 transmits the exhibitor's access information for downloading the visitor data to the exhibitor terminal 3 of each exhibitor. The exhibitor terminal 3 receives the exhibitor's access information transmitted from the server 1. The exhibitor terminal 3 transmits a request to the server 1 to download the exhibitor's visitor data.

When the server 1 receives a download request for visitor data transmitted from the exhibitor terminal 3, it determines whether or not the number of download requests for visitor data has exceeded a predetermined number. If the server 1 determines that the number of download requests has not exceeded the predetermined number, it outputs the visitor data in response to the download request to the exhibitor terminal 3. If the server 1 determines that the number of download requests has exceeded the predetermined number, it resends access information for a new exhibitor to the exhibitor terminal 3.

Figure 2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a storage unit 12, a communication unit 13, an input unit 14, a display unit 15, a reading unit 16, and a large-capacity storage unit 17. Each component is connected by a bus B.

The control unit 11 includes a processor such as a CPU (Central Processing Unit), MPU (Micro-Processing Unit), and GPU (Graphics Processing Unit), and performs various information processing, control processing, and the like related to the server 1 by reading and executing a control program 1P stored in the storage unit 12. Note that while the control unit 11 is described in FIG. 2 as being a single processor, it may be a multi-processor.

The memory unit 12 includes memory elements such as RAM (Random Access Memory) and ROM (Read Only Memory), and stores the control program 1P or data etc. required for the control unit 11 to execute processing. The memory unit 12 also temporarily stores data etc. required for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing communication-related processing, and transmits and receives information between the mobile terminal 2 and the exhibitor terminal 3 etc. via the network N.

The input unit 14 is an input device such as a mouse, keyboard, touch panel, or button, and outputs received operation information to the control unit 11. The display unit 15 is a liquid crystal display or an organic EL (electroluminescence) display, etc., and displays various information according to instructions from the control unit 11.

The reading unit 16 reads the portable storage medium 1a, which may be a CD (Compact Disc)-ROM or a DVD (Digital Versatile Disc)-ROM. The control unit 11 may read the control program 1P from the portable storage medium 1a via the reading unit 16 and store it in the mass storage unit 17. The control unit 11 may also download the control program 1P from another computer via a network N or the like and store it in the mass storage unit 17. The control unit 11 may also read the control program 1P from the semiconductor memory 1b.

The mass storage unit 17 includes a recording medium such as a HDD (Hard disk drive) or SSD (Solid State Drive). The mass storage unit 17 includes an event DB (database) 171, a download data DB 172, a visitor DB 173, an exhibitor DB 174, and a terminal monitoring DB 175. The event DB 171 stores information about events. The download data DB 172 stores visitor data for download. The visitor DB 173 stores information about visitors. The exhibitor DB 174 stores information about exhibitors. The terminal monitoring DB 175 stores information about multiple mobile terminals to be monitored.

In this embodiment, the memory unit 12 and the large-capacity memory unit 17 may be configured as an integrated memory device. The large-capacity memory unit 17 may also be configured from multiple memory devices. Furthermore, the large-capacity memory unit 17 may be an external memory device connected to the server 1.

In this embodiment, the server 1 is described as being one information processing device, but the processing may be distributed among a plurality of devices, or the server 1 may be configured as a virtual machine.

Figure 3 is an explanatory diagram showing an example of a record layout of event DB171. Event DB171 includes an event ID column, an event name column, a program column, an event location column, an event date column, an event start time column, an event end time column, a downloadable period column, a login period column, an application start date and time column, an application end date and time column, an acceptance start time column, an acceptance end time column, a sub-event ID column, and a sub-event name column.

The event ID column stores a unique event ID to identify each event. The event name column stores the name of the event. The program column stores the event program (contents). The venue column stores the location where the event is held. The event date column stores the date on which the event is held. The event start time column stores the start time of the event. The event end time column stores the end time of the event. The downloadable period column stores the period during which visitor data can be downloaded.

The login period column stores the period during which the mobile terminal 2 can log in to the server 1 using the exhibitor code. The application start date and time column stores the start date and time for applying for the event. The application end date and time column stores the end date and time for applying for the event. The acceptance start time column stores the start time at which the event is accepted. The acceptance end time column stores the end time at which the event is accepted. The sub-event ID column stores a sub-event ID that uniquely identifies a sub-event within an event. The sub-event name column stores the name of the sub-event.

Figure 4 is an explanatory diagram showing an example of a record layout of the download data DB 172. The download data DB 172 includes a terminal ID column, an exhibitor ID column, a read date and time column, a visitor ID column, a request code column, and a lead ID column. The terminal ID column stores a mobile terminal ID that identifies the mobile terminal 2 loaned to the exhibitor. The exhibitor ID column stores an exhibitor ID that identifies the exhibitor. The read date and time column stores date and time information when the visitor code was read. The visitor ID column stores the visitor ID (read content) read from the visitor code.

The request code column stores a request code that identifies a request. A request code is an identifier used to identify the request of a visitor attending an event (for example, the person giving the explanation on the day, the level of interest, the catalogues to be distributed, etc.), and is defined arbitrarily by the organizer (exhibitor) of the sub-event. By checking the request code, the organizer of the sub-event can quickly understand the visitor's request. The lead ID column stores a unique ID for each applicant for an event (campaign, seminar, etc.).

Figure 5 is an explanatory diagram showing an example of a record layout of visitor DB 173. Visitor DB 173 includes a visitor ID column, an event ID column, a sub-event ID column, a visitor count column, a surname column, a middle name column, a given name column, a surname (furigana) column, a given name (furigana) column, a company name column, a company name (furigana) column, a department column, and an attribute column. The visitor ID column stores a visitor ID that uniquely identifies each visitor to identify them. The event ID column stores an event ID that identifies an event. The sub-event ID column stores a sub-event ID that identifies a sub-event that a visitor will attend. The visitor count column stores the number of people who attended an event according to one visitor ID. One visitor ID can be used by multiple visitors (multiple people) at the same time.

The last name column stores the last name of the visitor. The middle name column stores the middle name of the visitor. The first name column stores the first name of the visitor. The last name (furigana) column stores the furigana of the visitor's last name. The first name (furigana) column stores the furigana of the visitor's first name. The company name column stores the name of the company to which the visitor belongs. The company name (furigana) column stores the furigana of the company name. The department column stores the department of the company to which the visitor belongs. The attribute column stores attribute information according to the attributes of the visitor. For example, if the event is a product exhibition, the attribute information can be expressed as "VIP (Very Important Person) member,""customer who purchased product A," etc.

Figure 6 is an explanatory diagram showing an example of a record layout of exhibitor DB 174. Exhibitor DB 174 includes an exhibitor ID column, an event ID column, a sub-event ID column, an exhibitor name column, a number of available terminals column, an email address column, a passcode column, a data download date and time column, and a number of download requests column. The exhibitor ID column stores an exhibitor ID that uniquely identifies each exhibitor. The event ID column stores an event ID that uniquely identifies an event. The sub-event ID column stores a sub-event ID that uniquely identifies a sub-event within an event. The exhibitor name column stores the name of the exhibitor. The number of available terminals column stores the number of mobile terminals 2 that can be loaned to an exhibitor.

The email address column stores the email address of the exhibitor. The passcode column stores a passcode for authentication when downloading visitor data. The data download date and time column stores information about the date and time when visitor data was downloaded. The download request count column stores the number of times a visitor data download was requested according to the exhibitor's access information. The access information will be described later.

Figure 7 is an explanatory diagram showing an example of a record layout of the terminal monitoring DB 175. The terminal monitoring DB 175 includes a terminal ID column, a terminal name column, a last application login date and time column, a last read date and time column, a status column, and an exhibitor ID column. The terminal ID column stores a unique ID of the mobile terminal 2 to identify each mobile terminal 2 to be monitored. The terminal name column stores the name of the mobile terminal 2 to be monitored. The last application login date and time column stores date and time information when the mobile terminal 2 to be monitored last logged in (connected) to the server 1.

The last read date and time column stores the date and time when the communication status of the mobile terminal 2 was last read. The status column stores the communication status with the mobile terminal 2 to be monitored. In this embodiment, the status of "online", "offline" or "stopped" is stored as the communication status. "Online" means that the server 1 can communicate with the mobile terminal 2. "Offline" means that the server 1 cannot communicate with the mobile terminal 2. "Stopped" means that the communication function of the mobile terminal 2 has been stopped by the server 1. The exhibitor ID column stores the exhibitor ID that identifies the exhibitor.

Note that the storage format of each DB described above is just an example, and other storage formats are also possible as long as the relationships between data are maintained.

Figure 8 is a block diagram showing an example of the configuration of the mobile terminal 2. The mobile terminal 2 includes a control unit 21, a storage unit 22, a communication unit 23, an input unit 24, a display unit 25, a clock unit 26, a photographing unit 28, and a code reading unit 29. Each component is connected by a bus B.

The control unit 21 includes an arithmetic processing device such as a CPU or an MPU, and performs various information processing, control processing, and the like related to the mobile terminal 2 by reading and executing a control program 2P stored in the storage unit 22. Note that, although the control unit 21 is described as a single processor in Fig. 8, it may be a multi-processor. The storage unit 22 includes memory elements such as a RAM and a ROM, and stores the control program 2P or data, etc., required for the control unit 21 to execute processing. The storage unit 22 also temporarily stores data, etc., required for the control unit 21 to execute arithmetic processing.

The communication unit 23 is a communication module for performing communication-related processing using a wireless radio WAN (Wide Area Network), and transmits and receives information to and from the server 1, etc., via the network N. The wireless WAN is a network for connecting to the carrier's communication network via mobile phone lines such as the 4G (Generation) or 5G LTE (Long Term Evolution) communication standard, and is provided to the subscriber. The input unit 24 may be a keyboard, a mouse, or a touch panel integrated with the display unit 25. The display unit 25 is a liquid crystal display or an organic EL display, etc., and displays various information according to instructions from the control unit 21.

The clock unit 26 is a circuit that keeps track of time or elapsed time, etc., and provides the control unit 21 with the timekeeping results in response to a request from the control unit 21. The clock unit 26 also provides a timer function. The timer function is a function that notifies the control unit 21 when a preset time has elapsed since a start command was issued. Alternatively, the timer function is a function that responds to an inquiry from the control unit 21 as to whether or not a preset time has elapsed since a start command was issued.

The photographing unit 28 is, for example, a photographing device such as a CCD (Charge Coupled Device) camera or a CMOS (Complementary Metal Oxide Semiconductor) camera. The photographing unit 28 may be composed of multiple photographing devices. The photographing unit 28 may not be built into the mobile terminal 2, but may be externally connected directly to the mobile terminal 2 and configured to be capable of photographing. The code reading unit 29 is a read-only module for reading two-dimensional codes, one-dimensional codes, etc. The reading of codes will be described later.

Figure 9 is a block diagram showing an example of the configuration of the exhibitor terminal 3. The exhibitor terminal 3 includes a control unit 31, a memory unit 32, a communication unit 33, an input unit 34, and a display unit 35. Each component is connected by a bus B.

The control unit 31 includes an arithmetic processing device such as a CPU or MPU, and performs various information processing, control processing, etc. related to the exhibitor terminal 3 by reading and executing the control program 3P stored in the memory unit 32. Note that while FIG. 9 describes the control unit 31 as a single processor, it may also be a multi-processor. The memory unit 32 includes memory elements such as RAM and ROM, and stores the control program 3P or data, etc. required for the control unit 31 to execute processing. The memory unit 32 also temporarily stores data, etc. required for the control unit 31 to execute arithmetic processing.

The communication unit 33 is a communication module for performing communication-related processing, and transmits and receives information to and from the server 1, etc., via the network N. The input unit 34 may be a keyboard, a mouse, or a touch panel integrated with the display unit 35. The display unit 35 is a liquid crystal display or an organic EL display, etc., and displays various information according to instructions from the control unit 31.

Figure 10 is an explanatory diagram explaining the operation of the visitor management system. Figure 10A is an explanatory diagram explaining the operation of performing login processing of the mobile terminal 2 using the exhibitor code. First, the server 1 generates and transmits an exhibitor code that identifies the exhibitor, to be read by the mobile terminal 2 lent to multiple exhibitors exhibiting at the event.

The exhibitor code may be, for example, a two-dimensional code, a one-dimensional code, etc. A two-dimensional code is a code that displays information in both the horizontal and vertical directions, as opposed to a one-dimensional code that displays information only in the horizontal direction. Typical two-dimensional codes include, for example, QR Code (registered trademark), DataMatrix (registered trademark), and VeriCode (registered trademark). One-dimensional codes are,
For example, a barcode is used. In the present embodiment, a two-dimensional code is read as an example.

In addition, if multiple mobile terminals 2 are lent to an exhibitor, an individual exhibitor code may be issued to each mobile terminal 2, or a common exhibitor code may be issued to multiple mobile terminals 2.

Specifically, based on the event ID, server 1 obtains from exhibitor DB 174 the exhibitor ID of the exhibitor for whom a two-dimensional code is to be issued. Server 1 uses a two-dimensional code generation library to generate an exhibitor code that describes the exhibitor ID and event ID. Note that the items embedded in the exhibitor code may be set to any items according to actual needs. For example, the exhibitor code describes the exhibitor ID, exhibitor name, and event ID.

The server 1 sends the generated exhibitor code to the exhibitor terminal 3, for example by sending an email. The exhibitor terminal 3 receives the email sent from the server 1 and displays the exhibitor code. Note that the process of sending and receiving the exhibitor code is not limited to email. For example, the server 1 outputs the generated exhibitor code to the exhibitor's page in an app (application) for the exhibitor. The exhibitor may log into the app and the exhibitor terminal 3 may display the exhibitor code output on the exhibitor's page. Note that the exhibitor code may be mailed directly to the exhibitor.

Next, the mobile terminal 2 logs in to the server 1 using the exhibitor code. Specifically, the mobile terminal 2 reads the exhibitor ID and event ID from the exhibitor code, and transmits the exhibitor ID and event ID that it has read, as well as the mobile terminal ID, to the server 1. The server 1 determines whether or not login is possible based on the exhibitor ID and event ID transmitted from the mobile terminal 2.

Specifically, the server 1 compares the received exhibitor ID and event ID with the exhibitor ID and event ID stored in the exhibitor DB 174. If the server 1 determines that they match, it obtains the login-enabled period from the event DB 171 based on the received event ID. If the server 1 determines that the current date and time is within the login-enabled period, it obtains the number of available mobile terminals from the exhibitor DB 174 based on the received exhibitor ID and event ID. The server 1 counts the number of logged-in mobile terminals 2 from the online status of the monitored terminals stored in the terminal monitoring DB 175, and determines whether the counted number of logged-in mobile terminals 2 exceeds the number of available mobile terminals. If the server 1 determines that the number of logged-in mobile terminals 2 does not exceed the number of available mobile terminals, it determines that login is possible.

If the server 1 determines that login is possible, it stores the terminal ID, terminal name, login date and time, read date and time, communication status, and exhibitor ID as a single record in the terminal monitoring DB 175. The server 1 sends the visitor's reception screen to the mobile terminal 2. The mobile terminal 2 receives the visitor's reception screen sent from the server 1 and displays the received reception screen.

Figure 10B is an explanatory diagram explaining the operation of outputting visitor data in response to a download request from an exhibitor. After logging in to the server 1 using the exhibitor code, the mobile terminal 2 reads visitor identification information from the visitor code issued to the visitor who attended the event. The visitor code, like the exhibitor code, is, for example, a two-dimensional code, a one-dimensional code, etc. The visitor identification information is, for example, a visitor ID for identifying the visitor. The mobile terminal 2 transmits the read visitor ID and mobile terminal ID to the server 1.

The server 1 receives the visitor ID and mobile terminal ID transmitted from the mobile terminal 2, and obtains the exhibitor ID from the terminal monitoring DB 175 based on the received mobile terminal ID. The server 1 stores the mobile terminal ID, the reading date and time, and the visitor ID as one record in the download data DB 172, in association with the obtained exhibitor ID.

When a request code and lead ID are written in a visitor code or other dedicated two-dimensional code, the mobile terminal 2 reads the request code and lead ID from the code and transmits them to the server 1 together with the visitor ID and mobile terminal ID. The server 1 associates the mobile terminal ID, reading date and time, visitor ID, request code and lead ID with the exhibitor ID and stores them as one record in the download data DB 172. The request code and lead ID are not required transmission items and can be omitted.

Before or during the exhibition, the server 1 creates access information for the exhibitor to download visitor data and transmits it to the exhibitor terminal 3. The access information includes, for example, a uniform resource locator (URL) for accessing a download-only site, a URL for reissuing a passcode, and a passcode for authentication. The access information may be transmitted to the exhibitor by email, or may be transmitted to the exhibitor via an app directed to the exhibitor. Furthermore, the access information may be printed out on paper and mailed directly to the exhibitor.

The exhibitor terminal 3 receives the access information sent from the server 1. When the exhibitor terminal 3 receives a touch (click) operation on the URL link listed in the access information by the exhibitor, it retrieves the download page posted on the download-only site specified by the URL and displays the retrieved download page. When the exhibitor terminal 3 receives input of the exhibitor's email address and authentication passcode, it transmits the received exhibitor's email address and authentication passcode to the server 1.

The server 1 receives the email address and passcode sent from the exhibitor terminal 3. Based on the received email address and passcode, the server 1 determines whether or not it is possible to download the visitor data. Specifically, the server 1 obtains the exhibitor ID, event ID, and number of download requests from the exhibitor DB 174 based on the received email address and passcode.

The server 1 obtains the downloadable period from the event DB 171 based on the obtained event ID. If the server 1 determines that it is within the downloadable period, it obtains a predetermined number of times (threshold) stored in advance in the memory unit 12 or the mass storage unit 17. For example, if the visitor data can only be downloaded once due to security measures, the threshold is set to "1."

When the server 1 determines that the number of download requests it has acquired has exceeded a predetermined number, it resends (reissues) access information different from the previously issued access information to the exhibitor terminal 3 in response to a request for passcode reissue based on the passcode reissue URL. The reissued access information includes a URL for accessing the download-only site (same as the previously issued URL), a passcode reissue URL (same as the previously issued URL), and a new authentication passcode. Note that when access information is issued for the first time or reissued, the server 1 updates the number of download requests stored in the exhibitor DB 174 to the initial value (not downloaded: 0).

If the server 1 determines that the number of download requests has not exceeded a predetermined number, it acquires visitor data from the download data DB 172 and the visitor DB 173 based on the exhibitor ID and visitor ID. The visitor data includes the visitor's first and last name, visitor attributes (e.g., VIP member, customer who purchased product A, etc.), the name and department of the company to which the visitor belongs, etc. The server 1 writes the acquired visitor data into a file in CSV (comma-separated values) format. The server 1 transmits the written CSV file to the exhibitor terminal 3.

The exhibitor terminal 3 receives the CSV file sent from the server 1 and displays the received CSV file. The server 1 may write the visitor data into a file in PDF (Portable Document Format) format and send it, or may send the visitor data itself directly to the exhibitor terminal 3. Furthermore, the visitor data may be written into an EXCEL (registered trademark) file with an extension such as XLS or XLSX.

Figure 11 is a flowchart showing the processing steps when performing login processing of the mobile terminal 2 using the exhibitor code. The control unit 11 of the server 1 obtains the exhibitor ID from the exhibitor DB 174 based on the event ID, and generates an exhibitor code that describes the exhibitor ID and the event ID using a two-dimensional code generation library (step S101). The control unit 11 sends the generated exhibitor code by email to the exhibitor terminal 3 via the communication unit 13 (step S102).

The control unit 21 of the mobile terminal 2 reads the exhibitor code issued to the exhibitor via the photographing unit 28 or the code reading unit 29 (step S201). The control unit 21 acquires the exhibitor ID and event ID from the exhibitor code that has been read (step S202). The control unit 21 transmits the acquired exhibitor ID and event ID, as well as the mobile terminal ID, to the server 1 via the communication unit 23 (step S203). The control unit 11 of the server 1 receives the exhibitor ID, event ID, and mobile terminal ID transmitted from the mobile terminal 2 via the communication unit 13 (step S103).

The control unit 11 compares the received exhibitor ID and event ID with the exhibitor ID and event ID stored in the exhibitor DB 174 and determines whether they match (step S104). If the control unit 11 determines that they do not match (NO in step S104), it sends an error screen to the mobile terminal 2 via the communication unit 13 (step S105). The control unit 21 of the mobile terminal 2 receives the error screen sent from the server 1 via the communication unit 23 (step S204) and displays the received error screen on the display unit 25 (step S205).

If the control unit 11 determines that the two match (YES in step S104), it determines whether the current date and time is within the login period (step S106). If the control unit 11 determines that the current date and time is outside the login period (NO in step S106), it transitions to step S105.

If the control unit 11 determines that the current date and time is within the period during which login is possible (YES in step S106), it determines whether the number of logged-in mobile terminals 2 exceeds the number of available mobile terminals (step S107). Specifically, the control unit 11 obtains the number of available mobile terminals from the exhibitor DB 174 based on the exhibitor ID and event ID received. The control unit 11 counts the number of logged-in mobile terminals 2 from the online status of the monitored terminals stored in the terminal monitoring DB 175, and compares the counted number of logged-in mobile terminals 2 with the number of available mobile terminals 2.

When the control unit 11 determines that the number of logged-in mobile terminals 2 exceeds the number of available mobile terminals (YES in step S107), it transitions to step S105. When the control unit 11 determines that the number of logged-in mobile terminals 2 does not exceed the number of available mobile terminals (NO in step S107), it stores the terminal ID, terminal name, login date and time, read date and time, communication status, and exhibitor ID as one record in the terminal monitoring DB 175 (step S108). The control unit 11 transmits the visitor's reception screen to the mobile terminal 2 via the communication unit 13 (step S109). The control unit 21 of the mobile terminal 2 receives the visitor's reception screen transmitted from the server 1 via the communication unit 23 (step S206), and displays the received reception screen on the display unit 25 (step S207).

Figures 12 and 13 are flowcharts showing the processing steps when outputting visitor data. After the login process of the mobile terminal 2 is performed using the exhibitor code, the control unit 21 of the mobile terminal 2 reads the visitor code of the visitor who attended the event via the photographing unit 28 or the code reading unit 29 (step S211). The control unit 21 acquires the visitor ID from the read visitor code (step S212). The control unit 21 transmits the acquired visitor ID and mobile terminal ID to the server 1 via the communication unit 23 (step S213).

The control unit 11 of the server 1 receives the visitor ID and the mobile terminal ID transmitted from the mobile terminal 2 through the communication unit 13 (step S111), and acquires the exhibitor ID from the terminal monitoring DB 175 based on the received mobile terminal ID (step S112). The control unit 11 stores the mobile terminal ID, the read date and time, and the visitor ID as one record in the download data DB 172 in association with the acquired exhibitor ID (step S113). The control unit 11 determines whether or not a predetermined date and time has arrived at which the exhibitor's access information for downloading the visitor data can be transmitted to the exhibitor terminal 3 (step S114). The predetermined date and time may be, for example, two weeks or more before the event date and time (exhibition date and time) stored in the event DB 171, or one day or more before the event date and time. Furthermore, the predetermined date and time may be, for example, after a specified time on the event date (for example, 10:00 AM). The predetermined date and time may be, for example, stored in the storage unit 12 in advance. In this embodiment, it is determined whether a specific date and time has arrived at which the exhibitor's access information for downloading visitor data can be sent to the exhibitor terminal 3, but this determination process (step S114) is not essential.

If the control unit 11 determines that the specified date and time has not yet arrived (NO in step S114), the control unit 11 waits. If the control unit 11 determines that the specified date and time has arrived (YES in step S114), the control unit 11 creates access information for the exhibitor to download the visitor data (step S115). The access information includes a URL for accessing the download-only site, a URL for reissuing a passcode, and a passcode for authentication. The control unit 11 sends the created access information by email to the exhibitor terminal 3 via the communication unit 13 (step S116). The control unit 11 updates the number of download requests stored in the exhibitor DB 174 to the initial value (not downloaded: 0), and updates the authentication passcode stored in the exhibitor DB 174 to the issued passcode (step S117).

The control unit 31 of the exhibitor terminal 3 receives the access information sent from the server 1 via the communication unit 33 (step S311). The control unit 31 accepts a touch operation by the exhibitor on the URL link listed in the access information via the input unit 34 (step S312). The control unit 31 acquires the download page posted on the download-only site specified by the URL via the communication unit 33 (step S313).

The control unit 31 displays the acquired download page on the display unit 35 (step S314). The control unit 31 accepts input of the exhibitor's email address and authentication passcode through the input unit 34 (step S315), and the control unit 31 transmits the accepted exhibitor's email address and authentication passcode to the server 1 through the communication unit 33 (step S316).

The control unit 11 of the server 1 receives the email address and passcode sent from the exhibitor terminal 3 via the communication unit 13 (step S118). The control unit 11 compares the received email address and passcode with the email address and passcode stored in the exhibitor DB 174. If the control unit 11 determines that the two do not match, the process returns to step S118. If the control unit 11 determines that the two match, the control unit 11 obtains the exhibitor ID and event ID from the exhibitor DB 174 based on the email address and passcode.

The control unit 11 obtains the download period from the event DB 171 based on the obtained event ID, and determines whether or not it is within the download period (step S119). If the control unit 11 determines that it is outside the download period (NO in step S119), it ends the process. The control unit 11 may also send a message to the exhibitor terminal 3 via the communication unit 13, indicating that it is outside the download period.

When the control unit 11 determines that it is within the downloadable period (YES in step S119), it acquires a predetermined number of times previously stored in the storage unit 12 or the mass storage unit 17 (step S120). The control unit 11 determines whether the number of download requests has exceeded the predetermined number (step S121). Specifically, the control unit 11 acquires the number of download requests from the download data DB 172 based on the exhibitor ID. The control unit 11 compares the acquired number of download requests with the predetermined number.

If the control unit 11 determines that the number of download requests obtained has exceeded the predetermined number (YES in step S121), the process returns to step S115 and recreates access information including a new passcode. If the control unit 11 determines that the number of download requests obtained has not exceeded the predetermined number (NO in step S121), the control unit 11 obtains visitor data from the download data DB 172 and visitor DB 173 based on the visitor ID and exhibitor ID (step S122).

The control unit 11 writes the acquired visitor data into a CSV format file (step S123). The control unit 11 transmits the written CSV file to the exhibitor terminal 3 via the communication unit 13 (step S124). The control unit 31 of the exhibitor terminal 3 receives the CSV file transmitted from the server 1 via the communication unit 33 (step S317) and displays the received CSV file on the display unit 35 (step S318).

Figure 14 is an explanatory diagram showing an example of a screen that displays an exhibitor code on the exhibitor terminal 3. Figure 14A is an explanatory diagram showing an example of a screen that displays an exhibitor code sent by email. The server 1 uses a two-dimensional code generation library to generate an exhibitor code that describes the exhibitor ID and event ID. The server 1 sends the generated exhibitor code to the exhibitor terminal 3 by email. The exhibitor terminal 3 receives the email containing the exhibitor code sent from the server 1, and uses email software to display the exhibitor code on the screen.

Figure 14B is an explanatory diagram showing an example of a screen that displays an exhibitor code to an exhibitor via the app. The server 1 outputs the generated exhibitor code to the exhibitor's page in the app for the exhibitor. The exhibitor logs into the app on the exhibitor terminal 3, and the exhibitor code output to the exhibitor's page is displayed on the screen.

15 is an explanatory diagram showing an example of a screen for reading an exhibitor code by the mobile device 2. The screen includes a keyboard switching button 11a and a scan button 11b. The keyboard switching button 11a is a button for switching to a keyboard that allows exhibitor authentication information (e.g., exhibitor ID, password, etc.) to be directly entered instead of reading a two-dimensional code. When the mobile device 2 receives a touch operation of the keyboard switching button 11a, it calls up the keyboard and displays it on the screen.

The scan button 11b is a button that reads the exhibitor code. When the mobile terminal 2 receives a touch operation of the scan button 11b, it activates the photographing unit 28 or the code reading unit 29. The mobile terminal 2 obtains the exhibitor ID and event ID for login authentication from the exhibitor code via the photographing unit 28 or the code reading unit 29. The mobile terminal 2 transmits the obtained exhibitor ID and event ID to the server 1.

Figure 16 is an explanatory diagram showing an example of a download screen for visitor data. Figure 16A is an explanatory diagram showing an example of a screen displaying access information notified to the exhibitor. The server 1 creates access information for the exhibitor to download visitor data and transmits it to the exhibitor terminal 3. The access information includes, for example, a URL for accessing a download-only site, a passcode for authentication, a URL for reissuing the passcode, or a URL for viewing the manual.

The exhibitor terminal 3 receives and displays the access information transmitted from the server 1. When the exhibitor terminal 3 receives a touch operation on the URL link listed in the access information by the exhibitor, it acquires the download page posted on the download-only site specified by the URL, and displays the acquired download page (FIG. 16B).

Figure 16B is an explanatory diagram showing an example of a screen that accepts input of an exhibitor's email address and authentication passcode. The screen includes an email address input field 12a, a passcode input field 12b, and a Start Download button 12c. The email address input field 12a is a text field that accepts input of an email address. The passcode input field 12b is a text field that accepts input of a passcode. The Start Download button 12c is a button for downloading visitor data.

When the exhibitor terminal 3 receives a touch operation of the download start button 12c, it transmits the exhibitor's email address entered in the email address input field 12a and the passcode entered in the passcode input field 12b to the server 1. Based on the email address and passcode transmitted from the exhibitor terminal 3, the server 1 determines whether or not it is possible to download the visitor data.

If the server 1 determines that the visitor data can be downloaded, it acquires the visitor data from the download data DB 172 and the visitor DB 173 based on the exhibitor ID and visitor ID. The server 1 writes the acquired visitor data into a CSV format file and transmits the written CSV file to the exhibitor terminal 3. The exhibitor terminal 3 receives the CSV file transmitted from the server 1 and displays the received CSV file on the screen.

It is possible to issue an exhibitor code for each type of event (exhibition booth, seminar, etc.). For example, if a first exhibitor code for an exhibition booth and a second exhibitor code for a seminar are issued, visitor data for the exhibition booth can be downloaded after login to the mobile terminal 2 via the first exhibitor code is accepted. Also, visitor data for the seminar can be downloaded after login to the mobile terminal 2 via the second exhibitor code is accepted.

By issuing an exhibitor code for each type of event, for example if an exhibitor exhibits at both an exhibition booth and a seminar, it is possible to output visitor data for each type of event. Note that the process of issuing an exhibitor code for each type of event and the process of downloading visitor data are the same as those described above, so a description thereof will be omitted.

According to this embodiment, it is possible to obtain visitor data in real time without having to wait for the delivery date.

In this embodiment, a maximum number of download requests is set, so when the maximum number is reached, new access information is reissued to the exhibitor, improving the security level.

(Embodiment 2)
The second embodiment relates to a form in which attendee data based on an item to be downloaded selected from a plurality of items of attendee data is output. Note that a description of the contents that overlap with the first embodiment will be omitted.

Figure 17 is a block diagram showing an example of the configuration of the server 1 of the second embodiment. Note that the same reference numerals are used for the same contents as in Figure 2, and the description will be omitted. The large-capacity storage unit 17 stores a download setting DB 176. The download setting DB 176 stores information related to items to be downloaded.

Figure 18 is an explanatory diagram showing an example of a record layout of download setting DB 176. Download setting DB 176 includes an exhibitor ID column, a default item name column, a setting item name column, a sorting order column, and an option column. The exhibitor ID column stores an exhibitor ID that identifies the exhibitor. The default item name column stores the default item name of the item to be downloaded. The setting item name column stores the name of the item to be downloaded that is set by the exhibitor. The sorting order column stores the sorting order of the items to be downloaded. The option column stores option information for the items to be downloaded. The option information is, for example, "display the items to be downloaded enclosed in double quotes."

The visitor data has multiple items. The visitor data includes the visitor ID, the visitor's first and last name, the furigana of the visitor's first and last name, the name of the company to which the visitor belongs, the furigana of the company's name, the department, the exhibitor ID, the mobile terminal ID loaned to the exhibitor, the request code, the lead ID, the date the visitor code was read, etc. When the exhibitor selects an item to be downloaded from multiple items of visitor data, the server 1 obtains visitor data based on the selected item to be downloaded and outputs it to the exhibitor terminal 3.

Next, the process of outputting visitor data based on the items to be downloaded will be described. The exhibitor terminal 3 accepts the exhibitor's selection of items to be downloaded from multiple items of visitor data. The exhibitor terminal 3 transmits the exhibitor ID, the selected items to be downloaded, and setting information related to the target items to the server 1. The setting information includes, for example, the order of the target items, the names of the setting items to be displayed, options for the target items, etc.

The server 1 receives the exhibitor ID, the items to be downloaded, and the setting information related to the target items transmitted from the exhibitor terminal 3. The server 1 stores the received items to be downloaded and the setting information related to the target items in the download setting DB 176 in association with the exhibitor ID. Specifically, the server 1 stores the default item name, setting item name, order, and options in the download setting DB 176 as one record in association with the exhibitor ID.

When the server 1 receives a download request for visitor data from the exhibitor terminal 3, it acquires visitor data based on the set items to be downloaded and outputs it to the exhibitor terminal 3. Specifically, the server 1 receives the exhibitor's email address and authentication passcode from the exhibitor terminal 3, and acquires an exhibitor ID from the exhibitor DB 174 based on the exhibitor's email address and authentication passcode received. The server 1 acquires the items to be downloaded set by the exhibitor from the download setting DB 176 based on the acquired exhibitor ID.

Based on the acquired items to be downloaded, the server 1 acquires the corresponding items to be downloaded from the download data DB 172 and the visitor DB 173. The server 1 writes the acquired items to be downloaded, for example, to a file in CSV format, and transmits the written CSV file to the exhibitor terminal 3. The exhibitor terminal 3 receives the CSV file transmitted from the server 1, and displays the received CSV file.

Figure 19 is a flowchart showing the processing steps when accepting the selection of items to be downloaded. The control unit 31 of the exhibitor terminal 3 accepts the selection of items to be downloaded from multiple items of visitor data via the input unit 34 (step S331). The control unit 31 transmits the exhibitor ID, the selected items to be downloaded, and setting information related to the items (order, setting item name, options, etc.) to the server 1 via the communication unit 33 (step S332).

The control unit 11 of the server 1 receives the exhibitor ID, the items to be downloaded, and the setting information related to the items transmitted from the exhibitor terminal 3 (step S131). The control unit 11 associates the received items to be downloaded and the setting information related to the items with the exhibitor ID and stores them in the download setting DB 176 of the mass storage unit 17 (step S132).

Figure 20 is a flowchart showing the processing steps when outputting visitor data based on items to be downloaded. Note that the same reference numerals are used for the same contents as in Figure 13, and the description will be omitted. The control unit 11 of the server 1 executes step S121. If the control unit 11 determines that the number of download requests has not exceeded the predetermined number (NO in step S121), the control unit 11 acquires the items to be downloaded set by the exhibitor based on the exhibitor ID from the download setting DB 176 (step S141). Based on the acquired items to be downloaded, the control unit 11 acquires the corresponding visitor data from the download data DB 172 and visitor DB 173 (step S142). The control unit 11 executes the processing of step S123.

Figure 21 is an explanatory diagram showing an example of a screen that accepts the selection of items to be downloaded. The screen that accepts the selection of items to be downloaded includes item selection check boxes 13a, a sort order input field 13b, a setting item name input field 13c, an option selection combo box 13d, and a save button 13e.

The item selection checkbox 13a is a checkbox that accepts the selection of an item to be downloaded. Checked items are output as items to be downloaded. The order input field 13b is a text field that accepts input of the order of items. The setting item name input field 13c is a text field that accepts input of item names. In addition to default item names, exhibitors can set any item name. The option selection combo box 13d is a combo box that accepts option settings for items. Options such as "enclose in double quotes", "full-width display", or "insert space" may be set in the option selection combo box 13d. The save button 13e is a button that saves the selected item to be downloaded.

The exhibitor terminal 3 acquires and displays a selection acceptance screen for the items to be downloaded from the server 1. When the exhibitor terminal 3 accepts a touch operation of the save button 13e, it transmits to the server 1 the exhibitor ID, the items to be downloaded selected in the item selection check boxes 13a, the order input in the order input field 13b, the setting item names input in the setting item name input field 13c, and the options selected in the option selection combo box 13d. The server 1 receives the items to be downloaded, the order corresponding to the target items, the item names, and the options transmitted from the exhibitor terminal 3. The server 1 stores the received items to be downloaded, the order corresponding to the target items, the item names, and the options in the download setting DB 176 in association with the exhibitor ID.

According to this embodiment, by outputting visitor data based on the items to be downloaded, it becomes possible to create the report that the exhibitor desires.

(Embodiment 3)
The third embodiment relates to an embodiment in which a synchronization process is performed based on a visitor ID when the mobile terminal 2 determines that it is unable to communicate with the server 1 based on the communication state of the network N. Note that a description of the contents that overlap with the first and second embodiments will be omitted.

Figure 22 is a block diagram showing an example of the configuration of the server 1 of embodiment 3. Note that the same reference numerals are used for the same contents as in Figure 2, and the description will be omitted. The large-capacity storage unit 17 stores a visitor management DB 177. The visitor management DB 177 stores management information for managing visitors who attend the event.

Figure 23 is an explanatory diagram showing an example of a record layout of visitor management DB177. Visitor management DB177 includes an event ID column, a visitor ID column, an application status column, a reception status column, and a sub-event ID column. The event ID column stores an event ID that identifies an event. The visitor ID column stores a visitor ID that identifies a visitor. The application status column stores the application status of attending the event. The application status column stores, for example, "applied" or "cancelled." The reception status column stores the reception status of the visitor. The reception status column stores, for example, "attended" or "not yet accepted." The sub-event ID column stores a sub-event ID that identifies a sub-event that the visitor has attended.

Figure 24 is a block diagram showing an example of the configuration of a mobile terminal 2 according to embodiment 3. Note that the same reference numerals are used for the same contents as in Figure 8, and the description thereof will be omitted. The mobile terminal 2 includes an auxiliary memory unit 27. The auxiliary memory unit 27 includes a recording medium such as an HDD or SSD. The auxiliary memory unit 27 includes a reading history DB 271 and a visitor information display DB 272.

The read history DB271 stores history information read from a visitor code that describes a visitor ID. The visitor information display DB272 stores visitor information related to visitors who attend the event. In this embodiment, the memory unit 22 and the auxiliary memory unit 27 may be configured as an integrated memory device. The auxiliary memory unit 27 may also be configured from multiple memory devices. Furthermore, the auxiliary memory unit 27 may be an external memory device connected to the mobile terminal 2.

Figure 25 is an explanatory diagram showing an example of a record layout of the reading history DB271. The reading history DB271 includes an event ID column, a visitor ID column, a visit date and time column, and a status column. The event ID column stores an event ID that identifies an event. The visitor ID column stores a visitor ID that identifies a visitor. The visit date and time column stores information about the date and time when a visitor arrived at an event.

The status column stores the synchronization status of the visitor ID read from the visitor code. The synchronization status is expressed, for example, as "sent", "not sent", "send error" and "read error" states. The "sent" state is a synchronized state in which the visitor ID has been sent to the server 1 and visitor information has been acquired. The "not sent" state is a state in which the visitor ID has not been sent because it has been determined that communication is not possible. The "send error" state is a state in which a line problem or the like occurred during transmission and the transmission has failed. The "read error" state is a state in which synchronization of the visitor ID has failed because an invalid visitor code has been read.

Figure 26 is an explanatory diagram showing an example of a record layout of DB272 for displaying visitor information. DB272 for displaying visitor information includes a visitor ID column, a company name column, a visitor name column, a visitor number column, and an attribute column. The visitor ID column stores a visitor ID that identifies a visitor. The company name column stores the name of the company to which the visitor belongs. The visitor name column stores the name of the visitor. The visitor number column stores the number of people who attended the event according to one visitor ID. The attribute column stores attribute information according to the visitor's attributes.

Note that the storage format of each DB described above is just an example, and other storage formats are also possible as long as the relationships between data are maintained.

Figure 27 is a functional block diagram showing the processing operation for performing synchronization processing based on a visitor ID. The mobile terminal 2 reads the visitor code issued to the visitor. The visitor code may be, for example, a two-dimensional code or a one-dimensional code. In this embodiment, the reading of a two-dimensional code will be described as an example. The mobile terminal 2 uses a two-dimensional code analysis library to obtain the visitor ID from the read two-dimensional code.

The mobile terminal 2 determines whether or not it is possible to communicate with the server 1 according to the communication state of the network N. Specifically, the mobile terminal 2 determines whether or not it is possible to communicate with the server 1 by using a connection line acquisition API (Application Programming Interface), which is one function of the control program 2P in the mobile terminal 2. The connection line includes a public line network such as a 4G or 5G communication standard, or a wireless communication line such as Wi-Fi (registered trademark).

If the mobile device 2 determines that it is able to communicate with the server 1, it transmits the visitor ID read from the two-dimensional code to the server 1. The server 1 receives the visitor ID transmitted from the mobile device 2. The server 1 determines whether or not to permit attendance based on the received visitor ID. Specifically, the server 1 acquires the reception status of the visitor from the visitor management DB 177 based on the visitor ID and event ID. If the server 1 determines that the acquired reception status is "already attended", it determines that the visitor is a duplicate visitor. If the server 1 determines that the acquired reception status is "not yet accepted", it determines that the visitor is not a duplicate visitor.

If the server 1 determines that the visitor is not a duplicate visitor, it determines that the visit should be permitted. In this case, the server 1 acquires visitor information from the visitor management DB 177 based on the visitor ID. The visitor information includes the name of the company to which the visitor belongs, the visitor's name, the number of visitors, and the visitor's attributes (e.g., VIP member, customer who purchased product A, etc.). Based on the event ID and visitor ID, the server 1 updates the reception status column in the visitor management DB 177 to "Attended." The server 1 sends the acquired visitor information to the mobile terminal 2.

The portable terminal 2 receives and displays the visitor information transmitted from the server 1. The portable terminal 2 stores the reading history of the two-dimensional code in the reading history DB 271. Specifically, the portable terminal 2 stores the event ID, visitor ID, and "sent" status as one record in the reading history DB 271 in association with the visit date and time (the reading time when the visitor ID was read). The portable terminal 2 stores the visitor information in the visitor information display DB 272. Specifically, the portable terminal 2 stores the visitor ID, company name, visitor name, number of visitors, and attributes as one record in the visitor information display DB 272.

If the server 1 determines that there is a duplicate visitor, it determines that the visit is not permitted. In this case, the server 1 does not send the visitor information to the mobile terminal 2, and sends a read error message to the mobile terminal 2 to the effect that the visit is not permitted. In response to the read error message sent from the server 1, the mobile terminal 2 stores the two-dimensional code read history in the read history DB 271 with the transmission status of the visitor ID as "read error". Specifically, the mobile terminal 2 associates the event ID, visitor ID, and "read error" status with the visit date and time and stores them as one record in the read history DB 271. Through the above process, the server 1 and the mobile terminal 2 synchronize based on the visitor ID, and share the result of the determination as to whether or not to permit visit, and the visitor information of visitors who are permitted to visit.

On the other hand, if the mobile terminal 2 determines that it is unable to communicate with the server 1, it stores the visitor ID (unsynchronized visitor ID) read from the two-dimensional code in the read history DB 271. Specifically, the mobile terminal 2 associates the event ID, visitor ID, and "not sent" status with the date and time of visit as one record in the read history DB 271.

In order to resend an unsent visitor ID to the server 1, the mobile terminal 2 starts a timer to calculate the elapsed time. When the mobile terminal 2 determines that a predetermined time interval (e.g., 10 seconds) has elapsed, it re-determines whether or not communication with the server 1 is possible. When the mobile terminal 2 determines that communication with the server 1 is possible, it re-sends the visitor ID to the server 1. Note that the communication re-determination process and visitor ID re-sending process are similar to the processes described above, so a description thereof will be omitted.

In this way, if the mobile terminal 2 is unable to send the visitor ID to the server 1 due to a deterioration in communication conditions or other reasons, it temporarily stores the visitor ID as "not sent" and resumes transmission as soon as communication is restored. This allows for smooth reception of visitors even in poor communication conditions at an event venue, for example.

Figures 28 and 29 are flow charts showing the processing steps when accepting a visitor who has come to an event. The control unit 21 of the mobile terminal 2 reads the visitor code via the photographing unit 28 or the code reading unit 29 (step S251). The control unit 21 uses a two-dimensional code analysis library to obtain a visitor ID from the read visitor code (step S252).

The control unit 21 uses the connection line acquisition API to perform a communication determination process to determine whether or not communication with the server 1 via the network N is possible (step S253). If the control unit 21 determines that communication with the server 1 is not possible (NO in step S253), it stores the event ID, visitor ID, and "not transmitted" status as one record in the read history DB 271 in association with the date and time of arrival (step S254). The control unit 21 uses the clock unit 26 to determine whether a predetermined time interval (e.g., 5 seconds) has elapsed (step S255).

If the control unit 21 determines that the predetermined time interval has elapsed (YES in step S255), the control unit 21 returns to step S253 and re-determines whether communication with the server 1 is possible. If the control unit 21 determines that the predetermined time interval has not elapsed (NO in step S255), the control unit 21 waits for processing.

When the control unit 21 determines that communication with the server 1 is possible (YES in step S253), the control unit 21 transmits the visitor ID read from the visitor code to the server 1 via the communication unit 23 (step S256). The control unit 11 of the server 1 receives the visitor ID transmitted from the mobile terminal 2 via the communication unit 13 (step S151). The control unit 11 acquires the reception status of the visitor from the visitor management DB 177 based on the visitor ID and event ID, and determines whether the visitor is a duplicate visitor based on the acquired reception status (step S152).

If the control unit 11 determines that the visitor is a duplicate visitor (YES in step S152), it transmits a read error to the mobile device 2 via the communication unit 13 (step S153). The control unit 21 receives the read error transmitted from the server 1 via the communication unit 23 (step S257). Depending on the received read error, the control unit 21 associates the event ID, visitor ID and "read error" status with the visit date and time and stores them as one record in the read history DB 271 (step S258).

When the control unit 11 determines that the visitor is not a duplicate visitor (NO in step S152), it acquires visitor information from the visitor management DB 177 based on the visitor ID (step S154). The visitor information includes the name of the company to which the visitor belongs, the visitor's name, the number of visitors, and the visitor's attributes. Based on the event ID and visitor ID, the control unit 11 updates the reception status column in the visitor management DB 177 to "Attended" (step S155). The control unit 11 sends the acquired visitor information to the mobile device 2 via the communication unit 13 (step S156).

The control unit 21 receives the visitor information sent from the server 1 (step S259) and stores the read history and the received visitor information in the auxiliary storage unit 27 (step S260). Specifically, the control unit 21 stores the event ID, visitor ID, and "sent" status as one record in the read history DB 271, in association with the visit date and time. The control unit 21 stores the visitor ID, company name, visitor name, number of visitors, and attributes as one record in the visitor information display DB 272. The control unit 21 displays the visitor information on the display unit 25 (step S261).

Figure 30 is an explanatory diagram showing an example of a visitor reception screen. The reception screen includes an event name 20a, a number display field 20b, a visitor display field 20c, a button 20d, and an object 20e. The event name 20a is a display field that displays the name of the event. The number display field 20b is a display field that displays the total number of visitor codes read ("Total Read"), the number of people who attended ("Attended"), and the number of unsynchronized visitor IDs ("Unsynchronized"). The visitor display field 20c is a display field that displays visitor information.

Button 20d is a button for switching the reading mode. The reading modes include a code reading mode for reading a visitor code, and a direct input mode for directly inputting a visitor ID (attendance ticket ID). Object 20e is a button or text field for accepting a visitor ID. In the direct input mode, object 20e is a text field for inputting a visitor ID. In the code reading mode, object 20e changes to a button for reading a two-dimensional code.

The mobile terminal 2 counts the total number of reads (the number of synchronized cases and the number of unsynchronized cases) from the read history DB 271 based on the event ID. The mobile terminal 2 counts the number of visitors from the visitor information display DB 272. The mobile terminal 2 counts the number of unsynchronized cases in the "unsent" or "error" state from the read history DB 271 based on the event ID. The mobile terminal 2 displays the counted total number of reads, the number of visitors, and the number of unsynchronized cases in the number display field 20b. Note that in this embodiment, an example has been described in which the counted number of "unsent" cases and the number of "error" cases is displayed as the number of unsynchronized cases, but this is not limited to this. For example, the number of "unsent" cases and the number of "error" cases may each be displayed.

When the mobile device 2 receives a touch operation of the button 20d, the mobile device 2 switches the reading mode. In the code reading mode, the mobile device 2 acquires a visitor ID from a visitor code read by the object 20e (button). In the direct input mode, the mobile device 2 receives an input visitor ID directly from the object 20e (text field).

The mobile terminal 2 performs a process to determine whether or not communication with the server 1 is possible. If the mobile terminal 2 determines that communication with the server 1 is possible, it transmits the accepted visitor ID to the server 1. The server 1 receives the visitor ID transmitted from the mobile terminal 2 and determines whether or not to permit attendance based on the received visitor ID. If the server 1 determines that attendance is permitted, it retrieves visitor information including the visitor's name, number of visitors, company, attributes, etc. from the visitor management DB 177 based on the visitor ID.

The server 1 transmits the acquired visitor information to the mobile terminal 2. The mobile terminal 2 receives the visitor information transmitted from the server 1. The mobile terminal 2 stores the visitor date and time and the "transmitted" status as one record in the read history DB 271 based on the event ID and visitor ID. The mobile terminal 2 displays the received visitor information in the visitor display area 20c.

Figure 31 is an explanatory diagram showing an example of a reading history screen. The number of items display field 20b is the same as the number of items display field 20b in Figure 30, so a description is omitted. The reading history screen includes a reading history display field 21a, a sending icon 21b, a not-sent icon 21c, a sending error icon 21d, a reading error icon 21e, a cancel icon 21f, a sending extraction button 21g, a not-sent extraction button 21h, a sending error extraction button 21i, and a reading error extraction button 21j.

The reading history display field 21a is a display field that displays the reading history of the visitor code. The reading history displayed in the reading history display field 21a includes the visitor ID and the time the visitor code was read. The sending icon 21b is an icon that indicates the "sent" status. "Sent" is a reading history in which the visitor ID was successfully sent. The not-sent icon 21c is an icon that indicates the "not-sent" status. "Not-sent" indicates a status in which the visitor ID was read when the line was not working, but was not sent to the server 1.

The transmission error icon 21d is an icon that indicates a "transmission error" state. "Transmission error" indicates that a line malfunction or the like occurred during transmission, causing the transmission to fail. The read error icon 21e is an icon that indicates a "read error" state. "Read error" indicates that the visitor code is invalid. The cancel icon 21f is an icon that indicates a "cancellation" state. "Cancellation" indicates that the read visitor ID has been canceled. Note that the icons are not limited to those mentioned above, and any icon may be provided according to actual needs.

The sent extract button 21g is a button for displaying only the read history in the "sent" state. The not sent extract button 21h is a button for displaying only the read history in the "not sent" state. The sent error extract button 21i is a button for displaying only the read history in the "sent error" state. The read error extract button 21j is a button for displaying only the read history in the "read error" state. The mobile terminal 2 acquires the visitor ID, the visit date and time information, and the synchronization status from the read history DB 271 based on the event ID. The mobile terminal 2 displays the acquired visitor ID and visit date and time information in the read history display field 21a. The mobile terminal 2 displays the corresponding icon based on the synchronization status corresponding to the acquired visitor ID.

When the portable terminal 2 receives a touch operation of the transmission extraction button 21g, it extracts a reading history corresponding to the "sent" state from the reading history acquired from the reading history DB 271. When the portable terminal 2 receives a touch operation of the not-sent extraction button 21h, it extracts a reading history corresponding to the "not-sent" state from the reading history acquired from the reading history DB 271. When the portable terminal 2 receives a touch operation of the transmission error extraction button 21i, it extracts a reading history corresponding to the "sent error" state from the reading history acquired from the reading history DB 271. When the portable terminal 2 receives a touch operation of the read error extraction button 21j, it extracts a reading history corresponding to the "read error" state from the reading history acquired from the reading history DB 271. The portable terminal 2 displays the extracted reading history in the reading history display field 21a.

In this embodiment, it is possible to accept visitors to an event by reading a visitor code that describes the visitor ID.

According to this embodiment, if the mobile terminal 2 that accepts visitors cannot connect to the server 1, it can store the visitor ID and resend it after the communication situation is restored.

According to this embodiment, it is possible to continue accepting visitors even if the communication status of network N is poor or the system on server 1 goes down.

According to this embodiment, it is possible to check in visitors on the mobile terminal 2, regardless of the local environment.

The embodiments disclosed herein are illustrative in all respects and should not be considered limiting. The scope of the present invention is indicated by the claims, not by the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the claims.

1 Management device (server)
REFERENCE SIGNS LIST 11 Control unit 12 Storage unit 13 Communication unit 14 Input unit 15 Display unit 16 Reading unit 17 Large-capacity storage unit 171 Event DB
172 Download data DB
173 Visitor DB
174 Exhibitor DB
175 Terminal monitoring DB
176 Download settings DB
177 Visitor Management DB
1a Portable storage medium 1b Semiconductor memory 1P Control program 2 Portable terminal 21 Control unit 22 Storage unit 23 Communication unit 24 Input unit 25 Display unit 26 Clock unit 27 Auxiliary storage unit 271 Reading history DB
272 Visitor information display database
28: Image capture unit 29: Code reader 2P: Control program 3: Exhibitor terminal 31: Control unit 32: Memory unit 33: Communication unit 34: Input unit 35: Display unit 3P: Control program

Claims (9)

a reception unit that receives logins from mobile terminals provided to multiple exhibitors exhibiting at the event using exhibitor codes that identify the exhibitors; and
a storage control unit that executes control to store in a predetermined device the visitor data corresponding to the visitor code read by the mobile terminal after login in association with the exhibitor;
a notification unit that notifies each of the exhibitors of the access information for downloading the visitor data before or during the exhibit;
an output control unit that executes control to output the visitor data in response to a download request for the visitor data based on the notified access information of the exhibitor. The information processing device according to claim 1 , wherein the notification unit re-notifies access information different from the access information when the number of download requests for the visitor data exceeds a predetermined number. The visitor data includes a plurality of items,
the receiving unit receives a selection of an item to be downloaded from the plurality of items;
the output control unit executes control to output the attendee data based on the selected item in response to the download request for the attendee data.
3. The information processing device according to claim 1 or 2. when a plurality of the mobile terminals are lent to the exhibitor , the reception unit accepts login of the mobile terminals using the exhibitor code that is common or individual among the mobile terminals;
4. The information processing device according to claim 1. The storage control unit executes control to store the attendee data, including the name of the attendee and the name of the company to which the attendee belongs, in the specified device.
5. An information processing apparatus according to claim 1. An information processing system having a mobile terminal and a management device that manages visitor data,
The management device includes:
a reception unit that receives logins from mobile terminals provided to multiple exhibitors exhibiting at the event using exhibitor codes that identify the exhibitors; and
a storage unit that stores visitor data corresponding to the visitor code read by the mobile terminal after logging in, in association with the exhibitor;
a notification unit that notifies each of the exhibitors of the access information for downloading the visitor data before or during the exhibit;
an output unit that outputs the visitor data in response to a download request for the visitor data based on the access information of the exhibitor notified by the notification unit. The mobile terminal,
determining whether communication with a management device that manages the attendee data is possible;
If it is determined that communication is possible, the visitor identification information read from the visitor code is transmitted to the management device;
If it is determined that communication is not possible, the read visitor identification information is stored;
re-determining whether communication with the management device is possible at predetermined time intervals;
The information processing system according to claim 6 , wherein when it is determined that communication is possible, the stored visitor identification information is transmitted to the management device. An information processing method executed by an information processing device,
accepting logins to mobile terminals via exhibitor codes that identify the exhibitors and that are to be read by the mobile terminals that are loaned to the exhibitors who will be exhibiting at the event;
store visitor data corresponding to the visitor code read by the mobile terminal after login in association with the exhibitor;
notifying each of said exhibitors of their access information for downloading said visitor data before or during their exhibition;
and outputting the visitor data in response to a download request for the visitor data based on the notified access information of the exhibitor. On the computer,
accepting logins to mobile terminals via exhibitor codes that identify the exhibitors and that are to be read by the mobile terminals that are loaned to the exhibitors who will be exhibiting at the event;
store visitor data corresponding to the visitor code read by the mobile terminal after login in association with the exhibitor;
notifying each of said exhibitors of their access information for downloading said visitor data before or during their exhibition;
a program for executing a control process including a process for outputting the visitor data in response to a download request for the visitor data based on the notified access information of the exhibitor.

Images